Posted: 8/9/2013 12:00:17 PM EDT
|
SIP is a shitty protocol network wise. But even when the network had made it as easy as possible for SIP to run and route over it your applications are next to brain dead.
Computers, and especially cell phones, tend to have multiple network interfaces that can be connected to multiple networks. It would be awesome if your application would consult the routing table to determine the correct registration and invite address to place in the SIP packets. Please stop picking a random interface IP or simply the one with the default gateway. Very few SIP applications do this. Some even allow the user to manually specify the address or adapter to use. Bravo. You have made my life easy. |
|
Quoted:
SIP is a shitty protocol network wise. But even when the network had made it as easy as possible for SIP to run and route over it your applications are next to brain dead. Computers, and especially cell phones, tend to have multiple network interfaces that can be connected to multiple networks. It would be awesome if your application would consult the routing table to determine the correct registration and invite address to place in the SIP packets. Please stop picking a random interface IP or simply the one with the default gateway. Very few SIP applications do this. Some even allow the user to manually specify the address or adapter to use. Bravo. You have made my life easy. Just wait for the new Java SIP. It'll eliminate all your current problems! 
|
|
Quoted:
I assume you're speaking to application developers who choose to use SIP as a signaling protocol? Doesn't sound like a SIP issue per say, more like a SIP proxy setting is wrong on the client. You'd be right. Except I'm finding some applications don't have the ability to set it. And in my situation its not even required with basic routing or source IP checks such as... What is my source interface for this traffic? Unless theres some sort of special situation, by default your source IP on the packet should also be what SIP address you put in the packet. Computer with multiple network interfaces has IPs... 192.168.1.2/24 (Your computer on a home network that gets NAT'ted outbound) 172.16.0.2/24 (Tunnel adapter IP address on a VPN) Default gateway is 192.168.1.1 Additional route for 10.0.0.0/24 is gateway 172.16.0.1 for traffic going over VPN PBX/SIP Server 10.0.0.2 Packet to the server has source address 172.16.0.2. Good. It gets to the server. But in the SIP address within the packet it provides the server with 192.168.1.2 Most applications provide for a STUN server setting. Which fixes the problem because the STUN server tells the SIP app "Hey! I see your source IP as 172.16.0.2" and then the SIP app puts that within its packets. But its stupid to even have to do this in the first place. You'd figure after past protocols like FTP fucked up by putting IPs in the data portion of the packet developers would have learned their lesson. Well... I guess they're developers and not network engineers... |