Frank Shearar wrote: > <[EMAIL PROTECTED]> wrote: > >> I am currently working on the TCP transport for the opensipstack >> library. I have a few doubts on how to properly construct the Contact >> address for outbound INVITEs. On construction of the INVITE request, >> the UA Core doesn't have an idea about the port the transport would be >> providing to send the request and it would be impossible to guess this >> before the actual request hits the Transport Unit. Currently, the stack >> populates the Via and Contact URIs with the address of the default >> listener on port 5060. Upon detection that the request is bound to a >> TCP destination, the transaction would change the top most via address >> with the socket created by the Transport to be sure that responses would >> be sent using the same socket. However, this approach cannot be used >> for the Contact URI since the contact might be the remote address of a >> request being proxied. Thus, the Contact address should remain intact >> for proxy transactions and only change it if the request is actually >> originated from the local UA. An extra sanity check is needed and see >> if Contact URI == local listener. This would work but I am in doubt >> that this is the best way to do it. My goal is to use the socket for >> the entire lifespan of the dialog without having to inject transport >> logic into the core level. I wonder what's the popular approach to do >> this. Any advice on how to do this the right way would be appreciated. >> > > I had a similar problem: you might have a UA with several IP addresses (one > for your LAN, one for your VPN connection), or you might need to call people > in several networks (the public Internet, or perhaps your LAN has a gateway > with a permanent VPN connection), and you need to know what IP address or > domain name to put in your Contact URI. You might, for instance, need to use > "sip:[EMAIL PROTECTED]" when contacting people on your VPN, and > "sip:[EMAIL PROTECTED]" to people on your LAN. Or you might need to call > someone o > n the public Internet, via a NAT. > > The route I chose, which works so far in the scenarios I use (I've got a > LAN, a gateway to a VPN on the LAN, and a NATting gateway to the Internet; > the VPN in turn uses a NATting gateway to the rest of my employer's > network), is this: > > 1. Ask the OS what the best local address is to use when contacting the > target. (My stack's currently only Windows-based, so I'm using IpHlpApi's > GetBestInterface to get the interface index, and then trawl through > GetIpAddrTable's table to find the IP address of that interface. I don't > think this will work in the event of multiple IP addresses on one interface, > if that's possible on Windows.) > > 2. With that local address in hand, I ask the OS's routing table what the > best route would be between this local address and that target. The best > route might be the default route. > > 3. If the best route's the default route, I check to see if there's a mapped > address (*) to use when contacting that address. If there is, I use the > mapped address. If not, then I use the local address found in step 2. > > (*) The UA keeps a list of "mapped routes" - networks that are on the far > side of a NATting gateway. These mapped routes associate the remote IP of > the NAT with a target network so that, for instance, all VPN calls (defined > by IPs on the network 192.168.1.0/24) have the VPN gateway's IP of > 192.168.1.100 (continuing from the example in the first paragraph). The > "mapped address" of this mapped route is thus 192.168.1.100. Additionally, > the mapped route might also provide a port, so that you would know to use > port 15060 (resulting in a URI of "sip:[EMAIL PROTECTED]:15060"). I currently > set these mapped routes via a configuration file. The idea is that when I > find time to implement ICE, I can use STUN to add these routes where > possible. > > I don't claim that the above is a 100% foolproof algorithm, but it does the > job in the scenarios common to my work: UAs on just a LAN, multihomed UAs, > UAs needing to call UAs on the far side of a NAT gateway. > > I hope this helps! > > frank > >
Pretty impressive approach, Frank. I currently do the same thing in opensipstack with the exception of the mapped address. I will steal your idea with mapped addresses when i get the chance ;-). However, my current problem is not really how to identify the correct interface to use. In fact, OpenSBC, one of the applications available in the project, can do bridging accross multiple networks. I use synchronous sockets for UDP so when the request reaches the Transaction Layer, Contact and Via addresses already contain the correct mapping since UDP sockets are not dynamically created on a per transaction basis. The problem arises when the transport is TCP. Since TCP sockets are yet to be created, as the transaction layer decides which transport to use for the request, it would carry the extra burden of changing the ports. This is pretty straight forward in Via address for it has pre-knowledge that the top via is always inserted by the local UA, proxy mode or not. however, Contact is much more complicated. There is the need to determine whether it can be changed or not. Proxy transactions should back off. Contacts for REGISTER should also not be changed. However, locally originated INVITEs should. With these gazillion complications, I began wondering whether its indeed the best way or there are more brilliant approach which I haven't thought of. Joegen _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
