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

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

Brett,

Please accept my apologies for the long delay.  My work priorities were 
shifted and I had to let this sit for a little while.

>>  >Suggested text: "A CANCEL request sent by an intermediary
>>  >MUST construct a Session-ID header value exactly like the INVITE's
>>  >INVITE's Session-ID."
>>
>>  OK, your text down below made this clearer for me.
>>  I agree we should do as you say.
>
>Potentially should make a slight modification to the suggested text so 
>that
>it only applies to CANCEL outside of dialog.

Why say that?  Why not have any CANCEL follow this rule?


>
>>  >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.
>
>Consider the simultaneous ring example with Alice having an outbound 
>B2BUA.
>Which 1 of many remote UUID's would she place within the Session-ID of 
>the
>single CANCEL which is sent outside of dialog?
>
>Why should the endpoint behave differently from intermediary when 
>sending
>CANCEL outside of dialog (assuming still planning to alter intermediary
>behavior)? Because of forking, lack of 199 support, et cetera, the 
>endpoint
>does not really know which of potentially many remote UUIDs to use to
>populate as the remote UUID within the CANCEL. Thus it is just a matter 
>of
>deciding if better to potentially include the correct remote UUID or 
>better
>to avoid including an incorrect remote UUID. I don't recall what RFC 
>3261
>says concerning a proxy relaying unknown headers from a received CANCEL 
>when
>sending the related CANCELs; similarly I'm not completely sure what
>draft-ietf-insipid-session-id wants to occur.

OK, I get your point.   How about this added to the end of the 
next-to-the-last paragraph in Section 6:

"The one exception is when the UA sends a CANCEL message, in which case 
the Session-ID header value will be identical to the original INVITE."


>>  >> >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?
>
>Place the following after "Refer to the third-party call control 
>example for
>an illustration."
>
>"If the third-party call controller sends a re-INVITE to obtain an 
>offer for
>connecting the endpoint to a different session, the Session-ID MAY 
>reflect
>the current session; the ACK's Session-ID would reflect the newly 
>connected
>session."

OK

>>>>>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?
>
>I still don't know your working definition of essential. The 
>Record-Route
>and Route stuff should be present to comply with RFC 3261 (without 
>requiring
>local policy to override RFC 3261 default behavior) since B2BUA is not
>altering Contact values. However, Record-Route and Route are not 
>essential
>for understanding Session-ID stuff within the example.
>
>If the ACK reflects the 2xx's Contact URI, I don't have a strong 
>opinion if
>the example shows the Record-Route and Route stuff since easy to assume 
>that
>loose routing is occurring and Record-Route/Route deemed non-essential.
OK, you want this added to F2 and F3?

Record-Route: <sip:server10.biloxi.example.com;lr>


>>"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?
>
>Based upon my following paragraph, you can likely leave as-is.

Which following paragraph?  This one here right below?


>Based upon section 9.3, the draft does not require an intermediary to 
>send a
>request solely to update Session-ID. Does the draft require an endpoint
>such as the Single Focus Conference Server to send a request solely to
>update the Session-ID (if became inaccurate such as when turn 2 
>separate
>calls into a conference)? Either way, it would help if there were 
>normative
>statements within sections 6 and 7 indicating that they MAY, SHOULD, or 
>MUST
>send a request to update the Session-ID if local UUID becomes 
>inaccurate.

I don't think there will be a case where the endpoint does not know the 
Session-ID.  The text in 9.4 is just confusing.  This re-INVITE updates 
the UUID to M' only as a side effect.  The real reason for sending the 
re-INVITE is to put the endpoint into the real target conference.  (Note 
that the initial call would drop the user into the IVR system.)

What I'd like to suggest is to remove the words "(to change the UUID to 
M')", because that is not the main reason for that exchange.


>>  >> >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.
>
>If so, see my section 6 comment. It shouldn't just apply to 
>intermediaries
>and the alignment could potentially be relaxed if CANCEL within dialog.

Agreed.   Section 6 now has this as the next-to-the-last paragraph.  
Sound OK?

"It is also important to note that if an intermediary in the network 
forks a session, the initiating UA may receive multiple responses back 
from different endpoints, each of which contains a different UUID 
(“local-uuid”) value.  UAs MUST take care to ensure that the correct 
UUID value is returned in the “remote” parameter when interacting with 
each endpoint.  The one exception is when the UA sends a CANCEL message, 
in which case the Session-ID header value will be identical to the 
original INVITE. "

Paul