Subject: Re: [Sip] Review request for draft-ietf-sip-record-route-fix-03

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Aug 2008 11:07:40 -0400

Keith and Dean asked me to review this document.
(I admit I had not read it until now.)

I am glad to see this document - it is important. And it goes a long way 
toward sorting out the issues. However I did find a number of things 
that IMO could be improved:

Section 5:

There is a small typo in the following:

    Preprocessing" f[RFC3261], implementors can choose that proxy MAY
                   ^
I believe the "f" is an accident.

Also, here and throughout the document the domain names "atlanta.com" 
and "biloxy.com" are used. While these are ubiquitous, and IMO pleasing, 
for sip examples, its my understanding that they aren't really supposed 
to be used in official documents because they are potentially valid 
domains that might belong to somebody. I recommend using 
"atlanta.example.com" and "biloxy.example.com" instead.

Figure 3:

The indenting seems odd and a bit distracting. I gather the indenting is 
aligned with the positioning of the sender in the call flow. But I don't 
find it helpful.

The messages don't include Via headers. Presumably this is because they 
aren't pertinent to what is being discussed. But it would be good to 
note that some headers have been omitted to ease readability.

IMO it would be useful to add another bit of info the the intro line for 
each message - the address to which it was sent. E.g.:

       F5 ACK UA1 -> P1 (192.0.2.254:5060)

While it is redundant information I think it would improve understanding.

Figure 5:

It appears to me that the message F2 is not consistent with the 
description of the scenario. That says that P1 is forwarding requests to 
bob using UDP based on information it learned from registration. If so, 
then I would expect that P1 would be translating the R-URI to the 
registered contact. Yet that is not shown. So I would expect message F2 
to look more like:

            F2 INVITE P1 -> UA2

            INVITE sip:[email-masked];transport=udp SIP/2.0
            Record-Route: <sip:192.0.2.1;lr> (NO transport param)
            From: Alice <sip:[email-masked]>;tag=1234
            To: Bob <sip:[email-masked]>
            Contact: <sip:[email-masked];transport=tcp>

Also, IMO it would be useful to add another bit of info the the intro 
line for each message - the domain to which it was sent. Rolling this up 
with my prior comment, perhaps always show the address, and also show 
the transport when it is pertinent to the discussion.

            F2 INVITE P1 -> UA2 (ua2.biloxi.com/udp)

Section 6:

Nowhere in here do I see any mention of the impact of message size on 
transport selection. In theory, any UA or proxy using UDP must also be 
prepared to use TCP for those requests that exceed the size limit for 
UDP. If the route is locked down to UDP in a Contact or Route header, 
then there will be no option to switch to TCP for large requests.

Having said that, I realize there are probably a lot of devices out 
there what only support UDP, and are not prepared to switch to TCP.

I don't know what the proper resolution of this problem is, but I do 
think it should be discussed, rather than being ignored.

Section 6.1:

There is normative language in this section:

    This usage SHOULD be avoided, because forcing the transport protocol

Is this intended to be normative? If so, its not entirely clear what 
"This" refers to.

Section 6.2:

This section seems to go out of its way to put Record-Route rewriting at 
parity with double record routing. This seems in conflict with the 
earlier sections that *prefer* double Record-Routing. I do think it 
probably makes sense to acknowledge here that Record-Route rewriting is 
a *possibility*, while not advocating it.

	Thanks,
	Paul

DRAGE, Keith (Keith) wrote:
> We recently put 
> 
> http://www.ietf.org/internet-drafts/draft-ietf-sip-record-route-fix-03.t
> xt
> 
> Unfortunately we only received one comment on the draft. In order to
> ensure that the document does get reviewed, we are asking a few people
> to do a review of the current version. A show of hands at the WG meeting
> indicated that very few people had read the current version.
> 
> Is it possible that you could do such a review of the document?
> 
> If so, then please indicate when you might be able to complete such a
> review?
> 
> Regards
> 
> Keith
> 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip