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

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

Brett,

Sorry for the belated reply.  I wasn't ignoring your message, but wasn't 
sure what to do.  I'm still not sure what to do, so let's try to come up 
with some agreeable text.

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

This is largely purposeful.  We do not want intermediaries really 
getting involved in the exchange of UUID values.  The instances where 
they do (e.g., 3PCC), then they are forced to do that, since they will 
potentially be originating UUID values.  If an intermediary is 
responding on behalf of an endpoint, then what the text currently says 
that "if it knows" the UUID value of the opposite endpoint, includes it. 
  Otherwise, it either uses the NULL value or fabricates a value.

In what way would you like to see the text re-worded, keeping in mind 
that we want B2BUAs to take a hands-off approach as much as possible.


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

That would be true of intermediaries like PBXes that are switching calls 
from one leg to another. It's only in situations where the intermediary 
is going to do something that causes endpoints to have the wrong value 
that they need to ensure they convey the right value.  If the SBC is not 
in the business of switching call legs from one device to another like a 
PBX does, it would not have to maintain this state at all.

That said, there is nothing to prevent an SBC from being more 
intelligent and maintaining these values.  It might be good, so long as 
it doesn't block or change them.


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

I guess I'm still missing something.  If a B2BUA exhanges Bob with Carol 
(Alice remains the constant "other endpoint"), then the B2BUA might send 
an INVITE to Carol and connect her to Alice.  This would be like Section 
9.3, where at the end Alice and Carol have different end-to-end values.  
This is a situation where a "nice" B2BUA might send a re-INVITE to Alice 
to inform Alice of the change in UUID values.  This would require such a 
B2BUA to be stateful and keep track of these UUID values.

Or is this another flow?  I'm happy to modify the flows or add text, but 
I'm not sure what you want to add where.  Can you tell me exactly what 
changes you'd like to see?  (Note I modified 9.3 as you can see in the 
exchange with Paul K.)


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

I think I see your point on expanding this sentence:

"When an intermediary transmits a provisional response or a response to 
a CANCEL request, the “remote-uuid” field will contain the UUID value of 
the UA that sent the message that prompted the transmission of the 
provisional response."

Maybe it should be broader:

"When an intermediary transmits a response on behalf of a remote 
endpoint, including a provisional response or a response to a CANCEL 
request, the “remote-uuid” field will contain the UUID value of the UA 
that sent the message that prompted the transmission of the provisional 
response."

The rest of that paragraph goes on to explain that the "local-uuid" 
value will be the remote UA's UUID or "null".

Feel free to re-word the above and I'll insert it into the text :-)


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

Whatever value is received in the "local-uuid" field gets copied into 
the "remote-uuid" field when responding.  So, one of the {A,B} values we 
know exactly what to do with.

The B2BUA could just put the received "remote-uuid" value into the 
tranmitted "local-uuid" field, blinding assuming the endpoint knew the 
right value.  That's what I would do, stick with the idea the B2BUA is 
relatively dumb about UUIDs.  However, the B2BUA could insert a 
different value for the "local-uuid" per the spec, including the null 
value OR the actual UUID of the remote endpoint if it knew it. However, 
I think that's asking the B2BUA to maintain too much intelligence.

Paul