Subject: RE: [Sip] Comments on draft-ietf-sip-outbound-05

From: "Kevin Johns" <[email-masked]>
Date: Mon, 30 Oct 2006 12:48:54 -0700

What about the proposed changes to section 5.3? It is not listed in your
email so does that mean it was accepted without comment? (If so great as
I agreed with the change in wording as well.)

> 5.3  Forwarding Requests
>
>    Otherwise, if the top-
>    most Route header refers to the Edge Proxy and contains a valid 
> flow
>    identifier token created by this proxy, the proxy MUST remove the 
> the
>    Route header and forward the request over the flow that received 
> the
>    REGISTER request that caused the flow identifier token to be 
> created.

I suggest the following sentence instead :

"Otherwise, if the top-most Route header refers to the Edge Proxy and
contains a valid flow identifier token created by this proxy, the proxy
MUST remove the Route header and forward the request over the flow
identified by the flow token".

If you don't like my text, then at least note there is a "the the" in
the original sentence.

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Monday, October 30, 2006 9:00 AM
To: Fredrik Thulin
Cc: [email-masked]
Subject: Re: [Sip] Comments on draft-ietf-sip-outbound-05

Hi Fredrik,

I like your proposed text.  I'm pasting all these into the draft unless
otherwise noted.

On 10/30/06, Fredrik Thulin <[email-masked]> wrote:
> > 6.  Registrar Mechanisms: Processing REGISTER Requests
> >
> >    Likewise if
> >    the REGISTER request visited an edge proxy, but no Path header 
> > field
> >    values are present, the registrar MUST ignore the reg-id
parameter.
>
> Just to check: Would a registrar know this because there were more 
> than one Via header in the request, but no Path header?

Yes.

> > 6.  Registrar Mechanisms: Processing REGISTER Requests
> >
> >    For a binding with an
> >    instance-id, the registrar still stores the Contact header field
> >    value URI with the binding, but does not consider the Contact URI

> > for
> >    comparison purposes.
>
> Shouldn't that be "For a binding with an instance-id and a reg-id, the

> ..."?

No, this sentence was added to allow implementations to fetch a GRUU
(which needs an instance-id) without implementing outbound (which needs
a reg-id).

> > 6.  Registrar Mechanisms: Processing REGISTER Requests
> >
> >    In addition to the normal information stored in the binding
record,
> >    some additional information needs to be stored for any
registration
> >    that contains a reg-id header parameter in the Contact header
field
> >    value.
>
> This should be "contains an instance-id and a reg-id header parameter"

> I believe. If there was only a reg-id parameter, it should be ignored.

Yes, good catch.

> > 6.  Registrar Mechanisms: Processing REGISTER Requests
> >
> >    ... MUST implement support the STUN
>
> Either implement or support.

"MUST implement the STUN keepalive mechanism described in Section x of
this document."

> > 8.  STUN Keepalive Processing
> >
> >    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 think this sentence should be removed. I don't think there is a 
> single way to ask the end user if STUN keepalives should be sent or 
> not that would actually make sense to an average end user. That 
> sentence is no longer needed after the new text explaining that a user

> agent must actually verify STUN support. I also think it is out of 
> scope for Outbound to tell implementors how they should make their 
> user interfaces.

I added this at the request of other folks in the WG.  The normative
language is just "MUST NOT use an ambiguous configuration option".
I'm inclined to leave this sentence or reword it unless the  folks who
were originally concerned also no longer think it is necessary.

> > 8.  STUN Keepalive Processing
>
> Generally regarding the mechanisms in this section, I am a bit unsure 
> about if the case where a next-hop actually _stops_ supporting STUN is

> handled with enough care. One might say that it would be very seldom 
> that providers actually downgrade their edge proxys to something that 
> no longer supports STUN, but think for example if I have my wifi phone

> configured with 192.168.0.1 supporting STUN keepalives. That might 
> work just fine with my own wireless access point, but perhaps not with

> someone elses, that my phone ends up connected to.
>
> I think there should be text saying that support has to be re-verified

> after some period of time without successfull STUN transactions. 
> Perhaps something like :
>
> "If a destination previously validated to support STUN keepalives does

> not respond to any STUN keepalives sent for 36000 seconds (ten hours),

> then the validation is to be considered revoked and support will have 
> to be verified in the same way as if the next-hop had never been 
> validated."

Ugh.  I'd like to think about this a bit more.

> > 8.  STUN Keepalive Processing
>
> If a client sends a REGISTER with "Supported: path", and receives a 
> 200 response with a Path vector in it, it could look for ";ob" in the 
> first Path header value, and use that as an explicit indication that 
> it would be OK to send STUN messages to the next hop, right? Of 
> course, the text in this section about actually validating STUN 
> support fot the next hop still applies.

Probably, but I needed to make the section on STUN processing relatively
autonomous.  I think I will bring this up at the meeting.

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

_______________________________________________
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: Tue, 31 Oct 2006 10:27:22 -0800

thanks,
-rohan