BTW, the webpage says that you can find out the IP and ports used by yourself if the NAT doesn't support UPnP and make the API to use it.
Yes I believe you can create an IRTCPortManager and use GetMapping to specify your AV ports and SIP Signalling) when you are starting a session (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rtcclnt/rt c/irtcportmanager_getmapping.asp)
However the registration process (not the INVITE) does However the registration process does not appear to allow you to communicate your external address, I don't see where it allows you to do that anywhere in the API.
The problem is I don't want to support uPnP at all, I want to support non-uPnP NATS.
Thanks for the FCP link, I will look into that!
Gary
-----Original Message----- From: Jan Janak [mailto:jan@iptel.org] Sent: 03 September 2003 11:39 To: Gary Brewer Cc: serusers@lists.iptel.org Subject: Re: [Serusers] NAT & RTPPRoxy
BTW, the webpage says that you can find out the IP and ports used by yourself if the NAT doesn't support UPnP and make the API to use it.
BTW2: I am aware of one IP phone that supports UPnP: http://www.act-tel.com.tw
Those guys had UPnP testbed at the last SIPIt.
Jan.
On 03-09 11:14, Gary Brewer wrote:
Thanks Jan,
I should have made myself a little bit clearer; I am using the RTC 1.2 API
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rtcclnt/rt
c/real_time_communications_rtc_client_start_page.asp)
What I find the most interesting is -
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rtcclnt/rtc
/traversal_of_upnp_enabled_nats.asp specifically the last sentence of the third paragraph. Why I can't provide it my external IP address and port on the NAT is annoying! I wonder if it would be possible to modify the
REGISTER
message on the way to the SIP server and change the IP:Port to my external NAT address mapping - or get NATHelper to do this for me.
Gary
-----Original Message----- From: Jan Janak [mailto:jan@iptel.org] Sent: 03 September 2003 10:34 To: Gary Brewer Cc: serusers@lists.iptel.org Subject: Re: [Serusers] NAT & RTPPRoxy
Hello, comments inline. All the NAT stuff is quite complicated and whether it would work or not depends on many factors.
On 03-09 09:55, Gary Brewer wrote:
Hi,
I have come across a similar problem. I want to use the A/V facilities
of
Windows Messenger if one or both of my clients are behind a NAT. I
realise
that it seems to be impossible to get this to work if the NAT is
symmetric.
(See: RFC3489 "Applicability Statement")
That depends. It could work even with symmetric NAT if the client you are using does support symmetric signalling and RTP (I am not sure
Windows
Messenger is). That means the user agent must be ready to receive SIP requests and responses on the same port which was used as the source
port
for sending SIP messages. Also it must support symmetric RTP to make media work.
Also the user agent must create REGISTERs containing public IP of the NAT (can be determined using STUN, for example), or you would have to use nathelper module on the server.
If only one of my clients is behind a NAT then it would seem I would
have
to
communicate my NATs external address and port mapping to the non-NAT'd client (possibly with the help of STUN) in my SIP Invite SDP message. I
Yes, but Windows Messenger doesn't support STUN.
would also have to setup UDP mappings for SIP, RTP/RTCP Audio Video on
my
NAT. Are my A/V port mappings also included in the Invite SDP message?
In case of symmetrict RTP, the client in the public internet will ignore what it receives in SDP and will send media back to the same IP and port from which it comes from the other side. That makes the communication through a NAT possible, but the client behind the NAT must send first media package (that packet will open a pinhole in the NAT). Also both sides must support symmetrict RTP and the client behind the NAT must signal that it is using this approach.
If the clients do not support symmetric signalling, then some kind of "NAT configuration" would be necesarry.
For example, many user agents can be configured to use ports from a specified port range only for RTP (let's say ports 10000-10100). You can then configure your NAT box to forward all the ports from the range back to your user agent.
If both clients are NAT'd then what is the approach? I don't see how I register with the SIP server using an external NAT address (my guess is
this
is what I would have to use if I wanted anyone on the other side of the
NAT
to be able to see me). MSFT have seemed to got around this problem by recommended everyone to use uPnP enabled NATs, which will automatically
bind
to an external address on the NAT and, I assume, use this when they
register
with the SIP server.
If both clients are behind NATs then you would probably have to use an RTP proxy which will be placed in the public internet.
RTPProxy is here https://demo.portaone.com/~sobomax/PortaSIP/ how does RTPProxy help in the NAT situation, does it at all?
See the previous insertion. It could help in the case when both clients are behind NATs and it could possibly help in some other cases too.
Please correct me where I am wrong, I am still trying to get my head
around
all of this! Has anyone successfully been able to get any of the
scenarios
above working (with AV)?
There is a couple of people who are running their clients behind NATs on the mailing list, so I hope they could give you some advice.
Jan.
This email may contain material that is confidential and/or privileged.
It
is for the sole use of the intended recipient. Any review, reliance or distribution by others of the e-mail or its contents or forwarding without express permission is strictly prohibited. No contractual undertakings
are
accepted by virtue of transmission of this e-mail unless expressly stated otherwise in the text of the e-mail itself. If you are not the intended recipient, please contact the sender and delete all copies. Contact us directly or via our website at www.rawcommunications.com.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
This email may contain material that is confidential and/or privileged. It is for the sole use of the intended recipient. Any review, reliance or distribution by others of the e-mail or its contents or forwarding without express permission is strictly prohibited. No contractual undertakings are accepted by virtue of transmission of this e-mail unless expressly stated otherwise in the text of the e-mail itself. If you are not the intended recipient, please contact the sender and delete all copies. Contact us directly or via our website at www.rawcommunications.com.
OK, you can use nathelper for REGISTRATION. Ad support for non-UPnP NAT, you will have to experiment--there is no general solution that works everywhere.
Jan.
On 03-09 11:54, Gary Brewer wrote:
BTW, the webpage says that you can find out the IP and ports used by yourself if the NAT doesn't support UPnP and make the API to use it.
Yes I believe you can create an IRTCPortManager and use GetMapping to specify your AV ports and SIP Signalling) when you are starting a session (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rtcclnt/rt c/irtcportmanager_getmapping.asp)
However the registration process (not the INVITE) does However the registration process does not appear to allow you to communicate your external address, I don't see where it allows you to do that anywhere in the API.
The problem is I don't want to support uPnP at all, I want to support non-uPnP NATS.
Thanks for the FCP link, I will look into that!
Gary
-----Original Message----- From: Jan Janak [mailto:jan@iptel.org] Sent: 03 September 2003 11:39 To: Gary Brewer Cc: serusers@lists.iptel.org Subject: Re: [Serusers] NAT & RTPPRoxy
BTW, the webpage says that you can find out the IP and ports used by yourself if the NAT doesn't support UPnP and make the API to use it.
BTW2: I am aware of one IP phone that supports UPnP: http://www.act-tel.com.tw
Those guys had UPnP testbed at the last SIPIt.
Jan.
On 03-09 11:14, Gary Brewer wrote:
Thanks Jan,
I should have made myself a little bit clearer; I am using the RTC 1.2 API
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rtcclnt/rt
c/real_time_communications_rtc_client_start_page.asp)
What I find the most interesting is -
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rtcclnt/rtc
/traversal_of_upnp_enabled_nats.asp specifically the last sentence of the third paragraph. Why I can't provide it my external IP address and port on the NAT is annoying! I wonder if it would be possible to modify the
REGISTER
message on the way to the SIP server and change the IP:Port to my external NAT address mapping - or get NATHelper to do this for me.
Gary
-----Original Message----- From: Jan Janak [mailto:jan@iptel.org] Sent: 03 September 2003 10:34 To: Gary Brewer Cc: serusers@lists.iptel.org Subject: Re: [Serusers] NAT & RTPPRoxy
Hello, comments inline. All the NAT stuff is quite complicated and whether it would work or not depends on many factors.
On 03-09 09:55, Gary Brewer wrote:
Hi,
I have come across a similar problem. I want to use the A/V facilities
of
Windows Messenger if one or both of my clients are behind a NAT. I
realise
that it seems to be impossible to get this to work if the NAT is
symmetric.
(See: RFC3489 "Applicability Statement")
That depends. It could work even with symmetric NAT if the client you are using does support symmetric signalling and RTP (I am not sure
Windows
Messenger is). That means the user agent must be ready to receive SIP requests and responses on the same port which was used as the source
port
for sending SIP messages. Also it must support symmetric RTP to make media work.
Also the user agent must create REGISTERs containing public IP of the NAT (can be determined using STUN, for example), or you would have to use nathelper module on the server.
If only one of my clients is behind a NAT then it would seem I would
have
to
communicate my NATs external address and port mapping to the non-NAT'd client (possibly with the help of STUN) in my SIP Invite SDP message. I
Yes, but Windows Messenger doesn't support STUN.
would also have to setup UDP mappings for SIP, RTP/RTCP Audio Video on
my
NAT. Are my A/V port mappings also included in the Invite SDP message?
In case of symmetrict RTP, the client in the public internet will ignore what it receives in SDP and will send media back to the same IP and port from which it comes from the other side. That makes the communication through a NAT possible, but the client behind the NAT must send first media package (that packet will open a pinhole in the NAT). Also both sides must support symmetrict RTP and the client behind the NAT must signal that it is using this approach.
If the clients do not support symmetric signalling, then some kind of "NAT configuration" would be necesarry.
For example, many user agents can be configured to use ports from a specified port range only for RTP (let's say ports 10000-10100). You can then configure your NAT box to forward all the ports from the range back to your user agent.
If both clients are NAT'd then what is the approach? I don't see how I register with the SIP server using an external NAT address (my guess is
this
is what I would have to use if I wanted anyone on the other side of the
NAT
to be able to see me). MSFT have seemed to got around this problem by recommended everyone to use uPnP enabled NATs, which will automatically
bind
to an external address on the NAT and, I assume, use this when they
register
with the SIP server.
If both clients are behind NATs then you would probably have to use an RTP proxy which will be placed in the public internet.
RTPProxy is here https://demo.portaone.com/~sobomax/PortaSIP/ how does RTPProxy help in the NAT situation, does it at all?
See the previous insertion. It could help in the case when both clients are behind NATs and it could possibly help in some other cases too.
Please correct me where I am wrong, I am still trying to get my head
around
all of this! Has anyone successfully been able to get any of the
scenarios
above working (with AV)?
There is a couple of people who are running their clients behind NATs on the mailing list, so I hope they could give you some advice.
Jan.
This email may contain material that is confidential and/or privileged.
It
is for the sole use of the intended recipient. Any review, reliance or distribution by others of the e-mail or its contents or forwarding without express permission is strictly prohibited. No contractual undertakings
are
accepted by virtue of transmission of this e-mail unless expressly stated otherwise in the text of the e-mail itself. If you are not the intended recipient, please contact the sender and delete all copies. Contact us directly or via our website at www.rawcommunications.com.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
This email may contain material that is confidential and/or privileged. It is for the sole use of the intended recipient. Any review, reliance or distribution by others of the e-mail or its contents or forwarding without express permission is strictly prohibited. No contractual undertakings are accepted by virtue of transmission of this e-mail unless expressly stated otherwise in the text of the e-mail itself. If you are not the intended recipient, please contact the sender and delete all copies. Contact us directly or via our website at www.rawcommunications.com.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers