<[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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
