Is there any way to see if a SIP message is from behind nat? The example for nathelper searches for Cisco ATA, but you could have that without nat and you could have a different phone behind nat. Can I always apply nat fixing? Does it break anything if it was not natted? (My SER is not behind nat. It might make a difference if SER itself is behind nat.)
Is there still (0.8.11) the function add_rport()? SER does not complain with it there. Is it the same as force_rport? Does it do anything? Is it necessary? What does it do? (I see force_rport in nathelper.cfg.)
Why would I want to add direction=active?
Am I correct that there are 2 points in a SIP message that there could be problems from nat, 1-various SIP headers, and 2-SDP (c=, o=)? Does fix_nated_contact fix everything in the SIP message itself and fix_nated_sdp fix everything in SDP? Where would I want fix_nated_contact and fix_nated_sdp? Do I want fix_nated_contact in every message and fix_nated_sdp in INVITEs and its responses (provisional and OK)?
Thanks.
Dovid
Does Anybody knows how to implement a numbering plan with ser...? Ivan
Dovid wrote:
Is there any way to see if a SIP message is from behind nat? The example for nathelper searches for Cisco ATA, but you could have that without nat and you could have a different phone behind nat. Can I always apply nat fixing? Does it break anything if it was not natted? (My SER is not behind nat. It might make a difference if SER itself is behind nat.)
Yes, you can, but some phones will not work with such setup. This techniquie can only be applied to UAs supporting symmetric signalling and symmetric media, i.e. phones that always send and receive SIP and RTP from the same port (i.e. port X for SIP and port Y for RTP). The most prominent example of non-symmetric UA is Cisco IOS.
Is there still (0.8.11) the function add_rport()? SER does not complain with it there. Is it the same as force_rport? Does it do anything? Is it necessary? What does it do? (I see force_rport in nathelper.cfg.)
No, add_rport() was removed due to the fact that force_rport() was added into the base module.
Why would I want to add direction=active?
It might be necessary when sending session initiated by UA behind a NAT to some device that supports connection oriented media (COMEDIA), in which case destination device will be able to guess correct RTP settings to allow RTP through NAT. Again, the most popular device of such kind is Cisco IOS, therefore such feature allows to solve the problem with NAT completely for UA->PSTN calls, when properly configured Cisco GW is used for termination.
Am I correct that there are 2 points in a SIP message that there could be problems from nat, 1-various SIP headers, and 2-SDP (c=, o=)? Does fix_nated_contact fix everything in the SIP message itself and
Yes, it does, when applied correctly (see above).
fix_nated_sdp fix everything in SDP?
Sort of. Since RTP doesn't flow through the SIP proxy, we just assume that the NAT will not change source port for RTP and hope for good. In some cases it works, in some does not. You can use rtpproxy to ensure that RTP will always be able to traverse NAT, but again, it will work only for devices supporting symmetric RTP and will introduce another hop for RTP propagation.
Where would I want fix_nated_contact and fix_nated_sdp? Do I want fix_nated_contact in every message and fix_nated_sdp in INVITEs and its responses (provisional and OK)?
Yes, that's correct. Of course you don't really need to apply fix_nated_contact() to final negative replies.
-Maxim
Thanks.
Dovid
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers