Subject: [Sip] Review of sip-outbound-13

From: "Elwell, John" <[email-masked]>
Date: Fri, 04 Apr 2008 15:00:53 +0100

I think this is ready to go if the following minor comments are
addressed:

1. "This
   specification also defines multiple keep alive schemes."
Change "multiple" to "two".

2. "A Flow is a network protocol layer (layer 4) association"
Change "network" to "transport".

3. "One case where a UA may not want to include
   the sip.instance media feature tag at all is when it is making an
   anonymous request or some other privacy concern requires that the UA
   not reveal its identity."
There is no statement about what should be done in this case.

4. "These registration requests include a distinct reg-id parameter in
   the Contact header field."
I think some normative language is needed here. Perhaps change to:
"For registration requests in accordance with outbound behaviour, the UA
MUST include a distinct reg-id parameter in the Contact header field."

5. "the target first
   hop SIP note"
Change "note" to "node".

6. "as this is already allowed by
   [RFC3261].  Section 7.5, however a UA that did not register using
   outbound registration"
I think this should say
"as this is already allowed by
   [RFC3261] section 7.5. However, a UA that did not register using
   outbound registration"

7. "Configuration indicating keepalive support for a specific target is
   considered an explicit indication.  If these conditions are
   satisfied, the UA sends its keepalives according to the same
   guidelines described in the rest of this section as UAs which
   register."
I don't understand the meaning of the first sentence. Is it trying to
say that configuration is an alternative way of determining support for
keepalive?

8. "For devices where power is
   not a significant concern, the UA SHOULD select a random number
   between 95 and 120 seconds between keepalives.  When battery power is
   a concern, the UA SHOULD select a random number between 672 and 840
   seconds (14 minutes).  These times MAY be configurable."
The last sentence seems to undermine the previous SHOULD strength
statements. Also, what exactly can be configurable - just the upper and
lower bounds? I don't think, for example, we are proposing to allow
somebody to configure say 180 seconds as both upper and lower bounds
(not a range, no randomisation). So I think it is the bounds that can be
configurable, and even then the 20% difference must be maintained.
Perhaps it should say something like:
"The UA MUST select a random number between a fixed or configurable
upper bound and a lower bound, where the lower bound is 20% less then
the upper bound. The fixed upper bound or the default configurable upper
bound SHOULD be 120 seconds (95 seconds lower bound) where battery power
is not a concern and 840 seconds (672 seconds lower bound) where battery
power is a concern."

9. "The delay time is computed by selecting a uniform random time
between
   50 and 100 percent of the wait time.  The UA MUST wait for the value
   of the delay time before trying another registration to form a new
   flow for that URI."
I find this a little confusing. The several paragraphs before that have
all talked about wait time, or time to wait, which suggests that that is
how long you wait before trying registration again. Then we suddenly
have this "delay time" introduced, and it says that "UA MUST wait for
the value of the delay time before trying another registration". It
might be better to introduce the concept of delay time and wait time up
front. Furthermore, it is not clear whether the delay time (between 50
and 100 percent of the wait time) starts when the wait time starts or
when the wait time finishes. I think the examples given in the
succeeding paragraph suggest it is the former interpretation. In any
case, it needs to be clarified.

10. "The Edge Proxy can determine
   if it is the first hop by examining the Via header field."
Does this still work in the case of topology hiding by an upstream
entity?

11. "When a '+sip.instance' media feature parameter is present in a
   Contact header field of a REGISTER request (after the Contact header
   validation as described above), the corresponding binding is between
   an AOR and the combination of the instance-id (from the +sip.instance
   media feature parameter) and the value of reg-id parameter if it is
   present."
I think the normative statements that follow are only concerned with the
case where reg-id is present, so I think it should be changed to:
"When a '+sip.instance' media feature parameter and a reg-id parameter
are present in a
   Contact header field of a REGISTER request (after the Contact header
   validation as described above), the corresponding binding is between
   an AOR and the combination of the instance-id (from the +sip.instance
   media feature parameter) and the value of reg-id parameter."

John

_______________________________________________
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: Fri, 4 Apr 2008 18:37:59 -0500

Thank you John.

I am OK with your edits 1, 2, 4, 5, 6, 8 and 11.

I don't understand your point about 3.

For 7, it should say "A configuration option indicating...".

For 9, I'll have to defer to Rohan and Cullen because I find it
confusing too.

For 10, I believe that it would work if an upstream evil B2BUA does
topology hiding since the proxy uses the Via in the Request and not the 
Path in the response.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Elwell, John
> Sent: Friday, April 04, 2008 07:01
> To: IETF SIP List
> Subject: [Sip] Review of sip-outbound-13
> 
> "For registration requests in accordance with outbound 
> behaviour, the UA MUST include a distinct reg-id parameter in 
> I don't understand the meaning of the first sentence. Is it 
> trying to say that configuration is an alternative way of 
> determining support for keepalive?
> 
> The last sentence seems to undermine the previous SHOULD 
> strength statements. Also, what exactly can be configurable - 
> just the upper and lower bounds? I don't think, for example, 
> we are proposing to allow somebody to configure say 180 
> seconds as both upper and lower bounds (not a range, no 
> randomisation). So I think it is the bounds that can be 
> "The UA MUST select a random number between a fixed or 
> configurable upper bound and a lower bound, where the lower 
> bound is 20% less then the upper bound. The fixed upper bound 
> or the default configurable upper bound SHOULD be 120 seconds 
> (95 seconds lower bound) where battery power is not a concern 
> and 840 seconds (672 seconds lower bound) where battery power 
> is a concern."
> 
> 9. "The delay time is computed by selecting a uniform random 
> time between
> I find this a little confusing. The several paragraphs before 
> that have all talked about wait time, or time to wait, which 
> suggests that that is how long you wait before trying 
> registration again. Then we suddenly have this "delay time" 
> introduced, and it says that "UA MUST wait for the value of 
> the delay time before trying another registration". It might 
> be better to introduce the concept of delay time and wait 
> time up front. Furthermore, it is not clear whether the delay 
> time (between 50 and 100 percent of the wait time) starts 
> when the wait time starts or when the wait time finishes. I 
> think the examples given in the succeeding paragraph suggest 
> it is the former interpretation. In any case, it needs to be 
> clarified.
> 
> Does this still work in the case of topology hiding by an 
> upstream entity?
> 
> I think the normative statements that follow are only 
> concerned with the case where reg-id is present, so I think 
> it should be changed to:
> "When a '+sip.instance' media feature parameter and a reg-id 
> parameter are present in a
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Elwell, John" <[email-masked]>
Date: Sat, 05 Apr 2008 19:34:32 +0100

> Behalf Of Francois Audet
> Sent: 05 April 2008 00:38
> To: Elwell, John; IETF SIP List; Cullen Jennings; Rohan Mahy
> Subject: Re: [Sip] Review of sip-outbound-13
> 
> Thank you John.
> 
[JRE] It says that there is a case where a UA might not want to use the
sip.instance media feature tag, yet that tag is essential for outbound.
Is it saying that in such a case the UA should not use sip-outbound?

> For 7, it should say "A configuration option indicating...".
[JRE] OK, on re-reading it I understand it better, since it is referring
to the "explicit indication" in the previous paragraph. However, I think
your proposed wording change would be be an improvement.

> For 9, I'll have to defer to Rohan and Cullen because I find it
[JRE]Yes, and that is why I wasn't able to propose new words.

> topology hiding since the proxy uses the Via in the Request 
[JRE] What I meant was, if a proxy receives a REGISTER request with only
a single element in the Via header field, how does it know whether the
request came from a UA or from a topology-hiding B2BUA? This is probably
an unlikely situation for a REGISTER request (UA -> B2BUA -> proxy), but
can we rule it out?

John

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 6 Apr 2008 10:40:53 -0700

Hi John,

Thanks for your detailed comments. I have a few specifics inline.

> Is it saying that in such a case the UA should not use sip-outbound?
The text is explaining under what circumstances a UA would decide not  
to include +sip.instance in (any kind of) request.  Outbound  
registration requests certainly will not work if the UA leaves this  
parameter out.   I believe some of this is discussed in GRUU, but a  
complete discussion of this topic is certainly out of scope of the  
outbound spec.

[snip]
> [JRE]Yes, and that is why I wasn't able to propose new words.

We provided SHOULD level recommendations for the timers in this  
section.  If the UA has a good reason to do something else it MAY.   
The timers, the random spacing or lack thereof, even the backoff  
algorithm, they all could be configurable.  This is all we can say  
and all we should say on the matter.  I don't want to clutter up the  
text with a lot of text explaining things that UAs could do that we  
don't recommend.

I am certainly open to reading new proposed text, but I think the  
current text tells implementors what they should do pretty clearly.

> an unlikely situation for a REGISTER request (UA -> B2BUA ->  

A B2BUA has to behave as a legal UA.  The B2BUA will either advertise  
support for the outbound option-tag or not. If it does not support  
outbound, the registrar won't try an outbound-style registration and  
the original UAC will discover that from the response (no problem).  
If the B2BUA wants to support outbound, it will need to follow the  
spec. If the B2BUA wants to simulate an outbound-aware edge proxy,  
and also support topology hiding, it will need to insure that there  
are at least two Via headers in the request. It could easily do this  
by adding itself twice to the Via header field (possible, but not our  
problem).

Even if the B2BUA is truly broken and blindly copies option tags from  
the original UAC to the registrar (DON"T DO THIS KIDS!!!), it is  
unlikely that the B2BUA will know about and insert the 'ob' parameter  
in the first Path header.  The next hop will think the first edge  
proxy did not support outbound and carry on with non-outbound  
registration.

thanks,
-rohan

---

From: "Francois Audet" <[email-masked]>
Date: Sun, 6 Apr 2008 19:22:34 -0500

> > topology hiding since the proxy uses the Via in the Request and not 
> > the Path in the response.
> [JRE] What I meant was, if a proxy receives a REGISTER 
> request with only a single element in the Via header field, 
> how does it know whether the request came from a UA or from a 
> topology-hiding B2BUA? This is probably an unlikely situation 
> for a REGISTER request (UA -> B2BUA -> proxy), but can we rule it out?

Ah, "upstream" vis-a-vis the UAC, as opposed to "upstream" vis-a-vis the
outbound proxy.

Of course a B2BUA can screw things up. If one decides to have a 
B2BUA between the Outbound proxy and the UAC (which seems to be a weird
place for putting it), then obviously the B2BUA would have to comply to
outbound for outbound to work. I would think that normally, the B2BUA would
be on the other side or the outbound proxy, or even co-located with it.

There are plenty of opportunities for a B2BUA to mess things up. I don't 
believe it would make sense to say anything about it. 
_______________________________________________
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: "Elwell, John" <[email-masked]>
Date: Mon, 07 Apr 2008 14:53:47 +0100

Rohan,

OK, I can accept the explanations you give.

John 

> Behalf Of Rohan Mahy
> Sent: 06 April 2008 18:41
> To: Elwell, John
> Cc: IETF SIP List; Rohan Mahy; Francois Audet; Cullen Jennings
> > [JRE] It says that there is a case where a UA might not 
> want to use  
> > the
> request with  
> > only