That's called rtp auto adjust. The SIP server will not trust what it's in the SDP, but the real ip/source of the RTP flow coming to its own RTP port. David Ponzone Direction Technique email: david.ponzone@ipeva.fr tel: 01 74 03 18 97 gsm: 06 66 98 76 34 Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr - www.ipeva-studio.com Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur. Le 27/07/2011 à 01:58, Narendra Sirugudi a écrit :
David, Thanks for your reply.
rfc 3581 is indeed helpful.
If my understanding is correct, this helps the SIP UA client to learn the SIP session port as seen by the SIP server.
But i think this does not solve the issue of RTP IP and port in the SDP, unless i am missing something.
The basic issue with SIP UA client sitting behind a NAT server is that the SDP in the INVITE from the SIP UA, will contain the private IP & port of the SIP UA. At best the SIP server can assume that the RTP IP will be the source IP address seen on the IP header of the INVITE. But how to get the SIP UA client's NATTED RTP port?
A public STUN server does solve this issue, wherein the client first queries the STUN server to learn the natted RTP IP and port seen by the STUN server. Many SIP UA clients (softphones) seem to have the support for STUN, but STUN does not work with symmetric NAT. TURN, ICE are the suggested solutions. But i am yet to see any SIP UA clients having TURN, ICE support. One can definitely say that most SIP UA clients currently do not have TURN/ICE support. Moreover TURN/ICE might have latency issues.
Hence one tends to still look at SIP server based solutions.
Please do get back with your thoughts. Its possible that i am missing something.
thanks, --naren
On Tue, Jul 26, 2011 at 10:07 PM, David Ponzone <david.ponzone@ipeva.fr> wrote: More precisely, FreeSWITCH does not have any issues to handle a remote endpoint behind NAT if the endpoint correctly sets the rport parameter in the Via field (RFC3581). In case the endpoint does not, FreeSWITCH can force rport, meaning it will answer to the endpoint as if rport was set. This mechanism does not have anything to do with STUN/ICE or other external mechanism and it works perfectly.
David Ponzone Direction Technique email: david.ponzone@ipeva.fr tel: 01 74 03 18 97 gsm: 06 66 98 76 34
Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr - www.ipeva-studio.com
Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur.
Le 26/07/2011 à 07:23, curriegrad2004 a écrit :
In this case there's nothing I can think of that FreeSWITCH can do in this case if the remote endpoint doesn't support NAT at all.
You may want to try the nf_nat_sip module at the remote end, but it may not be the solution you're looking for
On Mon, Jul 25, 2011 at 8:48 PM, Narendra Sirugudi <nsirugudi@gmail.com> wrote:
Hi, Thanks for your reply.
Maybe my problem definition is not fully clear: For my use case, having addtional configuration on the SIP UA (softphone) side is not feasible. I am looking for solution on the Freeswitch side(sitting on the public network). Not all SIP UA clients (softphones) will have the solution of working around NAT, let alone STUN client support.
I observed the Freeswitch has some features like AutoNAT etc. Aren't these of any help for the use case i have ? I just started reading on the AutoNAT feature. The documentation of AutoNAT seems to suggest that freeswitch itself sits behind a NAT. This is not the same as my use case.
To summarize: Does freeswitch have any method of detecting that the remote SIP UA is behind a NAT and taking some action based on that ? Any suggestions are welcome.
thanks, --naren On Tue, Jul 26, 2011 at 7:09 AM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
The SIP UA only needs to be configured to use NAT in this case. The FS Server does not need any configuration in this case.
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org