[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] Comments on draft-ietf-sip-outbound-05
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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip