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

From: Brett Tate <[email-masked]>
Date: Fri, 24 Oct 2014 10:51:33 -0400

Hi,

The following are a few comments concerning
draft-ietf-insipid-session-id-10.

Thanks,
Brett

------

Section 1 paragraph 4: "This procedures" should be "The procedures".

Section 6 paragraph 1: "be used the peer" should be "be used if the peer".

Section 7 paragraph 1: Since proxies cannot alter a Call-ID (without
becoming B2BUA), "proxies and" should potentially be removed from the
first sentence.

Section 7 paragraph 6: Concerning early dialogs, the CANCEL correlates to
the INVITE instead of a specific early dialog.  Thus the paragraph should
likely be reworded to always reflect the INVITE when CANCEL not traversing
a dialog.  For instance if received multiple 18x creating multiple early
dialogs and received Session-IDs {B1, A} and {B2, A}, the current
paragraph appears to recommend that the CANCEL include one of these within
the CANCEL.

Section 7 paragraph 7: Should potentially recommend what should occur when
B2BUA sends re-INVITE without SDP to obtain SDP to setup another session.
More specifically, should the re-INVITE contain a new 3PCC generated UUID?
The other options would be to resurrect the discarded UUID or use the
currently connected session's UUID.

Section 9.1: Concerning the SIP messages, the B2BUA appears to be a proxy.
Thus from a RFC 7092 perspective, I guess that it is a Proxy-B2BUA that
hasn't originated any requests.

Section 9.1: The F3 and F4 Via branch "z9hG4bKnashds8" should instead
reflect INVITE's Via branch.

Section 9.1: The F4 Contact or F5 Request-URI potentially need a different
ip-address (although maybe reflecting missing Record-Route without "lr").
F4 Contact reflects F3 Contact and doesn't match F5 Request-URI.

Section 9.1: Concerning F6, the B2BUA's Via header appears to be missing.
And existing Via should contain a received parameter.

Section 9.2: Should potentially clarify if the REFER is mid-dialog even if
section 9.9 is out-of-dialog REFER.

Section 9.3 bullet 2: I'm glad that the example isn't mandating sending a
request to update the Session-ID after transfer.  However you might want
to reword the last sentence since Alice won't remain "completely unaware"
of the transfer since Alice's device would notice the transfer caused
Session-ID modification when subsequent messaging occurs on the dialog.

Section 9.4 bullet 4: Potentially should clarify why this example is
quickly updating the Session-ID but section 9.3 example does not.

Section 9.8.1 figure 10: What should be the CANCEL session-id if Bob-1 had
sent two 18x creating two early dialogs with Session-IDs {B1x, A} and
{B1y, A}?

Section 10 paragraph 4: "following" should be "follow".

Section 10 paragraph 5: "rules for" should be "rules that".

Section 10 bullets: Some currently start upper case; others currently
start lower case.

Section 10 bullet 7: "include and" should be "include a"

Section 10 last bullet: Should potentially reword the bullet.  I'm not
sure if second sentence is indicating to ignore unknown parameters, remove
unknown parameters, or something else (like reiterating that the above
bullets do not apply to them).

Section 14.2 RFC5589: "RFC 5359" should be "RFC 5589".

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 25 Oct 2014 02:36:05 +0000

Brett,

>Section 1 paragraph 4: "This procedures" should be "The procedures".
Fixed.

>Section 6 paragraph 1: "be used the peer" should be "be used if the 

Fixed.

>becoming B2BUA), "proxies and" should potentially be removed from the

Good catch! Fixed.

>paragraph appears to recommend that the CANCEL include one of these 

I'm not entirely clear on what you're suggesting.  All the current 
paragraph says is that if an intermediary sends a CANCEL and it doesn't 
have the value B1, for example, it is to use {A, "null"} as the 
Session-ID.

>currently connected session's UUID.

What changes in the text are you proposing?  The temporary value would 
persist until such time as a the 3PCC device learns what the actual UUID 
values are for Alice or Bob.  If a re-INVITE is sent, the 3PCC device 
would send either the same fabricated UUID to Bob if it does not know 
Alice's UUID.  Or, it will send Alice's UUID if it knows it.

>hasn't originated any requests.

B2BUAs don't have to originate requests.  This example (and all others 
that use B2BUA) shows a classic B2BUA.  I don't think it will help to 
make this clearer introducing a new type of device like "Proxy-B2BUA".

>reflect INVITE's Via branch.

Fixed

>F4 Contact reflects F3 Contact and doesn't match F5 Request-URI.

I think you're saying that F4 needs to contain a Record-Route header.  
Correct?
I've added "Record-Route: <sip:server10.biloxi.example.com;lr>"

I think the ACK from Alice to the B2BUA was also wrong.  I've changed 
that to reflect Bob's address.  That is, the ACK should have:
ACK sip:[email-masked] SIP/2.0

>And existing Via should contain a received parameter.

Fixed (I think; please check the next draft I'll post for this all all 
other corrections).

>section 9.9 is out-of-dialog REFER.
OK.  Added a sentence in parentheses.

>Session-ID modification when subsequent messaging occurs on the dialog.

That is certainly true up to this point that Alice would be unaware of 
the transfer, but you're right that she would become aware in the future 
when she receives a message from Carol.  I tried to make that a little 
clearer.

>quickly updating the Session-ID but section 9.3 example does not.

I'm not sure what you are referring to here.  Nowhere do we purposely go 
out of the way to update a Session-ID.  Those values are only updated 
when there is otherwise a reason to send a message.

>sent two 18x creating two early dialogs with Session-IDs {B1x, A} and

I don't fully understand your question.  However, if there is a single 
call initiated from Alice to Bob-1, then there would only be {B1} at 
Bob-1, not {B1x} and a {B1y}.  If you're asking about the case where 
Alice made two separate calls to Bob-1, then Alice would be using two 
separate {A1} and {A2} values.

>Section 10 paragraph 4: "following" should be "follow".

Fixed.

>Section 10 paragraph 5: "rules for" should be "rules that".

Fixed.

>Section 10 bullets: Some currently start upper case; others currently

Fixed.

>Section 10 bullet 7: "include and" should be "include a"

Fixed.

>bullets do not apply to them).

I tried to fix that.  Please let me know if this is clearer.

>Section 14.2 RFC5589: "RFC 5359" should be "RFC 5589".
Fixed it.

Thanks for the very thorough review.  This really helps!

Paul

---

From: Brett Tate <[email-masked]>
Date: Mon, 27 Oct 2014 12:27:14 -0400

Hi,

Thanks for the response; reply is inline.

> >Section 7 paragraph 6: Concerning early dialogs, the CANCEL correlates
> >to the INVITE instead of a specific early dialog. Thus the paragraph
> >should likely be reworded to always reflect the INVITE when CANCEL not
> >traversing a dialog. For instance if received multiple 18x creating
> >multiple early dialogs and received Session-IDs {B1, A} and {B2, A},
> >the current paragraph appears to recommend that the CANCEL include one
> >of these within the CANCEL.
>
> paragraph
> says is that if an intermediary sends a CANCEL and it doesn't have the
> value
> B1, for example, it is to use {A, "null"} as the Session-ID.

I'm indicating that a CANCEL should not reflect early dialog information; it
should reflect the INVITE.  Otherwise you'd be having to select a single
Session-ID from 1 of potentially many early dialogs to place within the
CANCEL (which isn't associated with a specific early dialog).  My comment is
similar to my Section 9.8.1 figure 10 comment.

Current text:

" A CANCEL request sent by an intermediary that has not received a UUID
   from the destination UA MUST construct a Session-ID header value
   exactly like the INVITE to that UA, with the known "local-uuid" value
   for the initiating UA and the null UUID as the "remote-uuid" value
   for the destination UA."

Suggested text: "A CANCEL request sent by an intermediary MUST construct a
Session-ID header value exactly like the INVITE's Session-ID."

Similar text should likely be added to section 6; for instance, maybe after
the next-to-last paragraph which indicates UAs MUST take care concerning
forking interaction.

> >Section 7 paragraph 7: Should potentially recommend what should occur
> >when B2BUA sends re-INVITE without SDP to obtain SDP to setup another
> >session.
> would send
> either the same fabricated UUID to Bob if it does not know Alice's UUID.
> Or,
> it will send Alice's UUID if it knows it.

The 3PCC device can send a re-INVITE without SDP to Alice to connect Alice
to device X instead of Bob.  X's UUID would be within the Session-ID of
re-INVITE's ACK; however I'm currently not sure what UUID the draft is
recommending the 3PCC to place within re-INVITE.  Allowing the 3PCC device
to do whatever (or interpret however) it wants is okay with me; however I
thought the draft might want to clarify what should occur.

For instance, see RFC 3725 section 10.2 figure 13.  After the Controller
sends re-INVITE to place the Called Party (Bob) on hold, the Controller
sends re-INVITE (message 4) to connect Pre-Paid User (Alice)  to Media
Server (X).  I'm attempting to understand which UUIDs should go within
message 4's Session-ID.

> that
> use B2BUA) shows a classic B2BUA.  I don't think it will help to make this
> clearer introducing a new type of device like "Proxy-B2BUA".

I was just commenting that the example looked like a proxy instead of a
B2BUA.  However if intentional, that is okay with me.

> >Section 9.1: The F4 Contact or F5 Request-URI potentially need a
> >different ip-address (although maybe reflecting missing Record-Route
> >without "lr").

Yes; unless Record-Route and Route were considered non-essential headers
(and the Request-URI was reflecting B2BUA's Record-Route entry which had no
lr).

Concerning draft-ietf-insipid-session-id-11... if Record-Route and Route are
considered essential, Record-Route should likely be added to F2 and F3; and
Route should likely be added to F5.

> Fixed (I think; please check the next draft I'll post for this all
> other corrections).

The fix looks okay to me.

> when there is otherwise a reason to send a message.

Figure 4 indicates "(to change the UUID to M')" within several locations
when sending re-INVITE.  Similarly section 8 has MUST statements which
appear to require the MCU to update the Session-ID.  Thus if the MCU didn't
otherwise have a need to send the re-INVITE, section 8 appears to require
sending re-INVITE to fix the Session-ID.

> separate {A1} and {A2} values.

See my section 7 paragraph 6 comment.  If it helps, consider situation of
Alice having an outbound B2BUA which sends CANCEL while Bob's B2BUA is using
a simultaneous ringing service (instead of Call Forward No Answer service).
Should Alice's B2BUA include Session-ID {A, B1} or {A, B2} within the CANCEL
sent to Bob's B2BUA?

If I understand correctly, Figure 10 and section 7 paragraph 6 currently
imply that Alice's outbound B2BUA would send CANCEL with Session-ID {A, B1}
or Session-ID {A, B2} instead of Session-ID {A, N}.  I'm suggesting that
Figure 10 and section 7 paragraph 6 potentially be updated to indicate that
Session-ID {A, N} would be sent.

> I tried to fix that.  Please let me know if this is clearer.

Sounds okay to me.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 29 Oct 2014 04:25:28 +0000

Brett,

>Session-ID header value exactly like the INVITE's Session-ID."

OK, your text down below made this clearer for me.  I agree we should do 
as you say.

>the next-to-last paragraph which indicates UAs MUST take care 

This is referring to Alice's behavior.  Basically, when she further 
communicates with Bob-2, for example, she needs to ensure the Session-ID 
header contain's Bob-2's UUID value.  I don't think we want to change 
that.

In both of the above, I'm not trying to be contrary, by any means. If 
folks don't think this is the right thing to do, I can change the text.  
  But, it seems odd that we'd have different rules for how the Session-ID 
is populated just because there is an early dialog and it definitely 
does not fulfill that desire to be able to use it for debugging 
messages.

>Server (X). I'm attempting to understand which UUIDs should go within

Yeah, this is a good point and it's not stated in the draft.   The 
benefit of using Bob's UUID is that the continuity is maintained.  If we 
use a null UUID for the re-invite, then it's lost.  For message 6, 
though, that INVITE should be {A,null}.  Message 7 would have {A,Y} (Y 
== Media Server).  Message 8 should have {A,Y}.  That's my opinion.  If 
you agree, would you mind suggesting some words that effectively convey 
that with brevity?

>Route should likely be added to F5.

F2, OK.  But F3 for Record-Route?  Does that message from Bob really 
need Record-Route?  I appreciate it could be there, but is that 
essential?

"Route:" in F5, ok.  What about F3 (since Record-Route is now added to 
F2)?

>sending re-INVITE to fix the Session-ID.

OK, I see why that's not so clear.  The text to which you refer in 
Figure 4 relates to the fact that the participant called into the MCU 
and initially had a call with the IVR system.  Once the IVR system was 
done, a re-INVITE is sent to put the participant to put them into the 
conference.  That's what the "to change the UUID to M'" text means.  
However, "to change the UUID" is not the primary motivation for sending 
that re-INVITE.

We could just remove  the text "(to change the UUID to M')" or change it 
to something else.  I'm not sure what we should change it to that will 
not be a mile long.  Suggestions?

>>  >Section 9.8.1 figure 10: What should be the CANCEL session-id if 
>>Bob-1
>>  >had

This bit made it clearer for me.

>Session-ID {A, N} would be sent.

OK, I'm sold on this needed change.  We'll have all CANCEL's align with 
INVITE messages.

Man, I really appreciate you finding these kinds of issues.

Paul