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

From: "Fredrik Thulin" <[email-masked]>
Date: Mon, 30 Oct 2006 15:41:44 +0100

These are my other comments/questions on Outbound 05 :

> 5.1  Processing Register Requests
>
>    When an Edge Proxy receives a registration request with a reg-id
>    header parameter in the Contact header field, it typically needs to
>    store a "flow token", containing information about the flow from 
> the
>    previous hop, in a Path header field value as described in RFC 3327
>    [RFC3327].

I would like to suggest making this text clearer about when an edge 
proxy needs to store a flow token and when it does not have to. 
Suggestion :

"When an Edge Proxy receives a registration request with a reg-id header 
parameter in the Contact header field, it must determine if it (the edge 
proxy) will have to be visited for any subsequent requests sent to the 
user agent identified in the Contact header field, or not. If the Edge 
Proxy determines that this is the case, then it needs to store a "flow 
token", containing information about the flow from the previous hop, in 
a Path header field value as described in RFC 3327 [RFC3327]."

> 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.

> 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?

> 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 
..."?

> 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.

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

Either implement or support.

> 7.  Authoritative Proxy Mechansims: Forwarding Requests
>
>    The proxy uses normal forwarding rules looking at the next-hop 
> target
>    of the message and the value of any stored Path header field vector
>    in the registration binding to decide how to forward the request 
> and
>    populate the Route header in the request.  Additionally, when the
>    proxy forwards a request to a binding that contains a reg-id, if 
> the
>    binding has a previous hop flow associated with it, the proxy MUST
>    send the request over the same network flow that was saved with the
>    binding.

This was one of the parts that was not clear enough for me to understand 
that the authoritative proxy could actually have decided that it didn't 
need to send the request using the exact same flow. I would like to 
suggest the following modification :

"The proxy uses normal forwarding rules looking at the next-hop target 
of the message and the value of any stored Path header field vector in 
the registration binding to decide how to forward the request and 
populate the Route header in the request.  If the proxy stored 
information about the flow it received the REGISTER for the binding in 
question over, then the proxy MUST send the request over the same 
network flow that was saved with the binding. The proxy would only have 
stored information about the exact flow used if it was deemed necessary 
at the time of registration, because the next hop was not known to be 
globally reachable."

> 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.

> 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."

> 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.

/Fredrik

_______________________________________________
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: Mon, 30 Oct 2006 07:59:52 -0800

Hi Fredrik,

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

> one Via header in the request, but no Path header?

Yes.

> 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).

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

Yes, good catch.

> Either implement or support.

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

> Outbound to tell implementors how they should make their user

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.

> be verified in the same way as if the next-hop had never been

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

> in this section about actually validating STUN support fot the next hop

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