Subject: [Sip] Outbound-12 comments

From: "Kevin Johns" <[email-masked]>
Date: Mon, 10 Mar 2008 12:26:37 -0600

All,
 
I did a review of outbound, please find my comments below. This review
is for sections 4-8 and the comments are primarily related to tightening
up the procedures.

Comments are formatted as follows - <section #>, <section title>,
<optional text location> - comment...
 
Regards,
Kevin
 
Section 4.2.1, Initial Registration, 2nd para - Is the opening sentence
well understood by all? "For each outbound proxy URI in the set, the UA
SHOULD send a unique REGISTER in the normal way using this URI as the
default outbound proxy."

Section 4.2.1, Initial Registration - this section makes no reference to
the keep-timer. It would seem that this should be discussed in the same
context as detecting outbound support in the registration response? It
is covered in section 4.4 but seems out of place as a first reference.

Section 4.2.2, Subsequent REGISTER requests, The first sentence -
"Re-registrations and single Contact de-registrations use the same
instance-id and reg-id values as the corresponding initial
registration." Suggest making this normative

Section 4.3, Sending Non-REGISTER Requests, 1st paragraph - "UAs that
support this specification SHOULD include the outbound option tag in a
Supported header field in a non-Register REGISTER request." What is a
non-Register REGISTER request? Further why is this recommended? I did
not see this information being used by the edge proxy elsewhere in the
document?

Section 4.4, Keep-alives and Detecting Flow Failure, 2nd paragraph -
"When a successful registration response contains the Flow-Timer header
field..." This is the first reference to the Flow-Timer header and it is
unclear in the context of this section what a successful registration
response is. While a proxy is only allowed to insert this in a response
containing the outbound option-tag in a Require header field, it would
seem reasonable to indicate that it is only used by the UA if outbound
support is also signaled. However this may cross with the current thread
on keep-alive usage and that a proxy may choose to use keep-alives
without outbound and have a desire to control their rate of arrival?

Section 4.4, Keep-alives and Detecting Flow Failure, 2nd paragraph -
"For example, it the server suggests 120 seconds, the UA would send each
keepalive with a different frequency between 95 and 120 seconds." I
think 'it' should be 'if'.

Section 5.4, Edge Proxy Keep alive Handling, last paragraph - should
recommended timer values be provided which align with the UA recommended
values in absence of the Flow-Timer value?

Section 6, Registrar Mechanisms: Processing REGISTER Requests - this
section has no discussion on action taken on receipt of a 430 response.
Section 7 (Authoritative Proxy Mechanisms: Forwarding Requests - last
para) does talk about invalidating bindings to invalid flows but does
not reference a 430 response as one possible methods for determining a
failed flow/binding. I am not sure which section should address this but
some text does need to be added to cover this cause.
_______________________________________________
Sip mailing list  https://www.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: "Francois Audet" <[email-masked]>
Date: Mon, 17 Mar 2008 19:12:12 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Kevin Johns
> Sent: Monday, March 10, 2008 11:27
> To: [email-masked]
> Subject: [Sip] Outbound-12 comments
> 
> All,
>  
> I did a review of outbound, please find my comments below. 
> This review is for sections 4-8 and the comments are 
> primarily related to tightening up the procedures.
> 
> Comments are formatted as follows - <section #>, <section 
> title>, <optional text location> - comment...
>  
> Regards,
> Kevin
>  
> Section 4.2.1, Initial Registration, 2nd para - Is the 
> opening sentence well understood by all? "For each outbound 
> proxy URI in the set, the UA SHOULD send a unique REGISTER in 
> the normal way using this URI as the default outbound proxy."

I think it's clear. What do you propose we change?

> Section 4.2.1, Initial Registration - this section makes no 
> reference to the keep-timer. It would seem that this should 
> be discussed in the same context as detecting outbound 
> support in the registration response? It is covered in 
> section 4.4 but seems out of place as a first reference.

You mean the Flow-Timer? I'm not sure why we would want to discuss the
Flow-Timer in the section about Registration. Can you be more 
specific on what you are looking for?

> Section 4.2.2, Subsequent REGISTER requests, The first 
> sentence - "Re-registrations and single Contact 
> de-registrations use the same instance-id and reg-id values 
> as the corresponding initial registration." Suggest making 
> this normative

You mean saying:
"Re-registrations and single Contact 
 de-registrations MUST use the same instance-id and reg-id values 
 as the corresponding initial registration."

Rohan?

> Section 4.3, Sending Non-REGISTER Requests, 1st paragraph - 
> "UAs that support this specification SHOULD include the 
> outbound option tag in a Supported header field in a 
> non-Register REGISTER request." What is a non-Register 
> REGISTER request? 

I think this is a typo: it should say "non-Register request.".

> Further why is this recommended? I did not 
> see this information being used by the edge proxy elsewhere 
> in the document?

That is a good question. Rohan? Cullen?

> Section 4.4, Keep-alives and Detecting Flow Failure, 2nd 
> paragraph - "When a successful registration response contains 
> the Flow-Timer header field..." This is the first reference 
> to the Flow-Timer header and it is unclear in the context of 
> this section what a successful registration response is. 
> While a proxy is only allowed to insert this in a response 
> containing the outbound option-tag in a Require header field, 
> it would seem reasonable to indicate that it is only used by 
> the UA if outbound support is also signaled. However this may 
> cross with the current thread on keep-alive usage and that a 
> proxy may choose to use keep-alives without outbound and have 
> a desire to control their rate of arrival?

Correct. It would cross with the current tread on keep-alive usage.

> Section 4.4, Keep-alives and Detecting Flow Failure, 2nd 
> paragraph - "For example, it the server suggests 120 seconds, 
> the UA would send each keepalive with a different frequency 
> between 95 and 120 seconds." I think 'it' should be 'if'.

Correct.

> Section 5.4, Edge Proxy Keep alive Handling, last paragraph - 
> should recommended timer values be provided which align with 
> the UA recommended values in absence of the Flow-Timer value?

I'm not sure it would be useful, as omitting the Flow-Timer
altogether would have the same result (and would use less
bytes in messages).

> Section 6, Registrar Mechanisms: Processing REGISTER Requests 
> - this section has no discussion on action taken on receipt 
> of a 430 response.

Correct. It describes UAS not UAC.

> para) does talk about invalidating bindings to invalid flows 
> but does not reference a 430 response as one possible methods 
> for determining a failed flow/binding. I am not sure which 
> section should address this but some text does need to be 
> added to cover this cause.

Yes, it may need some improvements.

---

From: "Kevin Johns" <[email-masked]>
Date: Thu, 20 Mar 2008 15:00:49 -0600

Francois,

Thanks for your responses, my responses are identified by <kcj>.

Kevin

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: Monday, March 17, 2008 6:12 PM
To: Kevin Johns; [email-masked]
Cc: Rohan Mahy; Cullen Jennings
Subject: RE: [Sip] Outbound-12 comments

> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Kevin Johns
> This review is for sections 4-8 and the comments are primarily related

> to tightening up the procedures.
> 
> Section 4.2.1, Initial Registration, 2nd para - Is the opening 
> sentence well understood by all? "For each outbound proxy URI in the 
> set, the UA SHOULD send a unique REGISTER in the normal way using this

> URI as the default outbound proxy."

I think it's clear. What do you propose we change?
<kcj> I was not necessarily proposing a change. I just wanted to make
sure folks were comfortable with the language 'a unique REGISTER in the
normal way'. When I read this it was unclear to me what unique was
referring to? Is the REGISTER unique in that each must have a different
reg-id or that a unique call-id is used or both? Further if the normal
way is RFC 3261 then why not state a REGISTER per RFC 3261 with the
following enhancements...?

> Section 4.2.1, Initial Registration - this section makes no reference 
> to the keep-timer. It would seem that this should be discussed in the 
> same context as detecting outbound support in the registration 
> response? It is covered in section 4.4 but seems out of place as a 
> first reference.

You mean the Flow-Timer? I'm not sure why we would want to discuss the
Flow-Timer in the section about Registration. Can you be more specific
on what you are looking for?
<kcj> Yes I meant flow-timer, sorry for the confusion. Given there is
text in 4.2.1 to examine the registration response for presence of the
outbound option-tag it seemed reasonable to identify all the parameters
the UA should look for in the response. No big deal if folks are
comfortable with the current text.

You mean saying:
"Re-registrations and single Contact
 de-registrations MUST use the same instance-id and reg-id values  as
the corresponding initial registration."
<kcj> Yes this is my suggestion

Rohan?

> non-Register REGISTER request?

> Further why is this recommended? I did not see this information being 
> used by the edge proxy elsewhere in the document?

> "When a successful registration response contains the Flow-Timer 
> header field..." This is the first reference to the Flow-Timer header 
> and it is unclear in the context of this section what a successful 
> registration response is.
> While a proxy is only allowed to insert this in a response containing 
> the outbound option-tag in a Require header field, it would seem 
> reasonable to indicate that it is only used by the UA if outbound 
> support is also signaled. However this may cross with the current 
> thread on keep-alive usage and that a proxy may choose to use 
> keep-alives without outbound and have a desire to control their rate 
> of arrival?

> "For example, it the server suggests 120 seconds, the UA would send 
> each keepalive with a different frequency between 95 and 120 seconds."

> I think 'it' should be 'if'.

Correct.

> recommended timer values be provided which align with the UA 
> recommended values in absence of the Flow-Timer value?

I'm not sure it would be useful, as omitting the Flow-Timer altogether
would have the same result (and would use less bytes in messages).
<kcj> OK

> - this section has no discussion on action taken on receipt of a 430 
> response.

Correct. It describes UAS not UAC.
<kcj> I am no longer sure why I called this out, especially given my
comment below on section 7.

> failed flow/binding. I am not sure which section should address this 
> but some text does need to be added to cover this cause.

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Thu, 20 Mar 2008 15:25:09 -0600

>>That is a good question. Rohan? Cullen?

[S] An example of a non-REGISTER request is a SIP SUBSCRIBE message. I
am guessing this requirement refers to the use of outbound in such
cases. (We use the 'ob' parameter within the SIP Configuration
Framework.)

- S

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 20 Mar 2008 16:26:51 -0500

Like the SUBSCRIBE in the example call flow section (the first one). 

> From: Sumanth Channabasappa [mailto:[email-masked]] 
> Sent: Thursday, March 20, 2008 14:25
> To: Kevin Johns; Audet, Francois (SC100:3055); [email-masked]
> Cc: Cullen Jennings; Rohan Mahy
> "UAs that 
> [S] An example of a non-REGISTER request is a SIP SUBSCRIBE 
> message. I am guessing this requirement refers to the use of 
> outbound in such cases. (We use the 'ob' parameter within the 
> SIP Configuration
> Framework.)
> 
> 
> - S
>

---

From: "Kevin Johns" <[email-masked]>
Date: Thu, 20 Mar 2008 15:27:33 -0600

Sumanth,

Right, but the question is why is this recommended and how is it used by
the Edge Proxy?

Kevin 

-----Original Message-----
From: Sumanth Channabasappa 
Sent: Thursday, March 20, 2008 3:25 PM
To: Kevin Johns; Francois Audet; [email-masked]
Cc: Cullen Jennings; Rohan Mahy
Subject: RE: [Sip] Outbound-12 comments

- S

---

From: "Kevin Johns" <[email-masked]>
Date: Thu, 20 Mar 2008 15:33:33 -0600

So this would seem to imply that the presence of outbound in the support
header indicates that a flow should be established and the Edge Proxy
record route with a flow token in order for the resulting NOTIFY to be
delivered in the absence of the UA having registered?

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Thu, 20 Mar 2008 15:41:55 -0600

Kevin,

That is my understanding. This would support bootstrapping configuration
(prior to registration).

- S

---

From: "Kevin Johns" <[email-masked]>
Date: Thu, 20 Mar 2008 15:43:10 -0600

Ok, so I don't recall any of this being discussed in outbound. So I
think some text is in order to explain why the UA includes this and what
the edge proxy is expected to do as a result.

Kevin 

-----Original Message-----
From: Sumanth Channabasappa 
Sent: Thursday, March 20, 2008 3:42 PM
To: Kevin Johns; 'Francois Audet'; [email-masked]'
Cc: 'Cullen Jennings'; 'Rohan Mahy'
Subject: RE: [Sip] Outbound-12 comments

Kevin,

- S

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 20 Mar 2008 16:47:53 -0500

See below. I've trimmed the things we are either fixing already or where 
we have closed.

> From: Kevin Johns [mailto:[email-masked]] 
> Sent: Thursday, March 20, 2008 14:01
> To: Audet, Francois (SC100:3055); [email-masked]
> <kcj> I was not necessarily proposing a change. I just wanted 
> to make sure folks were comfortable with the language 'a 
> unique REGISTER in the normal way'. When I read this it was 
> unclear to me what unique was referring to? Is the REGISTER 
> unique in that each must have a different reg-id or that a 
> unique call-id is used or both? Further if the normal way is 
> RFC 3261 then why not state a REGISTER per RFC 3261 with the 

What about this:

	For each outbound proxy URI in the set, the UAC SHOULD send 
	a REGISTER request using this URI as the outbound proxy.

> reference 
> You mean the Flow-Timer? I'm not sure why we would want to 
> discuss the Flow-Timer in the section about Registration. Can 
> you be more specific on what you are looking for?
> <kcj> Yes I meant flow-timer, sorry for the confusion. Given 
> there is text in 4.2.1 to examine the registration response 
> for presence of the outbound option-tag it seemed reasonable 
> to identify all the parameters the UA should look for in the 
> response. No big deal if folks are comfortable with the current text.

Yes, but there is already a forward reference to 4.4. It says:

	If outbound registration succeeded, as indicated by the presence of
	the outbound option-tag in the Require header field of a successful
	registration response, the UA begins sending keepalives as 
	described in Section 4.4."

>  de-registrations MUST use the same instance-id and reg-id 
> values  as the corresponding initial registration."

I'm OK with this recommendation.

---

From: "Kevin Johns" <[email-masked]>
Date: Thu, 20 Mar 2008 15:52:33 -0600

Just one further thought on the first topic below, otherwise I am ok
with the rest.

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: Thursday, March 20, 2008 3:48 PM
To: Kevin Johns; [email-masked]
Cc: Rohan Mahy; Cullen Jennings
Subject: RE: [Sip] Outbound-12 comments

> sure folks were comfortable with the language 'a unique REGISTER in 
> the normal way'. When I read this it was unclear to me what unique was

> referring to? Is the REGISTER unique in that each must have a 
> different reg-id or that a unique call-id is used or both? Further if 
> the normal way is RFC 3261 then why not state a REGISTER per RFC 3261 
> with the following enhancements...?

What about this:

	For each outbound proxy URI in the set, the UAC SHOULD send 
	a REGISTER request using this URI as the outbound proxy.
<kcj> This is good. Can we further clarify that the UAC MUST attempt to
register at least one or is that just plain obvious?

> outbound option-tag it seemed reasonable to identify all the 
> parameters the UA should look for in the response. No big deal if 
> folks are comfortable with the current text.

	If outbound registration succeeded, as indicated by the presence
of
	the outbound option-tag in the Require header field of a
successful
	registration response, the UA begins sending keepalives as 
	described in Section 4.4."

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 20 Mar 2008 14:10:05 -0800 (PST)

Hi Kevin,

Its already there.  UA behavior from the 3rd paragraph of Section 4.3:

>If the UAC is sending a dialog-forming request, and wants all subsequent
>requests in the dialog to arrive over the same flow, the UAC adds an 'ob'
>parameter to its Contact header. Typically this is desirable, but it is
>not necessary for example if the Contact is a [GRUU]. The flow used for
>the request is typically the same flow the UA registered over, but it
>could be a new flow, for example the initial subscription dialog for the
>[configuration framework] needs to exist before registration.

Edge proxy behavior is the same as that for any other dialog forming
request and is described in the last paragraph of Section 5.3.

thanks,
-rohan

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 20 Mar 2008 17:12:53 -0500

I think it's pretty obvious if you don't register at least one,
you won't get any calls.

But ok for the mofidified text. 

> Sent: Thursday, March 20, 2008 14:53
> Just one further thought on the first topic below, otherwise 
> I am ok with the rest.
> 
> See below. I've trimmed the things we are either fixing 
> already or where we have closed.
> 
> <kcj> This is good. Can we further clarify that the UAC MUST 
> attempt to register at least one or is that just plain obvious?
> 
> discuss the

---

From: "Kevin Johns" <[email-masked]>
Date: Thu, 20 Mar 2008 16:16:31 -0600

Right but these talk about adding 'ob' to the contact header. The text I
am referring to (1st para in section 4.3) talks about including the
outbound option-tag in the supported header. I guess this goes in
conjunction with including the ob parameter in the contact header? If
that is the case I did not make the connection till just now.

Kevin 

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Thursday, March 20, 2008 4:10 PM
To: Kevin Johns
Cc: Sumanth Channabasappa; Francois Audet; [email-masked]; Cullen
Jennings; Rohan Mahy

Hi Kevin,

> think some text is in order to explain why the UA includes this and 
> what the edge proxy is expected to do as a result.

Its already there.  UA behavior from the 3rd paragraph of Section 4.3:

>If the UAC is sending a dialog-forming request, and wants all 
>subsequent requests in the dialog to arrive over the same flow, the UAC
adds an 'ob'

>could be a new flow, for example the initial subscription dialog for 
>the [configuration framework] needs to exist before registration.

thanks,
-rohan

> That is my understanding. This would support bootstrapping 
> configuration (prior to registration).
>
> - S
>
> So this would seem to imply that the presence of outbound in the 
> support header indicates that a flow should be established and the 
> Edge Proxy record route with a flow token in order for the resulting 
> NOTIFY to be delivered in the absence of the UA having registered?
>

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 20 Mar 2008 15:03:27 -0800 (PST)

Hi,

Two comments inline.

> 	a REGISTER request using this URI as the outbound proxy.

I'm OK with "... a REGISTER request (with a unique Call-ID), using ..."

We added "unique" at someone's request because he was no sure if he should
use the same call-id and tags.

> I'm OK with this recommendation.

I'm not happy with this MUST.

The quoted statement already *is* normative.  It is not necessary to
include a MUST statement to make a statement normative.  Excessive and
unnecessary use of RFC 2119 language impairs clarity and readability.
Based on several requests from readers, I removed a lot of extraneous
MUSTs and the spec was much easier to read.

thanks,
-rohan

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 20 Mar 2008 18:14:00 -0500

> The quoted statement already *is* normative.  It is not 
> necessary to include a MUST statement to make a statement 
> normative.  Excessive and unnecessary use of RFC 2119 
> language impairs clarity and readability.
> Based on several requests from readers, I removed a lot of 
> extraneous MUSTs and the spec was much easier to read.

I think the point is that we are not adding really a new requirement here.

It's more like we are stating what is a re-registration in the context of insteance-id.

So I agree with Rohan.

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 20 Mar 2008 15:38:53 -0800 (PST)

Kevin,

You *always* include Supported: outbound if you support outbound.  This is
just normal RFC 3261 option-tag behavior.  This has no special
relationship with the 'ob' parameter.

thanks,
-rohan

---

From: Dean Willis <[email-masked]>
Date: Thu, 20 Mar 2008 19:41:45 -0500

> that is the case I did not make the connection till just now.

Strictly speaking, one includes in every Supported every extension  
that one supports, whether one is using it now or not. We seem to keep  
forgetting this. I didn't much like this approach, but it's what we  
have.

--
Dean