Subject: [Sip] Re: WGLC comments on sip-outbound-10

From: Rohan Mahy <[email-masked]>
Date: Sat, 1 Dec 2007 12:20:11 -0800

Hi Derek,

I think I have addressed all your comments except the CRLF backward  
compatibility, which I have fixed in my working copy. See below for  
specifics.

On Aug 6, 2007, at 3:46 PM, Derek MacDonald wrote:

> I've finished my review of outbound-10, mainly thinking about things
> from a client implementation & NAT traversal perspective.
>
> Major issues:
>
> The following issues are all one part of what I think is the core
> issue w/ outbound; the draft does not require normative behavior that
> will result in successful NAT traversal, although it does contain the
> necessary mechanisms for NAT traversal
> In 4.2 and 4.3 it is stated that route-set creation is outside the
> scope of outbound.  The behavior that is would work for NAT traversal
> in a simple deployment is described as an example in 4.2.

I think this is greatly improved in -11 by the following changes:

outbound-11 now states that the edge proxy is expected to record- 
route with a flow-token if the client includes an 'ob' parameter in  
its Contact.  If the client is using gruu, it uses the gruu instead  
in its contact.  The UA now also uses rport in all requests.

I think this should be sufficient to insure responses (rport),  
incoming requests (from Path flow token in REGISTER), and in-dialog  
requests (from Record-Route flow token, or from a GRUU) all get back  
to the UA.

>> From 4.2:
>
> "Forming the route set for the request is outside the scope of
>  this document, but typically results in sending the REGISTER such
>  that the topmost Route header field contains a loose route to the
>  outbound proxy URI."
>
> Are we really anticipating that an element will be inserted between
> the UA and the outbound proxy(s).  Do we want to allow this?

no and no.  The "typically results in sending the REGISTER..." text  
is there to allow the traditional usage of an outbound proxy, which  
is to resolve the IP address, port, and transport and send it there  
without including a Route header at all.

> If there
> is such an element in the route set, it will either have to:
>
> Support outbound, which causes a single point of failure if there
> isn't a 1-1 correspondence with the edge proxies. If there is a 1-1
> correspondence with the edge proxies, it is an edge proxy, so is
> should have just been configured as the outbound proxy.
>
>  OR
>
> Transparently relay outbound, which seems like a very bad idea.
>
> I think we should change the text to something like:
>
> "While forming the route set for the request is outside the scope of
> this specification, the first element in the route set for a
> registration MUST be from the outbound-proxy-set in order to use this
> specification."

I think the current text already require that the first element  
visited (whether in the route set or not) is in the outbound-proxy-set.

> Section 4.3 Discusses how a UA would send a request, but does not
> describe the basic behavior that would establish a dialog through a
> NAT.
>
> " When a UA is about to send a request, it first performs normal
>    processing to select the next hop URI.  The UA can use a variety of
>    techniques to compute the route set and accordingly the next hop  
> URI.
>    Discussion of these techniques is outside the scope of this  
> document
>    but could include mechanisms specified in RFC 3608 [22] (Service
>    Route) and [21]."
>
> If the next hop does not support outbound, and isn't an existing flow,
> a dialog establishing request will likely result in a route set which
> does not work through a NAT.  The rport mechanism only provides NAT
> traversal for a single SIP response.

correct.  there is now text setting the responsibility clearly:
> If the registrar did not support outbound, the UA may have  
> unintentionally registered an unroutable contact. It is the  
> responsiblity of the UA to remove any inappropriate Contacts.

> "The UA performs normal DNS resolution on the next hop URI (as
>    described in RFC 3263 [4]) to find a protocol, IP address, and  
> port."
>
> As there is no mechanism to determine outbound support in other
> administrative domains, this lookup is only relevant to outbound if
> the UA knows next hop supports outbound.

yes.

> Later in the same paragraph:
>
>   "If the UA cannot use one of the existing flows,then it SHOULD  
> form a new flow
>    by sending a datagram or opening a new connection to the next  
> hop, as
>    appropriate for the transport protocol."
>
> I was under the impression that flows are only created with REGISTER
> requests...is this incorrect?

this has been changed in -11 to allow flows to be formed for dialog- 
creating requests.

> The crux of the issue is that to accomplish NAT traversal using
> outbound w/out extensions, the UA MUST send dialog creating requests
> using an existing flow(selected by round-robin for appropriate
> transport/etc).  Furthermore, in 5.3, edge proxies MUST record route
> dialog creating requests.  We need to change the base-level behaviour
> of outbound so NAT traversal just works, is this is a core requirement
> of outbound.
>
> Also:
>
>       Note that if the UA wants its flow to work through NATs or
>       firewalls it still needs to put the 'rport' parameter [10] in  
> its
>       Via header field value, and send from the port it is prepared to
>       receive on.  More general information about NAT traversal in SIP
>       is described in [23].
>
> should be removed.  [23] is very out of date, and references
> outbound-01, and I believe some of the text is out of date.  Rport is
> not relevant when flows are used, although it doesn't cause any harm.

rport is still relevant when flows are used, because outbound does  
not change the rules in 3261 for forwarding responses.

> Questions/minor issues:
>
> 4.1:
>
> "The value of this parameter MUST be a URN [8].  One case
>    where a UA may not want to include the URN in the sip.instance
> media feature tag..."
>
> Does this mean that a sip.instance feature tag is still included? If
> so, what does it contain?

no, the whole parameter should be omitted.  i think i reworded this  
to make it more clear.

> "As a result, the UA instance SHOULD provide lexically equivalent URNs
> in each registration it
> generates. "
>
> Why not MUST instead of SHOULD?
fixed

> Nits
>
> Explain why the CRLFCRLF & CRLF messages used for the PING/PONG don't
> break existing SIP implementations.  I spent a lot of time looking
> through the grammar before I gave up and asked Rohan and pointed me to
> section 7.5 of 3261.  I would reference this section in 3.5.1 and/or
> 4.4.2.

bummer.  I forgot to include this in -11.  I have added this in my  
working copy to section 3.5.1 as follows:
> Sending a CRLF over a connection-oriented transport is
>           backwards safe (because of requirements in Section 7.5 of  
> RFC 3261),
>           but only implementations which support the 'keep'  
> parameter will
>           respond to a "ping" with a "pong".

> 2.1
>
> "reg-id:  This refers to the value of a new header field parameter
>       value for the Contact header field.  When a UA registers  
> multiple
>       times, each simultaneous registration gets a unique reg-id  
> value."
>
> change simultaneous to concurrent:
>
> "reg-id:  This refers to the value of a new header field parameter
>       value for the Contact header field.  When a UA registers  
> multiple
>       times, each concurrent registration gets a unique reg-id value."
fixed

> 3.3
>
> "If a UA has multiple flows, and one of the servers fails, the UA
>    delays the specified time before trying to form a new connection to
>    replace the flow to the server that failed."
>
> This implies that if the UA only has one flow, it retries immediately
> which doesn't match the behaviour described in 4.5. Maybe:
>
> "When a server fails the UA will delay before attempting to
> re-establish a flow, using the delays specified in section 4.5."

fixed

> 3.5
>
> Change(awkward):
>
> "In this case, the server provides an indicator (the
>    'timed-keepalives' parameter) that the server requires the  
> client to
>    use the suggested timer values."
>
> to
>
> "In this case, the server indicates that the client must use the
> suggested timer values by including the timed-keepalives parameter."

i think the original text (while uglier) is more clear.

> 4.1
>
> "This means the value of the time component of the UUID can be
>       arbitrarily selected to be any time less than the time when the
>       device was manufactured.  A time of 0 (as shown in the  
> example in
>       Section 3.2) is perfectly legal as long as the device knows no
>       other UUIDs were generated at this time."
>
> I found this extremely confusing; I think it is saying that the time
> component isn't necessary(but can't be in the future) if the device
> already has a unique mac address it includes in the UUID. Why not just
> say that a time of 0 can be used if the device is guaranteed to have a
> unique MAC address at construction time?

The UA can't use time zero, if the UA generates multiple instance-ids  
and uses time zero for all of them.
In the absence of better text, I left it as is.

thanks,
-rohan

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: mohammed Ali <[email-masked]>
Date: Sun, 2 Dec 2007 01:59:56 +0300

unsubscrib > From: [email-masked]> Date: Sat, 1 Dec 2007 12:20:11 -0800> To: [email-masked]> CC: [email-masked]; [email-masked]; [email-masked]> Subject: [Sip] Re: WGLC comments on sip-outbound-10> > Hi Derek,> > I think I have addressed all your comments except the CRLF backward > compatibility, which I have fixed in my working copy. See below for > specifics.> > > On Aug 6, 2007, at 3:46 PM, Derek MacDonald wrote:> > > I've finished my review of outbound-10, mainly thinking about things> > from a client implementation & NAT traversal perspective.> >> > Major issues:> >> > The following issues are all one part of what I think is the core> > issue w/ outbound; the draft does not require normative behavior that> > will result in successful NAT traversal, although it does contain the> > necessary mechanisms for NAT traversal> > In 4.2 and 4.3 it is stated that route-set creation is outside the> > scope of outbound. The behavior that is would work for NAT traversal> > in a simple deployment is described as an example in 4.2.> > I think this is greatly improved in -11 by the following changes:> > outbound-11 now states that the edge proxy is expected to record- > route with a flow-token if the client includes an 'ob' parameter in > its Contact. If the client is using gruu, it uses the gruu instead > in its contact. The UA now also uses rport in all requests.> > I think this should be sufficient to insure responses (rport), > incoming requests (from Path flow token in REGISTER), and in-dialog > requests (from Record-Route flow token, or from a GRUU) all get back > to the UA.> > >> From 4.2:> >> > "Forming the route set for the request is outside the scope of> > this document, but typically results in sending the REGISTER such> > that the topmost Route header field contains a loose route to the> > outbound proxy URI."> >> > Are we really anticipating that an element will be inserted between> > the UA and the outbound proxy(s). Do we want to allow this?> > no and no. The "typically results in sending the REGISTER..." text > is there to allow the traditional usage of an outbound proxy, which > is to resolve the IP address, port, and transport and send it there > without including a Route header at all.> > > If there> > is such an element in the route set, it will either have to:> >> > Support outbound, which causes a single point of failure if there> > isn't a 1-1 correspondence with the edge proxies. If there is a 1-1> > correspondence with the edge proxies, it is an edge proxy, so is> > should have just been configured as the outbound proxy.> >> > OR> >> > Transparently relay outbound, which seems like a very bad idea.> >> > I think we should change the text to something like:> >> > "While forming the route set for the request is outside the scope of> > this specification, the first element in the route set for a> > registration MUST be from the outbound-proxy-set in order to use this> > specification."> > I think the current text already require that the first element > visited (whether in the route set or not) is in the outbound-proxy-set.> > > Section 4.3 Discusses how a UA would send a request, but does not> > describe the basic behavior that would establish a dialog through a> > NAT.> >> > " When a UA is about to send a request, it first performs normal> > processing to select the next hop URI. The UA can use a variety of> > techniques to compute the route set and accordingly the next hop > > URI.> > Discussion of these techniques is outside the scope of this > > document> > but could include mechanisms specified in RFC 3608 [22] (Service> > Route) and [21]."> >> > If the next hop does not support outbound, and isn't an existing flow,> > a dialog establishing request will likely result in a route set which> > does not work through a NAT. The rport mechanism only provides NAT> > traversal for a single SIP response.> > correct. there is now text setting the responsibility clearly:> > If the registrar did not support outbound, the UA may have > > unintentionally registered an unroutable contact. It is the > > responsiblity of the UA to remove any inappropriate Contacts.> > > > "The UA performs normal DNS resolution on the next hop URI (as> > described in RFC 3263 [4]) to find a protocol, IP address, and > > port."> >> > As there is no mechanism to determine outbound support in other> > administrative domains, this lookup is only relevant to outbound if> > the UA knows next hop supports outbound.> > yes.> > > Later in the same paragraph:> >> > "If the UA cannot use one of the existing flows,then it SHOULD > > form a new flow> > by sending a datagram or opening a new connection to the next > > hop, as> > appropriate for the transport protocol."> >> > I was under the impression that flows are only created with REGISTER> > requests...is this incorrect?> > this has been changed in -11 to allow flows to be formed for dialog- > creating requests.> > > The crux of the issue is that to accomplish NAT traversal using> > outbound w/out extensions, the UA MUST send dialog creating requests> > using an existing flow(selected by round-robin for appropriate> > transport/etc). Furthermore, in 5.3, edge proxies MUST record route> > dialog creating requests. We need to change the base-level behaviour> > of outbound so NAT traversal just works, is this is a core requirement> > of outbound.> >> > Also:> >> > Note that if the UA wants its flow to work through NATs or> > firewalls it still needs to put the 'rport' parameter [10] in > > its> > Via header field value, and send from the port it is prepared to> > receive on. More general information about NAT traversal in SIP> > is described in [23].> >> > should be removed. [23] is very out of date, and references> > outbound-01, and I believe some of the text is out of date. Rport is> > not relevant when flows are used, although it doesn't cause any harm.> > rport is still relevant when flows are used, because outbound does > not change the rules in 3261 for forwarding responses.> > > Questions/minor issues:> >> > 4.1:> >> > "The value of this parameter MUST be a URN [8]. One case> > where a UA may not want to include the URN in the sip.instance> > media feature tag..."> >> > Does this mean that a sip.instance feature tag is still included? If> > so, what does it contain?> > no, the whole parameter should be omitted. i think i reworded this > to make it more clear.> > > "As a result, the UA instance SHOULD provide lexically equivalent URNs> > in each registration it> > generates. "> >> > Why not MUST instead of SHOULD?> fixed> > > Nits> >> > Explain why the CRLFCRLF & CRLF messages used for the PING/PONG don't> > break existing SIP implementations. I spent a lot of time looking> > through the grammar before I gave up and asked Rohan and pointed me to> > section 7.5 of 3261. I would reference this section in 3.5.1 and/or> > 4.4.2.> > bummer. I forgot to include this in -11. I have added this in my > working copy to section 3.5.1 as follows:> > Sending a CRLF over a connection-oriented transport is> > backwards safe (because of requirements in Section 7.5 of > > RFC 3261),> > but only implementations which support the 'keep' > > parameter will> > respond to a "ping" with a "pong".> > > > 2.1> >> > "reg-id: This refers to the value of a new header field parameter> > value for the Contact header field. When a UA registers > > multiple> > times, each simultaneous registration gets a unique reg-id > > value."> >> > change simultaneous to concurrent:> >> > "reg-id: This refers to the value of a new header field parameter> > value for the Contact header field. When a UA registers > > multiple> > times, each concurrent registration gets a unique reg-id value."> fixed> > > 3.3> >> > "If a UA has multiple flows, and one of the servers fails, the UA> > delays the specified time before trying to form a new connection to> > replace the flow to the server that failed."> >> > This implies that if the UA only has one flow, it retries immediately> > which doesn't match the behaviour described in 4.5. Maybe:> >> > "When a server fails the UA will delay before attempting to> > re-establish a flow, using the delays specified in section 4.5."> > fixed> > > 3.5> >> > Change(awkward):> >> > "In this case, the server provides an indicator (the> > 'timed-keepalives' parameter) that the server requires the > > client to> > use the suggested timer values."> >> > to> >> > "In this case, the server indicates that the client must use the> > suggested timer values by including the timed-keepalives parameter."> > i think the original text (while uglier) is more clear.> > > 4.1> >> > "This means the value of the time component of the UUID can be> > arbitrarily selected to be any time less than the time when the> > device was manufactured. A time of 0 (as shown in the > > example in> > Section 3.2) is perfectly legal as long as the device knows no> > other UUIDs were generated at this time."> >> > I found this extremely confusing; I think it is saying that the time> > component isn't necessary(but can't be in the future) if the device> > already has a unique mac address it includes in the UUID. Why not just> > say that a time of 0 can be used if the device is guaranteed to have a> > unique MAC address at construction time?> > The UA can't use time zero, if the UA generates multiple instance-ids > and uses time zero for all of them.> In the absence of better text, I left it as is.> > thanks,> -rohan> > > > > > _______________________________________________> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip> This list is for NEW development of the core SIP Protocol> Use [email-masked] for questions on current sip> Use [email-masked] for new developments on the application of sip
_________________________________________________________________
Connect to the next generation of MSN Messenger 
http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline