[SIPForum-techwg] NAT Traversal
Kaushik V Shah
kaushik at ncoretech.com
Thu Sep 11 05:49:19 EDT 2008
John,
Enterprise NAT will be traversed successfully as follows:
C1 ---- MP1 ------ MP2 ------ C2
When C1 sends media packet to MP1 (media proxy), it creates NAT binding
between
C1 and MP1. Also, MP1 makes note of which <ip address, port> from where
it received
the media packet. So when packet from C2 arrives at MP1 (via MP2), it is
forwarded
on same <ip address, port> from where MP1 received media packet from C1.
Since the binding is bidirectional, the media packet from MP1 reaches C1.
When media flow is not bidirectional, C1 and/or C2 are not sending media
packets.
In this case, they need to keep sending the keep-alive media packets to
MP1 and/or MP2
respectively. Not sure if there is a draft for what keep-alive media
packet contents could be.
Regards,
Kaushik
Elwell, John wrote:
> Kaushik,
>
> What you propose does not seem to be precluded by the draft. What is
> provided on the service provider side is outside the scope of the draft.
> However, I don't see how this helps with traversing NATs on the
> enterprise side.
>
> John
>
>
>> -----Original Message-----
>> From: Kaushik V Shah [mailto:kaushik at ncoretech.com]
>> Sent: 11 September 2008 10:04
>> To: Elwell, John
>> Cc: Ahmad, Syed; techwg at sipforum.org
>> Subject: Re: [SIPForum-techwg] NAT Traversal
>>
>> John,
>>
>> Essentially, Service Provider's Proxy will do following:
>>
>> 1. IP address in Sdp will be changed to reflect use of RTP proxying
>> server (could
>> be the STUN relay server of Service Provider).
>> 2. All RTP packets will go through this server.
>>
>> Actually, this is what is running on "iptel.org" public server.
>>
>> The advantage of this is that the solution works across both
>> symmetric
>> and asymmetric
>> NAT and does not require STUN/ICE at CPE.
>>
>> And Service Provider may also prefer this as it can regulate
>> how media
>> flows, which
>> in turn can help meet SLAs.
>>
>> Regards,
>> Kaushik
>>
>> Elwell, John wrote:
>>
>>> Kaushik,
>>>
>>> Can you describe what you mean?
>>>
>>> John
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Kaushik V Shah [mailto:kaushik at ncoretech.com]
>>>> Sent: 11 September 2008 09:36
>>>> To: Elwell, John
>>>> Cc: Ahmad, Syed; techwg at sipforum.org
>>>> Subject: Re: [SIPForum-techwg] NAT Traversal
>>>>
>>>>
>>>> Can we propose "Symmetric RTP (media) proxying by Service Provider"
>>>> as a way to work across NAT?
>>>>
>>>> Regards,
>>>> Kaushik
>>>>
>>>> Elwell, John wrote:
>>>>
>>>>
>>>>> Syed,
>>>>>
>>>>> If I recall correctly, the discussion during the writing of
>>>>>
>>>>>
>>>> SIPconnect
>>>>
>>>>
>>>>> 1.0 went along the lines of leaving it to the enterprise
>>>>>
>>>>>
>>>> network how to
>>>>
>>>>
>>>>> populate IP addresses and ports in SDP, e.g., using
>>>>>
>>>>>
>>>> ICE/STUN or using an
>>>>
>>>>
>>>>> SBC. I think this is what the current text tries to express.
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: techwg-bounces at sipforum.org
>>>>>> [mailto:techwg-bounces at sipforum.org] On Behalf Of Ahmad, Syed
>>>>>> Sent: 10 September 2008 17:00
>>>>>> To: techwg at sipforum.org
>>>>>> Subject: [SIPForum-techwg] NAT Traversal
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> Sorry if this issue is already addressed in the spec.
>>>>>> Reference Section
>>>>>> 7 (Firewall and NAT Traversal)
>>>>>>
>>>>>> Is there a recommended standard as per the spec that would
>>>>>> translate as
>>>>>> requiring CPEs to support:
>>>>>> A. STUN (as per latest RFC)
>>>>>> B. ICE
>>>>>> C. TURN, or anything else ?
>>>>>>
>>>>>> In a typical deployment - I assume that customer has a separate
>>>>>> Router/Firewall/NAT and the SIP CPE (e.g. an IP PBX) would
>>>>>>
>>>>>>
>>>> be behind
>>>>
>>>>
>>>>>> this edge router. Can I assume that this edge router has ALG
>>>>>> feature as
>>>>>> well ?
>>>>>>
>>>>>> As most SIP Service Providers will be using some form of
>>>>>>
>>>>>>
>>>> SBC (Session
>>>>
>>>>
>>>>>> Border Controller) - and setting up account between the
>>>>>>
>>>>>>
>>>> CPE and the SP
>>>>
>>>>
>>>>>> would result in a trust relationship between the two - is A,
>>>>>> or B or any
>>>>>> other related feature required as per spec (i.e MUST) - or
>>>>>>
>>>>>>
>>>> will it be
>>>>
>>>>
>>>>>> left to SIP SPs implementation on a case-by-case basis.
>>>>>>
>>>>>>
>>>>>> - Would appreciate if someone can point me in the right direction
>>>>>> please.
>>>>>>
>>>>>> Thanks in advance
>>>>>>
>>>>>> - Syed
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> PANASONIC COMMUNICATIONS COMPANY (U.K.) LTD.
>>>>>> Is a legal company registered in England & Wales
>>>>>> Registration Number 2030567
>>>>>> Registered Office:
>>>>>> Pencarn Way,
>>>>>> Duffryn,
>>>>>> Newport.
>>>>>> South Wales.
>>>>>> NP10 8YE
>>>>>> United Kingdom
>>>>>>
>>>>>>
>>>>>> ..............................................................
>>>>>> ................
>>>>>> Confidentiality Notice
>>>>>> The information contained in this Email, and any attachments,
>>>>>> is intended for the named recipients only. It may contain
>>>>>> confidential and/or legally privileged information. If you
>>>>>> are not the intended recipient, you must not copy, store,
>>>>>> distribute or take any action in reliance on it. Any views
>>>>>> expressed do not necessarily reflect the views of the company.
>>>>>>
>>>>>> If you receive this Email by mistake, please advise the
>>>>>> sender by using the reply facility in your Email software and
>>>>>> then delete it.
>>>>>> ..............................................................
>>>>>> ...............
>>>>>>
>>>>>> _______________________________________________
>>>>>> techwg mailing list
>>>>>> Send mail to: techwg at sipforum.org
>>>>>> Unsubscribe or edit options at:
>>>>>> http://sipforum.org/mailman/listinfo/techwg
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> techwg mailing list
>>>>> Send mail to: techwg at sipforum.org
>>>>> Unsubscribe or edit options at:
>>>>>
>>>>>
>>>> http://sipforum.org/mailman/listinfo/techwg
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>> The information contained in this electronic message and any
>>>> attachments to this message are intended for the exclusive
>>>> use of the addressee(s) and may contain proprietary,
>>>> confidential or privileged information. If you are not the
>>>> intended recipient, you should not disseminate, distribute or
>>>> copy this e-mail. Please notify the sender immediately and
>>>> destroy all copies of this message and any attachments
>>>> contained in it.
>>>>
>>>>
>>>>
>>>
>>>
>> The information contained in this electronic message and any
>> attachments to this message are intended for the exclusive
>> use of the addressee(s) and may contain proprietary,
>> confidential or privileged information. If you are not the
>> intended recipient, you should not disseminate, distribute or
>> copy this e-mail. Please notify the sender immediately and
>> destroy all copies of this message and any attachments
>> contained in it.
>>
>>
>
>
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.
More information about the techwg
mailing list