[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 <ft at it.su.se> 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip