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

From: Brett Tate <[email-masked]>
Date: Tue, 20 Jan 2015 12:52:40 -0500

Hi,

The following are some comments concerning
draft-ietf-insipid-session-id-12.

Thanks,
Brett

-------

Copyright: Replace 2014 with 2015.

Section 7 paragraph 6: Remove the extra period.  Potentially should reword
the sentence to avoid it sounding like the request constructs the
Session-ID.

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.

Section 9.1 F3: The Route should be removed; Record-Route URI must be
within <>.

Section 9.1 F5: The Route URI must be within <>.

Section 10 bullets 2 and 6: Bullet 2 isn't necessarily true since it can
occur within dialog after bullet 6.  However it raises some questions
concerning how the B2BUA should behave when swapping a connected party
over the same dialog.  For instance when the new endpoint and replaced
endpoint support different versions of Session-ID, does the B2BUA blindly
relay the new Session-ID (towards the remaining endpoint which supports
draft or only RFC 7329) or does it somehow apply section 10 rules?  For
instance consider RFC 3725 figure 13 where pre-paid user supports RFC
7329; called party supports draft and is actually the calling party; and
media server supports draft.  Message 6 could look like pre-paid user
supports draft; thus message 8 will contain a new Session-ID unless the
B2BUA is supposed to somehow apply section 10 to remedy the situation.

-- 

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.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 23 Jan 2015 04:07:08 +0000

Brett,

>Copyright: Replace 2014 with 2015.

Done.

>the sentence to avoid it sounding like the request constructs the

How about this?
"The Session-ID included in a CANCEL request MUST be identical to the 
Session-ID included in the corresponding INVITE."

>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.

>Section 9.1 F3: The Route should be removed; Record-Route URI must be

Oh, Word... you have to love that auto-correct.  I didn't even notice it 
did that it removed the <>.

>Section 9.1 F5: The Route URI must be within <>.

Fixed.

>occur within dialog after bullet 6.

This is just a statement of fact, no?  Shouldn't we keep it just to be 
clear and set a firm foundation?  And 6 is about the response, whereas 2 
is about the request.

>However it raises some questions

What we really want to encourage in this draft is that the B2BUA not try 
to be "smart" and try to "fix" a problem.  What the B2BUA should do is 
merely forward to each endpoint the value used by the opposite endpoint.

You are correct in identifying a potential problem, though.  If two 
older endpoints were exchanging messages and somehow that older endpoint 
started talking with a newer endpoint, the newer endpoint might send 
over "SessionID= a; remote=b" and the older endpoint sends over 
"Session-ID: x".   As each of these endpoints receives a message with 
some unexpected value, what happens?  Well, we never got a clear answer 
on that.  We have a statement in the draft that says that compatibility 
is not ensured due to unknowns.  We do not know if the older endpoint 
will start echoing the new value or will keep using its old value.

I don't think there is really much we can do to try to cover every 
corner case, but I'm happy to add something if we know there is a 
fixable case.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 23 Jan 2015 04:23:41 +0000

Brett,

>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 

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.

Paul

---

From: Brett Tate <[email-masked]>
Date: Fri, 23 Jan 2015 05:32:05 -0500

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

--

---

From: Brett Tate <[email-masked]>
Date: Fri, 23 Jan 2015 06:24:24 -0500

Hi,

Thanks for the response; reply is inline.

> >Section 7 paragraph 6: Remove the extra period. Potentially
> >should reword the sentence to avoid it sounding like the
> >request constructs the Session-ID.
>
> How about this?
> "The Session-ID included in a CANCEL request MUST be
> identical to the Session-ID included in the corresponding
> INVITE."

It sounds okay to me.

> >Section 10 bullets 2 and 6: Bullet 2 isn't necessarily
> >true since it can occur within dialog after bullet 6.
>
> This is just a statement of fact, no?  Shouldn't we keep
> it just to be clear and set a firm foundation?  And 6 is
> about the response, whereas 2 is about the request.

I was just highlighting that the bullet 2 is only potentially true since the
RFC 7329 device may send requests with the same exact Session-ID that the
draft compliant device sent within an originating INVITE.  Bullet 6 is
potentially adequate to help ensure that a draft compliant device won't
think that the remote party has become draft compliant mid dialog because of
bullet 2.

Concerning my adjusted RFC 3725 figure 13 example, there is currently
nothing to help the media server from incorrectly thinking that the remote
device is draft compliant since hit bullet 2.  A fix could be introduced by
allowing the B2BUA to indicate the non-compliance (by header or parameter)
to the media server.  However, introducing extra signaling complexity to
avoid the misinterpretation is potentially not worth it.

Thanks,
Brett

--

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 23 Jan 2015 23:30:52 +0000

Brett,

OK.  I'll change it.  Like you, I don't really have a strong preference. 
  I changed every instance of TCP to UDP.  That should do it.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 23 Jan 2015 23:54:09 +0000

Brett,

>think that the remote party has become draft compliant mid dialog 

OK, I see your point now.  However, bullet 6 doesn't cover that initial 
INVITE.  When Bob receives that initial INVITE message, Bob needs to 
know whether it's a 7329 or a newer device.  It needs to know how to 
respond.  However, between bullet 3 and 6, I think you're right that it 
might be redundant.  Still, I think it's best to leave it here.  That 
way nobody has to read between the lines.

However, we really don't know if the 7329 device will ever send a 
request with the exact same Session-ID as was originally sent by an 
endpoint or not. It might echo the Session-ID exactly as it was 
received, or it might remove the "remote" parameter.  Behavior of 
devices in the wild is not entirely known.  So, you might be right.  We 
just don't know and, therefore, can't guarantee this is always correct.

>avoid the misinterpretation is potentially not worth it.

Yeah, I can see this being a battle for a while. It will introduce more 
complexity that folks will not like.

The B2BUA should know what kind of endpoint it's dealing with usually, 
though.  I think this can be handled by implementations.  Still, if it 
connects A (new) and B (old), A and B might be stubborn about switching 
behavior.  We could give guidance about that (e.g., B2BUA modify the 
Session-ID), but that guidance would very much go against what we're 
arguing for in the document of taking a hands-off approach.  A  smart 
newer endpoint should also figure this out, too.  It's either going to 
get what looks like a proper reply or one of the following:
1) An echo of what it sends in its next message
2) A single UUID (indicating 7329 behavior)
3) A response with two unknown UUIDs.  More more message exchange with 
that entity will help to determine if it's new or old, as the old device 
will continue to operate as either (1) or (2).

Paul