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.
>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? 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."
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.
"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.
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?
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.
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?
"As a result, the UA instance SHOULD provide lexically equivalent URNs
in each registration it
generates. "
Why not MUST instead of SHOULD?
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.
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."
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."
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."
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?
-Derek
_______________________________________________
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
