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

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 07 Jan 2015 03:44:20 +0000

Brett,

Please accept my apologies for the long delay.  My work priorities were 
shifted and I had to let this sit for a little while.

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

Why say that?  Why not have any CANCEL follow this rule?

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

OK, I get your point.   How about this added to the end of the 
next-to-the-last paragraph in Section 6:

"The one exception is when the UA sends a CANCEL message, in which case 
the Session-ID header value will be identical to the original INVITE."

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

OK

>>>>>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.
OK, you want this added to F2 and F3?

Record-Route: <sip:server10.biloxi.example.com;lr>

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

Which following paragraph?  This one here right below?

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

I don't think there will be a case where the endpoint does not know the 
Session-ID.  The text in 9.4 is just confusing.  This re-INVITE updates 
the UUID to M' only as a side effect.  The real reason for sending the 
re-INVITE is to put the endpoint into the real target conference.  (Note 
that the initial call would drop the user into the IVR system.)

What I'd like to suggest is to remove the words "(to change the UUID to 
M')", because that is not the main reason for that exchange.

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

Agreed.   Section 6 now has this as the next-to-the-last paragraph.  
Sound OK?

"It is also important to note that if an intermediary in the network 
forks a session, the initiating UA may receive multiple responses back 
from different endpoints, each of which contains a different UUID 
(“local-uuid”) value.  UAs MUST take care to ensure that the correct 
UUID value is returned in the “remote” parameter when interacting with 
each endpoint.  The one exception is when the UA sends a CANCEL message, 
in which case the Session-ID header value will be identical to the 
original INVITE. "

Paul

---

From: Brett Tate <[email-masked]>
Date: Wed, 7 Jan 2015 12:15:42 -0500

Hi,

Thanks for the response; reply is inline.

> >> >MUST construct a Session-ID header value exactly like the
> >> >INVITE's Session-ID."
> >>
> >Potentially should make a slight modification to the
> >suggested text so that it only applies to CANCEL outside
> >of dialog.
>

I don't have a strong opinion either way.  Allowing different behavior
within dialog, allows the CANCEL to be more accurate (for example, the local
or remote values may have changed between re-INVITE and CANCEL).  Either
way, the draft would potentially need to clarify if a CANCEL's Session-ID is
allowed to update (or has no impact upon) the dialogs session-id value (for
building CANCEL's 2xx, re-INVITE's 487, et cetera).

<snip>

> OK, I get your point.   How about this added to the end
> of the next-to-the-last paragraph in Section 6:
>
> "The one exception is when the UA sends a CANCEL message,
> in which case the Session-ID header value will be identical
> to the original INVITE."

It sounds okay to me although "will be" potentially needs a normative
modification if not indicated elsewhere; however it may need updating based
upon outcome of the above discussion.

<snip>

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

Since version 11's F5 ACK reflects the 2xx's Contact URI, I don't have a
strong opinion what occurs concerning the Record-Route and Route stuff.

If Record-Route and Route are deemed essential, yes the Record-Route should
be added to F2 and F3.  The Route would also need to be added to F5.

If Record-Route and Route are deemed non-essential, the Record-Route added
to version 11 F4 can be removed.

> >>  >> >Section 9.4

<snip>

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

Yes.

> >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.
>
> I don't think there will be a case where the endpoint
> does not know the Session-ID.  The text in 9.4 is just
> confusing.  This re-INVITE updates the UUID to M' only as a
> side effect.  The real reason for sending the re-INVITE is
> to put the endpoint into the real target conference.  (Note
> What I'd like to suggest is to remove the words "(to change
> the UUID to M')", because that is not the main reason for
> that exchange.

The proposed change is okay with me.

<snip>

> Agreed.   Section 6 now has this as the next-to-the-last
> paragraph.  Sound OK?

See reply concerning "next-to-the-last paragraph in Section 6".

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 08 Jan 2015 04:10:05 +0000

Brett,

OK, it sounds like you're OK with what we have. I think it would be 
important to review those examples to make sure I did put the right 
values in for Route and Record-Route. I'll publish a new version shortly 
and will be happy to modify it more.

I don't think it should be necessary to talk about 487, etc. The rules 
for how to process messages when a Session-ID is present are consistent 
for all exchanges. The CANCEL one is a special case and you successfully 
argued your point for why it should be exactly like the one found in the 
INVITE (.. and with normative language). That's an exception called out, 
but I don't think we need to enumerate every response code. 487 should 
be no different than any other 4xx or 2xx, IMO.

Anyway, let me publish a new draft and let's have another round.

Paul

------ Original Message ------
From: "Brett Tate" <[email-masked]>
To: [email-masked]; [email-masked]
Sent: 1/7/2015 12:15:42 PM
Subject: Re: [Insipid] draft-ietf-insipid-session-id-10: comments

>_______________________________________________
>insipid mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/insipid

---

From: Brett Tate <[email-masked]>
Date: Tue, 20 Jan 2015 13:48:46 -0500

Hi,

> I don't think it should be necessary to talk about
> 487, etc. The rules for how to process messages when
> a Session-ID is present are consistent for all
> exchanges. The CANCEL one is a special case and you
> successfully argued your point for why it should be
> exactly like the one found in the INVITE (.. and
> with normative language). That's an exception called
> out, but I don't think we need to enumerate every
> response code. 487 should be no different than any
> other 4xx or 2xx, IMO.

During call setup, consider an UPDATE from caller that changed Session-ID
from {A, B} to {A2, B}.

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 {A, B} or {A2, B}?  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 {A, B} or {A2, B}?  Should the ACK sent by B2BUA contain {A, B} or
{A2, B}?

Thanks,
Brett

-- 

Meet with us at Mobile World Congress 2015 
<http://www.broadsoft.com/news/mobile-world-congress/>

This email is intended solely for the person or entity to which it is 
addressed and may contain confidential and/or privileged information. If 
you are not the intended recipient and have received this email in error, 
please notify BroadSoft, Inc. immediately by replying to this message, and 
destroy all copies of this message, along with any attachment, prior to 
reading, distributing or copying it.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 23 Jan 2015 04:40:09 +0000

Brett,

>During call setup, consider an UPDATE from caller that changed 

Why would the UPDATE have a different "local" UUID value than what was 
sent before?  I appreciate the "remote" value might have changed.  Maybe 
that's what you meant, but Alice would never change her "A" value.

Once I understand that, perhaps I can better answer your question below. 
  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. 
  The "local" part would have the sending endpoint's UUID value, since we 
do not have a rule that says otherwise.  So, I'd expect some endpoint 
"B" to send this as a Session-ID to Alice in response to a CANCEL or 
UPDATE:

    Session-ID: B; remote: A

Paul

---

From: Brett Tate <[email-masked]>
Date: Fri, 23 Jan 2015 09:44:01 -0500

Hi,

> >During call setup, consider an UPDATE from caller
> >that changed Session-ID from {A, B} to {A2, B}.
>
> Why would the UPDATE have a different "local" UUID
> value than what was sent before?

A B2BUA interaction occurred which replaced a user or user's device on one
side while call setup was occurring on the other side.

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

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

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

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?

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

--

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 24 Jan 2015 00:42:54 +0000

Brett,

>back during re-INVITE failure); I'm attempting to help avoid this draft 

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.

>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.  Ditto for replies to those OOD messages.

>mid-dialog updates forgotten before sending failure response).

Is this just a repeat of the previous?

>there a snippet within the draft (or an RFC) which supports that 

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.

>>  >or {B, A2}? Should the ACK sent by B2BUA contain

The 487 should contain {B,A} (same UUID for same session).  I'm not sure 
what's leading you to suggest this A2 value.

Paul

---

From: Brett Tate <[email-masked]>
Date: Mon, 26 Jan 2015 09:14:39 -0500

Hi,

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

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 27 Jan 2015 19:59:37 +0000

Brett,

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

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

>reflect that same dialog that was updated.

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

>Almost; the distinction is that the CANCEL is sent within dialog (i.e.

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

>modification (caused by the UPDATE) but subsequently received a CANCEL

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.

>include this new UUID as the "remote" parameter in any subsequent

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

---

From: Brett Tate <[email-masked]>
Date: Wed, 28 Jan 2015 12:16:22 -0500

Hi,

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

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