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

[Brett Tate <[e-mail]>]

Hi,

Thanks for the response; reply is inline.

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

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


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


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


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