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

[Brett Tate <[e-mail]>]

Hi,

Thanks for the response; reply is inline.

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

I don't think that it is adequate.

> Are there other such cases?

A B2BUA can generate requests and responses on behalf of both sides.  In my
opinion, section 7 covers some individual situations; however, it appears to
be missing the general case of tracking remote/local UUIDs and then using
the UUIDs when generating (instead of relaying) subsequent requests and
responses associated with the "session".


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

>From an intermediary perspective, it is irrelevant why something on each
side decided to change the supplied UUID.  My understanding is that the
draft requires (or will require) the intermediary to track the change so
that it MAY/SHOULD/MUST be used when the intermediary generates (instead of
relays) subsequent requests and responses associated with the "session".

Concerning "why the UPDATE would change the UUIDs" ... as mentioned within
http://www.ietf.org/mail-archive/web/insipid/current/msg00993.html, a B2BUA
interaction occurred which replaced a user or user's device on one
side while call setup was occurring on the other side.

The picture is the trapezoid model with B2BUAs instead of proxies (i.e.
caller, B2BUA1, B2BUA2, called) with potential forking and replacements
(i.e. "session" changes for a particular dialog).  The B2BUAs generate 487
instead of relaying them.


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

The "session" changed.  Consider hypothetical that B2BUA received INVITE
outside of dialog with {A, N}.  Forking during call setup resulted in {A, B}
and {A, C}.  Because of services while still inviting (and messages sent
over early dialog), the Session-IDs became {X, B} and {Y, C}.  If the CANCEL
with {A, N} was received out of dialog, what should be the Session-ID of
CANCEL's 200 and INVITE's 487 if sent with To tag reflecting dialog of {X,
B}?  If B2BUA then sent CANCEL and the subsequently received 487 (for
INVITE) indicated {C, whatever} with To tag of {Y, C} dialog, what should be
the Session-ID of the 487's ACK?  I assume "whatever" is irrelevant; however
I'm not sure if (and why) ACK's local UUID should be A or Y.


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

I get that; however then CANCEL received outside of dialog indicated {A, B}.
If the B2BUA subsequently generates ACK to the called party over what is/was
{C, F}, should the Session-ID be {A, F} or {C, F} (assuming received 487
indicated "F")?