__________________________ | | |________ ____|_____ ___________ || | | | 74.1.1.1 74.1.1.2 | | || SIP UA |---------------------| NAT Server|------------------------------------------| Freeswitch | ||________|10.10.10.10 |__________| Public Network |___________| | | 74.1.1.0 | Private Network 10.10.10.0 | |__________________________| Hi, In the above topology, the typical issue one faces is that the SDP(rtp) IP&port in SIP invite sent from the SIP UA to Freeswitch will contain the private Ip address of the SIP UA. Assuming source NAT, the typical solution is to use a STUN server in the public network, which will help the SIP UA to discover the public IP&port (for its private IP&port). The UA then sends the Invite with the SDP(RTP) IP&port set to the discovered public IP&port. (I believe Freeswitch does not have a STUN server within itself.) But suppose that we do not want to use the STUN solution. Does Freeswitch itself offer any solutions in this case ? thanks, --naren
Just in case my diagram got bungled: The use case is: Freeswitch in the public network, with a SIP UA in a private network talking to Freeswitch across a NAT Server. --naren On Tue, Jul 26, 2011 at 5:51 AM, Narendra Sirugudi <nsirugudi@gmail.com>wrote:
__________________________ | | |________ ____|_____ ___________ || | | | 74.1.1.1 74.1.1.2 | | || SIP UA |---------------------| NAT Server|------------------------------------------| Freeswitch | ||________|10.10.10.10 |__________| Public Network |___________| | | 74.1.1.0 | Private Network 10.10.10.0 | |__________________________|
Hi,
In the above topology, the typical issue one faces is that the SDP(rtp) IP&port in SIP invite sent from the SIP UA to Freeswitch will contain the private Ip address of the SIP UA.
Assuming source NAT, the typical solution is to use a STUN server in the public network, which will help the SIP UA to discover the public IP&port (for its private IP&port). The UA then sends the Invite with the SDP(RTP) IP&port set to the discovered public IP&port. (I believe Freeswitch does not have a STUN server within itself.)
But suppose that we do not want to use the STUN solution. Does Freeswitch itself offer any solutions in this case ?
thanks, --naren
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. On Mon, Jul 25, 2011 at 5:55 PM, Narendra Sirugudi <nsirugudi@gmail.com> wrote:
Just in case my diagram got bungled: The use case is: Freeswitch in the public network, with a SIP UA in a private network talking to Freeswitch across a NAT Server. --naren On Tue, Jul 26, 2011 at 5:51 AM, Narendra Sirugudi <nsirugudi@gmail.com> wrote:
__________________________ | | |________ ____|_____ ___________ || | | | 74.1.1.1 74.1.1.2 | | || SIP UA |---------------------| NAT Server|------------------------------------------| Freeswitch | ||________|10.10.10.10 |__________| Public Network |___________| | | 74.1.1.0 | Private Network 10.10.10.0 | |__________________________|
Hi,
In the above topology, the typical issue one faces is that the SDP(rtp) IP&port in SIP invite sent from the SIP UA to Freeswitch will contain the private Ip address of the SIP UA.
Assuming source NAT, the typical solution is to use a STUN server in the public network, which will help the SIP UA to discover the public IP&port (for its private IP&port). The UA then sends the Invite with the SDP(RTP) IP&port set to the discovered public IP&port. (I believe Freeswitch does not have a STUN server within itself.)
But suppose that we do not want to use the STUN solution. Does Freeswitch itself offer any solutions in this case ?
thanks, --naren
_______________________________________________ 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
I also forgot to mention that that the nf_nat_sip module in Linux replaces the STUN's server role pretty well On Mon, Jul 25, 2011 at 6:39 PM, 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.
On Mon, Jul 25, 2011 at 5:55 PM, Narendra Sirugudi <nsirugudi@gmail.com> wrote:
Just in case my diagram got bungled: The use case is: Freeswitch in the public network, with a SIP UA in a private network talking to Freeswitch across a NAT Server. --naren On Tue, Jul 26, 2011 at 5:51 AM, Narendra Sirugudi <nsirugudi@gmail.com> wrote:
__________________________ | | |________ ____|_____ ___________ || | | | 74.1.1.1 74.1.1.2 | | || SIP UA |---------------------| NAT Server|------------------------------------------| Freeswitch | ||________|10.10.10.10 |__________| Public Network |___________| | | 74.1.1.0 | Private Network 10.10.10.0 | |__________________________|
Hi,
In the above topology, the typical issue one faces is that the SDP(rtp) IP&port in SIP invite sent from the SIP UA to Freeswitch will contain the private Ip address of the SIP UA.
Assuming source NAT, the typical solution is to use a STUN server in the public network, which will help the SIP UA to discover the public IP&port (for its private IP&port). The UA then sends the Invite with the SDP(RTP) IP&port set to the discovered public IP&port. (I believe Freeswitch does not have a STUN server within itself.)
But suppose that we do not want to use the STUN solution. Does Freeswitch itself offer any solutions in this case ?
thanks, --naren
_______________________________________________ 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
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.
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
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
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
_______________________________________________ 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
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
participants (3)
-
curriegrad2004
-
David Ponzone
-
Narendra Sirugudi