[SIPForum-techwg] NAT Traversal
Elwell, John
john.elwell at siemens.com
Thu Sep 11 08:32:12 EDT 2008
Kaushik,
OK, I understand - I think this is the technique often referred to as
latching.
As you say, it does require special support within the enterprise
network, or more specifically at the media endpoints. They need to send
UDP packets before they can receive any. They also need to keep sending
them, but of course that is true for some other techniques, e.g., ICE.
This is of particular concern for early media in the backwards
direction, where normally the calling UA would not expect to transmit
media. Also, you would need to supply SDP answer before the call is
answered, to prevent clipping of media on answer (true also for ICE).
So it seems there needs to be some negotiation before this can be used,
and if the enterprise media endpoint doesn't support it, you would have
to use a different technique. Alternatively all media could be funnelled
through a media proxy on the enterprise side, which ensures the
necessary functionality is provided, but then that entity might as well
do the SDP modification too. In other words, what an SBC would do.
I would have concerns about how this would work in more complex
situations, e.g., a call from a service provider to an enterprise, which
then gets forwarded to a destination via another service provider,
thereby traversing two NATs, one on entry to the enterprise and one on
exit.
John
> -----Original Message-----
> From: Kaushik V Shah [mailto:kaushik at ncoretech.com]
> Sent: 11 September 2008 10:49
> To: Elwell, John
> Cc: Ahmad, Syed; techwg at sipforum.org
> Subject: Re: [SIPForum-techwg] NAT Traversal
>
> 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