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

From: Rohan Mahy <[email-masked]>
Date: Sat, 1 Dec 2007 10:57:34 -0800

Hi Kevin,

I think all your comments have been addressed in outbound-11.

more inline.

thanks,
-rohan

On Aug 1, 2007, at 11:11 AM, Kevin Johns wrote:
> Hi,
>
> Here are my comments on outbound. A few technical comments and  
> several nits...
>
> Kevin
>
> Technical (minor)
> Detecting Flow Failure - I could not find any text in this section  
> which provides requirements (nor informative guidance) on when a  
> flow should be considered failed. For CRLF it can be pretty  
> straight forward given there are no re-transmission algorithms  
> going on in the background (missed a response, immediatly send  
> another CRLF before declaring a failure or immediately declare the  
> flow failed). However, STUN does have a retransmission algorithm  
> that the UA would need to implement and presumably this would need  
> to complete before a flow is considered failed?

for UDP, the flow has failed when the STUN request fails (which  
includes timing out after 7.9 secs).  Normal STUN retransmits are  
sent since these are normal STUN requests.

This is covered in sect 8, 9th paragraph.

> Edge Proxy Mechanisms - A question on edge proxy behavior when the  
> registrar does not provide an indication of outbound support in the  
> REGISTER response. Assuming that the UAC indicated outbound support  
> and placed a reg-id in the contact header, the Edge Proxy would  
> create a flow token and add that to the Path header. The registrar  
> may not support outbound, but may support the Path header and store  
> that as part of the contact/AOR binding. If this is done, how is  
> the Edge Proxy to behave if it receives a request which contains a  
> Path header with a flow token? Is it to ignore the flow token and  
> follow standard forwarding rules per 3261 or do something else (act  
> on the flow token and forward per Outbound procedures?)

It is the responsibility of the UA to cleanup any registrations that  
are unwanted.  This includes any registration that had a Path header  
with a flow token that is no longer of interest.  I added this sentence:
> 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.

> STUN Keepalive Processing - I think almost all of the points made  
> in RFC3489bis around how to define a STUN usage are addressed by  
> this section with the exception of usage of optional attributes (in  
> particular FINGERPRINT). I think it can be inferred that Outbound  
> does not require (nor recommend?) the use of optional attributes,  
> but it might be good to clarify that to ensure interoperable  
> implementations.

good point. I fixed this in section 8.

> Nits:
> Abstract - the last sentence states 'specifies the usage of  
> multiple connections'. I find this statement a bit ambiguous as it  
> does not provide any context as to what multiple connections are  
> used for?
fixed

> Introduction, 1st paragraph, last sentence states 'this  
> specification allows SIP registrations when the UA is behind such a  
> firewall or NAT'. I thought this spec was about allowing inbound  
> requests from the proxy or registrar to the UA in the presence of a  
> firewall or NAT?
fixed

> Overview, 1st sentence state 'this technique'. What technique is  
> being referred to? I assume Outbound procedures?
fixed

> Summary of mechanism, 2nd paragraph, 2nd sentence states 'A failure  
> on a particular flow can be tried again on an alternate flow".  
> Suggest rewording to state A failure to deliver a request on a  
> particular flow can be re-attempted on an alternate flow.
fixed

> Edge Proxy Keepalive Handling - This section makes it very clear  
> that STUN MUST be supported, but only implies that CRLF must be  
> supported. It would be nice to align the text for the two methods.
fixed

_______________________________________________
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: Rohan Mahy <[email-masked]>
Date: Sat, 1 Dec 2007 11:19:21 -0800

Hi John,

I think I have addressed all your issues in outbound-11 except as  
noted below.

On Aug 1, 2007, at 1:43 AM, Elwell, John wrote:
> 1. "The UA can also include a reg-id parameter which is used to allow
> the
>    registrar to detect and avoid keeping invalid contacts when a UA
>    reboots or reconnects after its old connection has failed for some
>    reason."
> Surely if outbound behaviour is required it is necessary to include
> reg-id. So it should say "The UA also includes...."

This "can include" language allows the UA to do non-outbound  
registrations (for example third-party registrations described in  
sect 4.2.1)

> 2. "When the proxy goes to forward a
>    request to a given target, it looks and finds the flows over  
> which it
>    received the registration."
> In the case being described here in 3.2 there is only a single  
> flow. Add
> ", in this case, only a single flow".

good point. fixed

> 3. "The proxy then forwards the request on
>    that flow, instead of resolving the Contact URI using the  
> procedures
>    in RFC 3263 [4] and trying to form a new flow to that contact.   
> This
>    allows the proxy to forward a request to a particular contact over
>    the same flow that the UA used to register this AOR."
> This seems a bit circular. It effectively says that by forwarding  
> on the
> existing flow it enables the proxy to forward on the existing flow! I
> think the second of these two sentences can be deleted.

done

> 4. "To convey its instance-id in both requests and responses, the UA
>    includes a "sip.instance" media feature tag as a UA characteristic
>    [7] ."
> The sending of instance-id in responses does not seem to be specified
> anywhere, so perhaps this sentence should only refer to requests.  
> On the
> other hand, perhaps the intention is to send an instance-id in a  
> contact
> in a response, as described for requests in 4.3. If so, a section on
> sending responses is required.

I believe the current text clears this up.  The registrar includes  
the instance-id parameter in the response to a register request, but  
that is just a side effect of normal operation.

> 5. "These ordinary registration requests include a distinct reg-id
>    parameter in the Contact header field."
> There is no RFC2119 language here. Shouldn't it say something like:
> "If outbound behavior is required, registration requests MUST
> include..."

we've been asked by the ADs to avoid excessive use of normative  
language, so I left the text as is.

> 6. "4.3.  Sending Requests"
> I am not sure whether this section is intended to cover all requests
> (including REGISTER requests) or requests other than REGISTER. If the
> latter, the title should be "Sending Requests other than REGISTER".
done

> 7. "The contact is formed normally in that the UAC uses the IP address
> of
>    the device (even if the device is behind a NAT)."
> This does not allow for the use of a GRUU in non-REGISTER requests.

fixed

> 8. "Note that the requirements in this section
>    applies to both REGISTER requests received from an Edge Proxy as  
> well
>    as requests received directly from the UAC."
> I think this note is intended to refer only to the current paragraph,
> not the entire section.
fixed

> 9. "then the proxy MUST send the request over the same
>    'logical flow' saved with the binding that is known to deliver data
>    to the specific target UA instance."
> It is the logical flow that is know to deliver data to the UA, not the
> binding. I think it should say:
> "then the proxy MUST send the request over the same
>    'logical flow' saved with the binding, since that flow is known to
> deliver data
>    to the specific target UA instance."
fixed

> 10. "8.  STUN Keepalive Processing"
> This section contains a mixture of requirements on a UA and  
> requirements
> on a server. It would be good practice to separate these.

we came to some consensus in Montreal to put these in a single  
section.  The section is short enough that I think the requirements  
will be clear enough to implementors.

> 11. "Note that UACs MUST NOT
>    use an ambiguous configuration option such as "Work through  
> NATs?" or
>    "Do Keepalives?" to imply next hop STUN support."
> I am not sure about RFC2119 language here. First, it does not  
> express a
> protocol requirement. Second, the whole statement is a note. Third,  
> the
> requirement is vague and hard to test. I would have thought it
> sufficient to say "should not". If RFC2119 language is really  
> considered
> necessary, it should not be stronger than "SHOULD NOT" because of the
> vagueness of the requirement.

this was added based on consensus in Montreal. kept.

> 12. "Later, after
>    the Primary reboots, The Callee discovers the flow failure and
>    reestablishes a new flow to the Primary."
> Alternatively the proxy might discover the flow failure before the
> Primary reboots, although it cannot  of course successfully re- 
> establish
> the flow until after reboot. Perhaps it should say:
> "Later, after the Primary reboots, the Callee successfully  
> reestablishes
> a new flow to the Primary. Keepalive checks and any failed attempts to
> re-establish the flow are not shown."
fixed

> 13. "The value of the reg-id MUST NOT be 0 and MUST be less than  
> 2**31."
> According to the ABNF, the value can be less than or equal to 2**31.
fixed

> NITS
> - Change "the Registrar MUST NOR" to "the Registrar MUST NOT".
> - Change "Note that the requirements in this section
>    applies" to "Note that the requirements in this section
>    apply"
all fixed

thanks,
-rohan

---

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

Hi Nils,

The example still needs to be overhauled and will address the concern  
you raised.

On Aug 5, 2007, at 9:02 AM, Nils Ohlmeier wrote:

> Hello,
>
> sorry for being with my comments. Please find one minor technical  
> issue and
> several NITs below.
>
>
> Minor Technical:
>
> 9. Example Message Flow
>
> The 200 OK on page 28 contains no Path header, which should carry
> the ob and/or the keepalive URI parameters to allow the UA to detect
> that Oubound is supported and used. How can the UA detect that
> outbound is supported and used for this flow when it receives a
> 200 OK like this one?
> In the case there is an edge proxy included which supports outbound
> the 200 OK should have the Path header with the parameters. If the
> edge proxy does not support outbound, the Path header should not
> have the parameters. If the edge proxy does not even support the
> Path extension, outbound can not be supported either.
> But how does the UA detect that the Registrar supports and uses
> outbound in case there is no edge proxy involved?
> The easiest and simple solution to me would be that the Registrar
> has to include a Path header into the reply which points to itself
> and carries the required parameters.
>
> Another alternative would be to rely only on the Suported/Required
> header and do not look at the Path URI at all. Then the keepalive
> algorithm would be implicitly determined by the used transport, but
> that would also mean that there is no way for the Registrar to let
> the UA know that it supports the optional TCP Keepalive algorithm.
> And the Supported/Required header would have to be included into
> the reply by edge proxy (in case), which is, I think, against the  
> normal
> usage of these headers.
>
>
> NITs:
>
> 1. Introduction
>
> "This specification allows SIP registration when the
> UA is behind such a firewall or NAT."
>
> Proposed improvement:
> This specification ensures that the UA if it is behind
> such a firewall or NAT is reachable by the registrar after
> the first successful initial registration.

The UA is now also allowed to form a flow for dialog-forming requests

> 2.1 Definitions
>
> "outbound-proxy-set  A set of SIP URIs...."
>
> Proposed improvement:
> outbound-proxy-set: A set of SIP URIs...

fixed

> 3.2 Single Registrar and UA
>
> "
> REGISTER sip:example.com;keep-crlf SIP/2.0
> Via: SIP/2.0/TCP 192.0.2.1;branch...
> ...
> Contact: <sip:[email-masked]>;reg-id=1;...
> "
>
> Why have Via and Contact different IPs? I assume
> this is a type and should look like this:
>
> REGISTER sip:example.com;keep-crlf SIP/2.0
> Via: SIP/2.0/TCP 192.168.0.2;branch...
> ...
> Contact: <sip:[email-masked]>;reg-id=1;...

fixed

> 3.3 Multiple Connections from a User Agent
>
> "..., so mechanism like SRV can be used..."
>
> Proposed improvement:
> ..., so mechanism like DNS SRV can be used...

fixed

> 4.1 Instance ID Creation
>
> "... as the device knows no other UUIDs were generated at this time."
>
> Proposed improvement:
> ... as the device knows no other UUIDs were generated at this
> time on this device.

fixed

> 4.2.1 Registration by Other Instances
>
> Is the second paragraph about unregister only ment for this
> particular case or for all UAs supporting this draft?
>
> To me it semms at it is ment for all UAs, as the star Contact
> should match all bindings anyway. Otherwise it should be explained
> somewhere what a star Contact with an instance-id and/or reg-id
> means.

fixed.  star with instance-id is not allowed.

> 4.4 Detecting Flow Failure
>
> The last paragraph talks about tags in the URIs of the
> outbound-proxy-set. Are these tags are still used after the Chicago
> meeting? If so, then there should be a refence to chapter 12.
ok

> 5.4 Edge Proxy Keepalive Handling
>
> Why is TCP Keepalive not mentioned in this section?
> I think it should mention that this an optional keepalive mechanism
> for the edge proxy.
fixed

> 6. Registrar Mechanisms: Processing REGISTER Requests
>
> Last paragraph on page 22:
>
> "First the registrar examines the first Path header field value,
>  if any."
>
> Proposed improvement:
> First the registrar examines the first (bottom most) Path header
> field value, if any.
I think "first" is clear enough.

> 4th paragraph on page 23:
>
> "Furthermore, the Registrar MUST NOR include this option-tag..."
>
> Fix:
> Furthermore, the Registrar MUST NOT include this option-tag...
fixed

> 8. STUN Keeplalive Processing
>
> 1st paragraph on page 26:
>
> "Typically, a SIP node first sends a SIP request and waits to
> receive a final response (other than a 408 response) over a flow
> to a new target destination, before sending any STUN messages."
>
> Why should an UA start sending any STUN messages when it received
> any non-2xx reply?
> I think the sentence above should be limited to 2xx responses only
> as indication that the flow is "established" and the UA can send
> STUN messages now.
good point. fixed

> 12.2 SIP/SIPS URI Parameters
>
> Why is there no Parameter for the optional TCP Keepalive?
> Or should the sections talking about TCP Keepalive as an optional
> alternative be deleted from the document?

TCP keepalive references have been removed from the document.  The UA  
can always use TCP keepalives, but the UA cannot know that the next  
hop will respond (this is a ping with no pong).

thanks,
-rohan