unsubscrib > From: [EMAIL PROTECTED]> Date: Sat, 1 Dec 2007 12:20:11 -0800> To:
[EMAIL PROTECTED]> CC: [email protected]; [EMAIL PROTECTED]; [EMAIL PROTECTED]>
Subject: [Sip] Re: WGLC comments on sip-outbound-10> > 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
_________________________________________________________________
Connect to the next generation of MSN Messenger
http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline
_______________________________________________
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
