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

["Paul E. Jones" <[e-mail]>]

Brett,

Please see my comments below:


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

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


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

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.


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

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?


>>  >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.
>>
>>  I think you're saying that F4 needs to contain a Record-Route header.
>>  Correct?
>
>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.

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)?


>>  >Section 9.4 bullet 4: Potentially should clarify why this example is
>>  >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.
>
>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.

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
>>  >sent two 18x creating two early dialogs with Session-IDs {B1x, A} 
>>and
>>  >{B1y, A}?
>>
>>  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.
>
>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?

This bit made it clearer for me.


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

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