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

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

Brett,

>>  >> I think the answer, regardless, is going to be that
>>  >> the 487 should have the same Session-ID value as the
>>  >> CANCEL or INVITE for the "remote" part.
>>  >
>>  >Is there a snippet within the draft (or an RFC) which
>>  >supports that behavior? SIP has occasionally been vague
>>  >about what can update stored information associated the
>>  >dialog/remote-party (and what all gets rolled back during
>>  >re-INVITE failure); I'm attempting to help avoid this
>>  >draft from having the same issue.
>>
>>  Section 6 (first sentence) says that all non-intermediary
>>  SIP UAs must include the Session-ID header. It then
>>  explains what the format of that message is. There are no
>>  exception, except for CANCEL that we added and provisional
>>  responses.
>
>The UPDATE sent towards the called party changed the Session-ID 
>associated
>with the dialog. Section 6 indicates the following.
>
>"A UA MUST assume that the UUID value of the peer UA MAY change at any
>time due to service interactions. If the UUID value of the peer UA
>changes, the UA MUST accept the new UUID as the peer's UUID and
>include this new UUID as the "remote" parameter in any subsequent
>messages."
>
>Are you saying that the CANCEL received out-of-dialog changed it back 
>or
>something else rolled it back?

No, this has nothing to do with UPDATE or CANCEL.  This is just to 
handle situations such as when a PBX swaps out one endpoint for another. 
  For example, if I press a button on my phone to transfer a call from A 
to B (where I have A on hold and will transfer A to B), the PBX will 
send signaling messages to A that contain B's Session-ID header, for 
example.  When A sees that, it should not treat that as an error.  
Instead, it should just replace what it thought was the UUID (the one 
from my endpoint) with the one from B.

CANCEL does not change the UUID value of the sending endpoint, so the 
above doesn't relate to CANCEL.


>Additionally since the CANCEL's 200 response and INVITE's 487 can be
>generated by the intermediary (before receiving such responses from
>endpoint), what section indicates how the intermediary behaves when
>generating the CANCEL response and INVITE response? I haven't noticed 
>the
>applicable normative text within section 7.

If it is answering on behalf of a remote endpoint and knows what the 
"Session-ID" header value is, it should include that value.

If it does not know (e.g., the remote endpoint has never sent one), I 
think it should follow the same logic we describe for provisional 
responses.  What if we make this change:

"When an intermediary transmits a provisional response >>or a response 
to a CANCEL request<<, ..."

Are there other such cases?


>>  >If your answer is correct, that means that the working
>>  >group thinks that it is better to use the received
>>  >out-of-dialog CANCEL or INVITE local-uuid (instead of
>>  >reflecting the mid-dialog modification) when populating
>>  >the 487's remote-uuid. The behavior seems atypical; I
>>  >usually don't consider an out-of-dialog CANCEL as being
>>  >able to update mid dialog information (or mid-dialog
>>  >updates forgotten before sending failure response).
>>
>>  These values should be the same, since they're part of
>>  the same "session". Now, it's the definition of "session"
>>  that is purposely vague, but the OOD message should have
>>  the same UUID as the INVITE and other in-dialog messages.
>
>That is the issue. The UPDATE changed the UUID so it no longer matches 
>the
>value sent within prior INVITE and subsequent CANCEL. Thus I'm trying 
>to
>determining which remote UUID that the B2BUA should or must include 
>within
>the CANCEL's 2xx, INVITE's 487 response, and non-2xx's ACK when the To 
>tags
>reflect that same dialog that was updated.

Perhaps I need a picture.  Can you tell me again why the UPDATE would 
change the UUIDs?


>>  >If your answer is correct, that means that the working
>>  >group thinks that it is better to use the received
>>  >mid-dialog CANCEL or re-INVITE local-uuid (instead of
>>  >reflecting a subsequent modification) when populating
>>  >the 487's remote-uuid. The behavior seems atypical; I
>>  >usually don't consider a mid-dialog CANCEL as being able
>>  >to update mid-dialog information (or mid-dialog updates
>>  >forgotten before sending failure response).
>>
>>  Is this just a repeat of the previous?
>
>Almost; the distinction is that the CANCEL is sent within dialog (i.e.
>cancelling a re-INVITE).

There should be no difference in the UUID values uses with either 
in-dialog or OOD, as it's sent in relation to the "session".


>>  >What about my ACK questions? Should the ACK sent by B2BUA
>>  >for the 487 (after CANCEL) contain {A, B} or {A2, B}
>>  >during the two situations? Is there a snippet within the
>>  >draft (or an RFC) which supports that behavior?
>>
>>  All messages related to the session should carry the same
>>  UUID values. If the intermediary is manipulating the
>>  exchanges (e.g., switching endpoints B with C, for example),
>>  it should know what UUID to send.
>
>I'm not asking about the intermediary/endpoint that caused the UUID to
>change. I'm asking about another intermediary that is aware of the UUID
>modification (caused by the UPDATE) but subsequently received a CANCEL
>reflecting the old UUID.

In the event that a UUID value changed (which should only be because an 
actual endpoint somewhere downstream changed to another endpoint), that 
new UUID value should be used going forward.  So if some intermediary 
device sees this:

{A.B} -->
  <-- {B,A}

And then some new message comes through with a new value for A (and 
quite possibly B) as follows:
{C,F} -->

If it is going to be responding to messages and use the Session ID 
values, it should immediately take note of {C,F} coming from the left 
side.  If the right side sends a message using the old values:
<-- {B,A}

The B2BUA should use what it knows about:
{C,F} -->

However, the B2BUA could send this:
{C,B} -->

The reason I say that is that that value is what the Session-ID is going 
to be, and a "smart" B2BUA would know that.  However, there is no 
requirement for the B2BUA to be that smart.  One of the objectives in 
the WG was to try really hard to keep the B2BUA out of monkeying around 
with these UUID values and having to manipulate these values.


>>  >To help avoid further confusion, I fixed my following
>>  >questions concerning 487 since I had accidently
>>  >reflected To/From switching behavior instead of
>>  >draft's local/remote switching behavior.
>>  >
>>  >
>>  >> >The CANCEL is sent outside of dialog and would
>>  >> >contain {A, N}. If the 487 from B contains the
>>  >> >same To tag associated with UPDATE's modification,
>>  >> >should the 487 indicate {B, A} or {B, A2}? Should
>>  >> >the ACK sent by B2BUA contain {A, B} or {A2, B}?
>>  >> >
>>  >> >Same questions except UPDATE occurs during a re-INVITE.
>>  >> >
>>  >> >The CANCEL is sent within dialog and would
>>  >> >contain {A, B}. Should the 487 indicate {B, A}
>>  >> >or {B, A2}? Should the ACK sent by B2BUA contain
>>  >> >{A, B} or {A2, B}?
>>
>>  The 487 should contain {B,A} (same UUID for same session).
>>  I'm not sure what's leading you to suggest this A2 value.
>
>The UPDATE changed the UUID to be A2. Section 6 indicates the 
>following;
>but CANCEL containing INVITE's UUID (A) was received after the UPDATE
>modification to A2.
>
>"A UA MUST assume that the UUID value of the peer UA MAY change at any
>time due to service interactions. If the UUID value of the peer UA
>changes, the UA MUST accept the new UUID as the peer's UUID and
>include this new UUID as the "remote" parameter in any subsequent
>messages."

This ties back to the other UPDATE issue above.  I need a picture.  Can 
you draw a trivial flow to explain what you're suggesting.  I must be 
missing something.

Paul