Re: [Insipid] draft-ietf-insipid-session-id-12: comments

[Brett Tate <[e-mail]>]

Hi,

Thanks for the response.  Reply is inline.

> >>Section 9.1 F2, F3, and F5: Since UDP is the default transport,
> >>you might want to change the top Via's transport to be UDP
> >>within F2, F3, and F5.
> >
> >Unless there is a good reason to change these, I'd prefer
> >to leave them. UDP is still widely used, but TLS is also
> >extremely common. It's important that we don't have an error
> >here, of course. Any errors or just a preference for UDP.
>
> Actually, that would be "TLS".  Nonetheless, the question
> remains: is there a reason to change them to UDP?  If we do,
> I'd prefer to change all references to UDP just so it's all
> consistent.

I don't have a strong opinion on the topic.  The selected transport from
B2BUA to Bob violates the following SHOULD (assuming no reason to do
otherwise).

RFC 3263 section 4.1:

"Otherwise, if no transport protocol is specified, but the TARGET is a
numeric IP address, the client SHOULD use UDP for a SIP URI, and TCP
for a SIPS URI.  Similarly, if no transport protocol is specified,
and the TARGET is not numeric, but an explicit port is provided, the
client SHOULD use UDP for a SIP URI, and TCP for a SIPS URI.  This is
because UDP is the only mandatory transport in RFC 2543 [6], and thus
the only one guaranteed to be interoperable for a SIP URI.  It was
also specified as the default transport in RFC 2543 when no transport
was present in the SIP URI.  However, another transport, such as TCP,
MAY be used if the guidelines of SIP mandate it for this particular
request.  That is the case, for example, for requests that exceed the
path MTU."

Thanks,
Brett

-- 

Meet with us at Mobile World Congress 2015 
<http://www.broadsoft.com/news/mobile-world-congress/>

This email is intended solely for the person or entity to which it is 
addressed and may contain confidential and/or privileged information. If 
you are not the intended recipient and have received this email in error, 
please notify BroadSoft, Inc. immediately by replying to this message, and 
destroy all copies of this message, along with any attachment, prior to 
reading, distributing or copying it.