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

[Brett Tate <[e-mail]>]

Hi,

Thanks for the response; reply is inline.

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


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


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


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


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

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.


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