Hi Derek,
I think I have addressed all your comments except the CRLF backward
compatibility, which I have fixed in my working copy. See below for
specifics.
On Aug 6, 2007, at 3:46 PM, Derek MacDonald wrote:
I've finished my review of outbound-10, mainly thinking about things
from a client implementation & NAT traversal perspective.
Major issues:
The following issues are all one part of what I think is the core
issue w/ outbound; the draft does not require normative behavior that
will result in successful NAT traversal, although it does contain the
necessary mechanisms for NAT traversal
In 4.2 and 4.3 it is stated that route-set creation is outside the
scope of outbound. The behavior that is would work for NAT traversal
in a simple deployment is described as an example in 4.2.
I think this is greatly improved in -11 by the following changes:
outbound-11 now states that the edge proxy is expected to record-
route with a flow-token if the client includes an 'ob' parameter in
its Contact. If the client is using gruu, it uses the gruu instead
in its contact. The UA now also uses rport in all requests.
I think this should be sufficient to insure responses (rport),
incoming requests (from Path flow token in REGISTER), and in-dialog
requests (from Record-Route flow token, or from a GRUU) all get back
to the UA.
From 4.2:
"Forming the route set for the request is outside the scope of
this document, but typically results in sending the REGISTER such
that the topmost Route header field contains a loose route to the
outbound proxy URI."
Are we really anticipating that an element will be inserted between
the UA and the outbound proxy(s). Do we want to allow this?
no and no. The "typically results in sending the REGISTER..." text
is there to allow the traditional usage of an outbound proxy, which
is to resolve the IP address, port, and transport and send it there
without including a Route header at all.
If there
is such an element in the route set, it will either have to:
Support outbound, which causes a single point of failure if there
isn't a 1-1 correspondence with the edge proxies. If there is a 1-1
correspondence with the edge proxies, it is an edge proxy, so is
should have just been configured as the outbound proxy.
OR
Transparently relay outbound, which seems like a very bad idea.
I think we should change the text to something like:
"While forming the route set for the request is outside the scope of
this specification, the first element in the route set for a
registration MUST be from the outbound-proxy-set in order to use this
specification."
I think the current text already require that the first element
visited (whether in the route set or not) is in the outbound-proxy-set.
Section 4.3 Discusses how a UA would send a request, but does not
describe the basic behavior that would establish a dialog through a
NAT.
" When a UA is about to send a request, it first performs normal
processing to select the next hop URI. The UA can use a variety of
techniques to compute the route set and accordingly the next hop
URI.
Discussion of these techniques is outside the scope of this
document
but could include mechanisms specified in RFC 3608 [22] (Service
Route) and [21]."
If the next hop does not support outbound, and isn't an existing flow,
a dialog establishing request will likely result in a route set which
does not work through a NAT. The rport mechanism only provides NAT
traversal for a single SIP response.
correct. there is now text setting the responsibility clearly:
If the registrar did not support outbound, the UA may have
unintentionally registered an unroutable contact. It is the
responsiblity of the UA to remove any inappropriate Contacts.
"The UA performs normal DNS resolution on the next hop URI (as
described in RFC 3263 [4]) to find a protocol, IP address, and
port."
As there is no mechanism to determine outbound support in other
administrative domains, this lookup is only relevant to outbound if
the UA knows next hop supports outbound.
yes.
Later in the same paragraph:
"If the UA cannot use one of the existing flows,then it SHOULD
form a new flow
by sending a datagram or opening a new connection to the next
hop, as
appropriate for the transport protocol."
I was under the impression that flows are only created with REGISTER
requests...is this incorrect?
this has been changed in -11 to allow flows to be formed for dialog-
creating requests.
The crux of the issue is that to accomplish NAT traversal using
outbound w/out extensions, the UA MUST send dialog creating requests
using an existing flow(selected by round-robin for appropriate
transport/etc). Furthermore, in 5.3, edge proxies MUST record route
dialog creating requests. We need to change the base-level behaviour
of outbound so NAT traversal just works, is this is a core requirement
of outbound.
Also:
Note that if the UA wants its flow to work through NATs or
firewalls it still needs to put the 'rport' parameter [10] in
its
Via header field value, and send from the port it is prepared to
receive on. More general information about NAT traversal in SIP
is described in [23].
should be removed. [23] is very out of date, and references
outbound-01, and I believe some of the text is out of date. Rport is
not relevant when flows are used, although it doesn't cause any harm.
rport is still relevant when flows are used, because outbound does
not change the rules in 3261 for forwarding responses.
Questions/minor issues:
4.1:
"The value of this parameter MUST be a URN [8]. One case
where a UA may not want to include the URN in the sip.instance
media feature tag..."
Does this mean that a sip.instance feature tag is still included? If
so, what does it contain?
no, the whole parameter should be omitted. i think i reworded this
to make it more clear.
"As a result, the UA instance SHOULD provide lexically equivalent URNs
in each registration it
generates. "
Why not MUST instead of SHOULD?
fixed
Nits
Explain why the CRLFCRLF & CRLF messages used for the PING/PONG don't
break existing SIP implementations. I spent a lot of time looking
through the grammar before I gave up and asked Rohan and pointed me to
section 7.5 of 3261. I would reference this section in 3.5.1 and/or
4.4.2.
bummer. I forgot to include this in -11. I have added this in my
working copy to section 3.5.1 as follows:
Sending a CRLF over a connection-oriented transport is
backwards safe (because of requirements in Section 7.5 of
RFC 3261),
but only implementations which support the 'keep'
parameter will
respond to a "ping" with a "pong".
2.1
"reg-id: This refers to the value of a new header field parameter
value for the Contact header field. When a UA registers
multiple
times, each simultaneous registration gets a unique reg-id
value."
change simultaneous to concurrent:
"reg-id: This refers to the value of a new header field parameter
value for the Contact header field. When a UA registers
multiple
times, each concurrent registration gets a unique reg-id value."
fixed
3.3
"If a UA has multiple flows, and one of the servers fails, the UA
delays the specified time before trying to form a new connection to
replace the flow to the server that failed."
This implies that if the UA only has one flow, it retries immediately
which doesn't match the behaviour described in 4.5. Maybe:
"When a server fails the UA will delay before attempting to
re-establish a flow, using the delays specified in section 4.5."
fixed
3.5
Change(awkward):
"In this case, the server provides an indicator (the
'timed-keepalives' parameter) that the server requires the
client to
use the suggested timer values."
to
"In this case, the server indicates that the client must use the
suggested timer values by including the timed-keepalives parameter."
i think the original text (while uglier) is more clear.
4.1
"This means the value of the time component of the UUID can be
arbitrarily selected to be any time less than the time when the
device was manufactured. A time of 0 (as shown in the
example in
Section 3.2) is perfectly legal as long as the device knows no
other UUIDs were generated at this time."
I found this extremely confusing; I think it is saying that the time
component isn't necessary(but can't be in the future) if the device
already has a unique mac address it includes in the UUID. Why not just
say that a time of 0 can be used if the device is guaranteed to have a
unique MAC address at construction time?
The UA can't use time zero, if the UA generates multiple instance-ids
and uses time zero for all of them.
In the absence of better text, I left it as is.
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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
