[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Review of sip-outbound-13
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> 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.
>
> I am OK with your edits 1, 2, 4, 5, 6, 8 and 11.
>
> I don't understand your point about 3.
[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
> confusing too.
[JRE]Yes, and that is why I wasn't able to propose new words.
>
> 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.
[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
>
>
>
> > -----Original Message-----
> > From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> > Behalf Of Elwell, John
> > Sent: Friday, April 04, 2008 07:01
> > To: IETF SIP List
> > Subject: [Sip] Review of sip-outbound-13
> >
> > 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
> > sip-implementors at cs.columbia.edu for questions on current sip
> > Use sipping at ietf.org for new developments on the application of sip
> >
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip