Subject: [Insipid] Use case to consider

From: Adam Roach <[email-masked]>
Date: Mon, 26 Mar 2012 16:13:17 +0200

Here is the use case I tried to describe at the microphone. Do note that 
real PBXes -- some very popular, well-deployed real PBXes -- use 
signaling that looks like this.  I don't believe the current solution 
provides enough information for implementors to know what to do here, 
and I don't think the requirements have enough language around the 
description of the term "session" to point to a clear way for the 
solution to fix that.

First, I'm going to show a simple call between Alice and Bob, through a 
PBX that acts as a back-to-back user agent.

         Alice                Bob                 PBX
           |(1) INVITE (UUID=A)|                   |
           |-------------------------------------->|
           |(2) media          |                   |
           |.......................................|REQ4: UUID stays
           |                   |                   |the same
           |                   |(3) INVITE (UUID=A)|
           |                   |<------------------|
           |                   |(4) media          |
           |                   |...................|
           |                   |(5) 200 (UUID=B)   |
           |                   |------------------>|
           |(6) 200 (UUID=B)   |                   |
           |<--------------------------------------|Session ID is
           |                   |                   |AB everywhere

I think this is uncontroversial, based on the current charter. It's two 
different SIP dialogs (one from Alice to the PBX; one from the PBX to 
Bob), but one Session (the way the INSIPID charter seems to define it, 
and certainly what REQ4 implies).

Now, let's consider what happens when Carol activates a call barge 
function. I know that call barge can be implemented with several 
different call flows, but here's a plausible (and actually deployed) 
signaling flow:

         Alice                Bob                 PBX                Carol
           |(1) INVITE (UUID=A)|                   |                   |
           |-------------------------------------->|                   |
           |(2) media          |                   |                   |
           |.......................................|REQ4: UUID stays   |
           |                   |                   |the same           |
           |                   |(3) INVITE (UUID=A)|                   |
           |                   |<------------------|                   |
           |                   |(4) media          |                   |
           |                   |...................|                   |
           |                   |(5) 200 (UUID=B)   |                   |
           |                   |------------------>|REQ4: UUID stays   |
           |                   |                   |the same           |
           |(6) 200 (UUID=B)   |                   |                   |
           |<--------------------------------------|Session ID is      
|Carol
           |                   |                   |AB everywhere      
|starts
           |                   |                   |                   |call
           |                   |                   |                   
|barge
           |                   |                   |(7) INVITE Join    |
           |                   |                   |(UUID=C)           |
           |                   |                   |<------------------|
           |no signalling here |                   |                   |
           |                   |no signalling here |                   |
           |                   |                   |(8) media          |
           |                   |                   |...................|
           |                   |                   |(9) 200 (UUID=???) |
           |                   |                   |------------------>|
           |                   |                   |REQ3...???         |

You'll see that the whole thing starts falling apart around step 9. In 
this call scenario, there seems to be no behavior that is consistent 
with both REQ4 and REQ3. Certainly the call between Alice and Bob is the 
same session after Carol barges in as it was before.

Also, keep in mind (when thinking about the solution to this) that Carol 
may actually be entering into a call monitoring situation, in which 
Alice and Bob are supposed to be unaware of Carol's presence on the 
call. A solution that requires the PBX to send signaling to Alice and 
Bob would violate the expected confidentiality.

/a

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Mon, 26 Mar 2012 11:17:25 -0500

On 03/26/2012 09:13 AM, Adam Roach wrote:
> |<--------------------------------------|Session ID is |Carol
> | | |AB everywhere |starts
> | | | |call
> | | | |barge
> | | |(7) INVITE Join |
> | | |(UUID=C) |

Thanks for posting this; this is pretty much what I was envisioning when 
you were describing it during the meeting. Indeed, this sort of thing is 
quite common.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 26 Mar 2012 12:45:16 -0400

Adam,

> |call

One could view Carol as an active participant in the conference, even if
silent, but certainly she would be an active participant if she is able to
whisper to either Alice or Bob.  In this case, the PBX could be viewed as an
MCU.  In fact, it is performing a media mixing function, so the definition
fits.  Alternatively, Carol could be viewed as a silent participant and not
really part of the Bob/Carol conversation and more than a Wireshark capture
is.  So, we have three options to consider: 1) Carol is a full member of the
conference, 2) Carol is whispering only to one (say, Bob) and 3) Carol is
silently monitoring.

For (1), the PBX would create a new UUID "E" and send it down to Alice, Bob,
and Carol such that Alice sees a session ID of A || E, Bob sees a session ID
of B || E, and Carol would use C || E.  For anyone interested, it would be
possible to see that all of these sessions are somehow related, but each has
its own unique Session-ID.  Also, the "end" stops at the PBX, as it is now
the conference focus.

For (2), we have the option of the PBX performing the media mixing and call
control (2A) or Bob providing the media mixing and handling call control
(2B).  In both cases, we do not consider Carol to be a member of the
conference as described in (1) above.

For 2A, this means that we have two different conferences: one between Alice
and Bob and one between Bob and Carol.  The PBX is handing media and call
control and does not establish a different session between Carol and Bob:
call control for the session stops at the PBX.  The session is remains
end-to-end between Alice and Bob.  The PBX accepts the INVITE from Carol
with UUID=C and returns its own UUID=D, so the session between Bob and Carol
is C||D.  The PBX alters media it sends to Bob as it sees fit.  Media from
Bob to Alice remains unchanged.

For 2B, Bob has the capability of managing the two sessions itself and
mixing media as required locally.  In that case, Carol sends the INVITE to
the PBX (indicating a barge).  That is forwarded to Bob.  Bob formulates a
second UUID=E and returns that top Carol.  The session between Alice and Bob
remains unchanged (A || B).  There is a new session between Carol and Bob (C
|| E).

In short, the way in which Session IDs are constructed and where the end of
the media flow exists depends on how you wish to implement this feature in
the PBX.  I'd personally either chose to create a separate call as in (2B)
or merge everything into a conference as in (1).

Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 26 Mar 2012 20:04:32 +0000

[as an individual]

I had some comments/questions I had been planning to send on draft-jones-insipid-session-id-00, which fit into Adam's use-case well I think:

1) A lot of times we think about use-cases as having one PBX, or one App-Server, etc.  But in practice there are often many in any given call path.  For example Alice called Bob in Adam's diagram, with both Alice and Bob talking to "the" PBX.  But in the real world Bob could easily be on *another* PBX.  In that case, there could be a Frank who joins the call on Bob's PBX-1, or Bob could conference in Frank, etc., for the same call that Carol joined on PBX-2.  In that case, what is the UUID-pair between PBX-1 and PBX-2?

2) As Adam said, it's extremely common for the operators of PBXes to want to hide the details of call monitoring.  I'd argue it even beyond that, to say they don't even want you to know that the call moves around; for example in a call center from an IVR to an agent-queue/ACD to an agent to potentially voicemail.  So does the PBX always create a virtual UUID "P", which it answers a call with by giving back to Alice "A || P", while internally inside the call center it handles the separate/moving dialogs using "P || B", "P || C", etc.?  If the answer is "yes", then again as above in (1), if there are *two* PBXs, we lose the end-to-end nature of the correlator value, since the first PBX now bridges from "A || P1" to "P1 || P2", and the second PBX from "P1 || P2" to "P2 || B".  I don't think that's a big deal for your intended use-cases, but for troubleshooting it's not much better than what we have now.  Yet arguably it's the multi-PBX type cases that are the hardest to troubleshoot.

3) The draft says this: "Intermediaries such as session border controllers MUST NOT change any Session Identifier component received from an endpoint in a session."  Do you mean this to only apply to SBCs, or to any and all B2BUAs as well, such as PBXs?  Why would an SBC vendor comply with this, if the second-half of the identifier changes as the call moves around, since SBCs are also used to hide such moving? (and yes, SBCs can also process REFERs, re-INVITEs and INVITEs-with-Replaces locally instead of passing them on)

4) It's a nit, but I don't get why the draft concatenates two UUIDs into one "value", instead of just keeping them explicitly separate values. Like with a defined separator, for example.  It also violates the ABNF of "Session-ID-UUID" to concatenate two UUIDs into the single header field value, since a UUID is defined to be a fixed length. (again this is a nit, but I thought I'd mention it so you can fix the ABNF)

-hadriel

On Mar 26, 2012, at 6:45 PM, Paul E. Jones wrote:
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 27 Mar 2012 01:06:08 -0400

Hadriel,

> 1) A lot of times we think about use-cases as having one PBX, or one App-
> Server, etc.  But in practice there are often many in any given call path.
> For example Alice called Bob in Adam's diagram, with both Alice and Bob
> talking to "the" PBX.  But in the real world Bob could easily be on
> *another* PBX.  In that case, there could be a Frank who joins the call on
> Bob's PBX-1, or Bob could conference in Frank, etc., for the same call
> that Carol joined on PBX-2.  In that case, what is the UUID-pair between
> PBX-1 and PBX-2?

I'm having trouble following who is on PBX-1 and PBX-2, but let me provide
an example...

Assuming Alice (using UUID A1) is on PBX-1 and Bob (using UUID B1) is on
PBX-2, then the call from Alice to Bob would have an end-to-end Session-ID
of (A1||B1), with the concatenation order as specified in the draft or, if
we wanted, with each component kept distinct.  (I'm not sure if it matters
whether we concatenate or not, but it is important that we have these
distinct values.)

Assume Frank is on PBX-3 and is brought into the conference somehow by Bob.
The "somehow" is important.  Let's say Bob is in a call with Frank.  Then in
that case, Bob has a separate call with Frank whose Session-ID is (B2||F1).
Now, if Bob "joins" the call locally on his phone, then there are still two
SIP sessions in progress.  There is one from Bob to Alice and one from Bob
to Frank.  Bob might be mixing media locally, but these are two independent
calls and nothing changed w.r.t. to the Session ID as a result of the join.

If, however, Bob somehow pulled both calls into a conference hosted at the
PBX or an MCU, then things changed.  Likely, there was a conference Q
created and the devices were REFERed to Q.  So, there would be a call from
Alice to Q (A1||Q), Bob to Q (B1||Q), and Frank to Q (F1||Q).  B2
disappeared, since that call effectively vanished with the transfer.

It is also possible that the PBX does some magic where it merges media
together.  That's similar to the other example Hadriel asked about and to
which I replied.

SIP allows for one to use very "open" signaling (like a REFER) to bring
calls into a conference and it's also possible that calls are kept separate
and media mixed such that devices are oblivious to the fact that things are
merged.  Perhaps it's useful to ask: who would respond to the BYE message
should Alice send one at any point?  That is indicative of where the session
ends from her perspective.  If the PBX effectively took over as the endpoint
replacing Bob, for example, then that's where the session ends.  It's really
a conference focus without being named as such in this example.
 
> 2) As Adam said, it's extremely common for the operators of PBXes to want
> to hide the details of call monitoring.  I'd argue it even beyond that, to
> say they don't even want you to know that the call moves around; for
> example in a call center from an IVR to an agent-queue/ACD to an agent to
> potentially voicemail.  So does the PBX always create a virtual UUID "P",
> which it answers a call with by giving back to Alice "A || P", while
> internally inside the call center it handles the separate/moving dialogs
> using "P || B", "P || C", etc.?  If the answer is "yes", then again as
> above in (1), if there are *two* PBXs, we lose the end-to-end nature of
> the correlator value, since the first PBX now bridges from "A || P1" to
> "P1 || P2", and the second PBX from "P1 || P2" to "P2 || B".  I don't
> think that's a big deal for your intended use-cases, but for
> troubleshooting it's not much better than what we have now.  Yet arguably
> it's the multi-PBX type cases that are the hardest to troubleshoot.

What you describe seems to be counter to the objective of having an
end-to-end session identifier.  Certainly, a device could have this virtual
"P", but that is like having an SBC today terminate a call and re-originate
it using different identifiers.  In some of the examples Hadriel was
offering, I saw questions of "are we creating a conference and, thus a new
call, or are we just mixing media at some point for calls?"  Those questions
have answers that yield different signaling topologies and, thus, different
answers to what the Session-ID is.

So, this question of introducing "P" and the desire to hide details seems to
go against the objective of the work we're doing here.  Certainly, it could
be done, but not desirable if we want to track anything end-to-end.  This
puts the SBC at the "end", when it's actually in the middle.

> 3) The draft says this: "Intermediaries such as session border controllers
> MUST NOT change any Session Identifier component received from an endpoint
> in a session."  Do you mean this to only apply to SBCs, or to any and all
> B2BUAs as well, such as PBXs?  Why would an SBC vendor comply with this,
> if the second-half of the identifier changes as the call moves around,
> since SBCs are also used to hide such moving? (and yes, SBCs can also
> process REFERs, re-INVITEs and INVITEs-with-Replaces locally instead of
> passing them on)

The "such as" was intended to mean SBCs are just one example.  The same
would be true for a PBX.  The intent was to say that an SBC cannot receive a
UUID "A" from an incoming call and re-write that as  "B" on the outgoing
call.  It must remain as "A".

If we want to change the rules so that the intermediary can re-write the
UUID, then we lose the end-to-end property.

> 4) It's a nit, but I don't get why the draft concatenates two UUIDs into
> one "value", instead of just keeping them explicitly separate values. Like
> with a defined separator, for example.  It also violates the ABNF of
> "Session-ID-UUID" to concatenate two UUIDs into the single header field
> value, since a UUID is defined to be a fixed length. (again this is a nit,
> but I thought I'd mention it so you can fix the ABNF)

I went around on this a bit, too.  I could be persuaded easily to change
this.  What I did not want is to have two headers.  I wanted to have "value"
that could be efficiently compared (versus two where we have to have the
logic "if ((X==a) && (Y=b)) || (X=b) && (Y=a))" to do a comparison.  So, I
specified an order of concatenation to produce a single "value".  Splitting
it right down the middle re-produces the two individual UUIDs, of course.

In any case, I'm open to any suggestions here that make it easier to use.

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Mar 2012 23:01:20 +0200

On 3/26/12 10:04 PM, Hadriel Kaplan wrote:

> Yet arguably it's the multi-PBX type cases that are the hardest to *troubles hoot*.

Best part of the discussion so far. :-)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Mar 2012 23:11:30 +0200

Paul J,

IIRC, what your draft is really proposing is that an identifier be 
assigned per call-*leg*, and that each UA keep track of its own 
call-leg-id and the call-leg-id of some other call-leg in a "session" 
with it. Maybe that is the call-leg-id of the *first* other leg in the 
session, though it could equally well be the *most recent* call-leg-id.
And then when logging, etc. it is to record both of those call-leg-ids.

In principle, I suppose a UA could keep track of more than one 
call-leg-id of other legs in its session, if it becomes aware of them. 
And then it could log whichever it has.

	Thanks,
	Paul K

On 3/27/12 7:06 AM, Paul E. Jones wrote:
> logic "if ((X==a)&&  (Y=b)) || (X=b)&&  (Y=a))" to do a comparison.  So, I

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 28 Mar 2012 19:06:00 -0400

Paul,

As long as "leg" extends end-to-end, then that's roughly correct.  However,
there is enough confusion in terms, so I'd prefer we uses "Session-ID-UUID"
or something.  But, yes, there are two unique IDs, one from Alice and one
from Bob.  These two IDs together are the Session-ID.

For a given call, there should never be more than two UUIDs to track
(Alice's and Bob's).  The remote UUID (Bob's) might change, though, due to
service interactions (e.g., Bob transfers the call to Alice, or Bob's PBX
merges two calls locally into one new call).  Such changes would be noted
with an INVITE (likely) coming to Alice with a new Session-ID-UUID.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Tuesday, March 27, 2012 5:12 PM
> To: [email-masked]
> Subject: Re: [Insipid] Use case to consider
> 
> Paul J,
> 
> assigned per call-*leg*, and that each UA keep track of its own call-leg-
> id and the call-leg-id of some other call-leg in a "session"
> In principle, I suppose a UA could keep track of more than one call-leg-id
> of other legs in its session, if it becomes aware of them.
> >> 1) A lot of times we think about use-cases as having one PBX, or one
> >> App- Server, etc.  But in practice there are often many in any given
> call path.
> >> For example Alice called Bob in Adam's diagram, with both Alice and
> >> Bob talking to "the" PBX.  But in the real world Bob could easily be
> >> on
> >> *another* PBX.  In that case, there could be a Frank who joins the
> >> call on Bob's PBX-1, or Bob could conference in Frank, etc., for the
> >> same call that Carol joined on PBX-2.  In that case, what is the
> >> UUID-pair between
> >> PBX-1 and PBX-2?
> >
> > I'm having trouble following who is on PBX-1 and PBX-2, but let me
> > provide an example...
> >
> > Assuming Alice (using UUID A1) is on PBX-1 and Bob (using UUID B1) is
> > on PBX-2, then the call from Alice to Bob would have an end-to-end
> > Session-ID of (A1||B1), with the concatenation order as specified in
> > the draft or, if we wanted, with each component kept distinct.  (I'm
> > not sure if it matters whether we concatenate or not, but it is
> > important that we have these distinct values.)
> >
> > The "somehow" is important.  Let's say Bob is in a call with Frank.
> > Then in that case, Bob has a separate call with Frank whose Session-ID
> is (B2||F1).
> > Now, if Bob "joins" the call locally on his phone, then there are
> > still two SIP sessions in progress.  There is one from Bob to Alice
> > and one from Bob to Frank.  Bob might be mixing media locally, but
> > these are two independent calls and nothing changed w.r.t. to the
> Session ID as a result of the join.
> >
> > If, however, Bob somehow pulled both calls into a conference hosted at
> > the PBX or an MCU, then things changed.  Likely, there was a
> > conference Q created and the devices were REFERed to Q.  So, there
> > would be a call from Alice to Q (A1||Q), Bob to Q (B1||Q), and Frank
> > to Q (F1||Q).  B2 disappeared, since that call effectively vanished with
> the transfer.
> >
> > together.  That's similar to the other example Hadriel asked about and
> > to which I replied.
> >
> > SIP allows for one to use very "open" signaling (like a REFER) to
> > bring calls into a conference and it's also possible that calls are
> > kept separate and media mixed such that devices are oblivious to the
> > fact that things are merged.  Perhaps it's useful to ask: who would
> > respond to the BYE message should Alice send one at any point?  That
> > is indicative of where the session ends from her perspective.  If the
> > PBX effectively took over as the endpoint replacing Bob, for example,
> > then that's where the session ends.  It's really a conference focus
> without being named as such in this example.
> >
> >> 2) As Adam said, it's extremely common for the operators of PBXes to
> >> want to hide the details of call monitoring.  I'd argue it even
> >> beyond that, to say they don't even want you to know that the call
> >> moves around; for example in a call center from an IVR to an
> >> agent-queue/ACD to an agent to potentially voicemail.  So does the
> >> PBX always create a virtual UUID "P", which it answers a call with by
> >> giving back to Alice "A || P", while internally inside the call
> >> center it handles the separate/moving dialogs using "P || B", "P ||
> >> C", etc.?  If the answer is "yes", then again as above in (1), if
> >> there are *two* PBXs, we lose the end-to-end nature of the correlator
> >> value, since the first PBX now bridges from "A || P1" to
> >> troubleshooting it's not much better than what we have now.  Yet
> >> arguably it's the multi-PBX type cases that are the hardest to
> troubleshoot.
> >
> > end-to-end session identifier.  Certainly, a device could have this
> > virtual "P", but that is like having an SBC today terminate a call and
> > re-originate it using different identifiers.  In some of the examples
> > Hadriel was offering, I saw questions of "are we creating a conference
> > and, thus a new call, or are we just mixing media at some point for
> > calls?"  Those questions have answers that yield different signaling
> > topologies and, thus, different answers to what the Session-ID is.
> >
> > So, this question of introducing "P" and the desire to hide details
> > seems to go against the objective of the work we're doing here.
> > Certainly, it could be done, but not desirable if we want to track
> > anything end-to-end.  This puts the SBC at the "end", when it's actually
> in the middle.
> >
> >
> >> 3) The draft says this: "Intermediaries such as session border
> >> controllers MUST NOT change any Session Identifier component received
> >> from an endpoint in a session."  Do you mean this to only apply to
> >> SBCs, or to any and all B2BUAs as well, such as PBXs?  Why would an
> >> SBC vendor comply with this, if the second-half of the identifier
> >> changes as the call moves around, since SBCs are also used to hide
> >> such moving? (and yes, SBCs can also process REFERs, re-INVITEs and
> >> INVITEs-with-Replaces locally instead of passing them on)
> >
> > The "such as" was intended to mean SBCs are just one example.  The
> > same would be true for a PBX.  The intent was to say that an SBC
> > cannot receive a UUID "A" from an incoming call and re-write that as
> > "B" on the outgoing call.  It must remain as "A".
> >
> > If we want to change the rules so that the intermediary can re-write
> > the UUID, then we lose the end-to-end property.
> >
> >> 4) It's a nit, but I don't get why the draft concatenates two UUIDs
> >> into one "value", instead of just keeping them explicitly separate
> >> values. Like with a defined separator, for example.  It also violates
> >> the ABNF of "Session-ID-UUID" to concatenate two UUIDs into the
> >> single header field value, since a UUID is defined to be a fixed
> >> length. (again this is a nit, but I thought I'd mention it so you can
> >> fix the ABNF)
> >
> > I went around on this a bit, too.  I could be persuaded easily to
> > change this.  What I did not want is to have two headers.  I wanted to
> have "value"
> > that could be efficiently compared (versus two where we have to have
> > the logic "if ((X==a)&&  (Y=b)) || (X=b)&&  (Y=a))" to do a
> > comparison.  So, I specified an order of concatenation to produce a
> > single "value".  Splitting it right down the middle re-produces the two
> individual UUIDs, of course.
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Mar 2012 15:55:29 +0200

> from Bob.  These two IDs together are the Session-ID.

I know you are describing it as one thing, but what you are proposing is 
a *pair* of things. My point is that each "leg" (aka "half call") has 
its own id, and becomes part of a pair. This is exactly analogous to the 
tags (to-tag and from-tag) that form part of the dialog id.

> with an INVITE (likely) coming to Alice with a new Session-ID-UUID.

Its here that what you say gets a bit controversial.

Your use of "call" here is pretty loose - we probably won't all agree 
with what it means, when it starts or ends, etc. Sip has no notion of a 
half call, that can be joined to other half calls to make a full call. 
(Even though B2BUAs do this all the time there is no generally accepted 
terminology for it.)

If we only discuss full e2e calls, and say that they consist of a pair 
of these IDs, fine. But then you start talking about relating calls 
based on matching just half of a pair.

This starts to sound to me like it requires a sort of framework that 
describes these half calls assembled in various ways, how IDs are 
assigned and reassigned to the various pieces, and how and when pairs 
are formed.

	Thanks,
	Paul K

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Mar 2012 23:37:02 -0400

Paul,

> > (Alice's and Bob's).  The remote UUID (Bob's) might change, though,
> > due to service interactions (e.g., Bob transfers the call to Alice, or
> > Bob's PBX merges two calls locally into one new call).  Such changes
> > would be noted with an INVITE (likely) coming to Alice with a new
> Session-ID-UUID.
> 

Of course.  Is anything related to SIP ever not? :-)
 
> Your use of "call" here is pretty loose - we probably won't all agree with
> what it means, when it starts or ends, etc. Sip has no notion of a half
> call, that can be joined to other half calls to make a full call.

Yeah, my use of call here is loose.  And, while SIP has this end-to-end
notion, the reality is often different.  This gets us back to the definition
discussion we had for a "session".  I'd prefer to not use "call" since we're
talking about the "session" initiation protocol... there is a session here
somewhere, and it's not just a media session.
 
> If we only discuss full e2e calls, and say that they consist of a pair of
> these IDs, fine. But then you start talking about relating calls based on
> matching just half of a pair.

I assume you're referring to the MCU case where we're proposing that the MCU
use the same UUID for all participants in a given conference?  It is that
case where I say we can relate calls.  Don't try to complicate this with
some "half call" notion.  Look at it only for what it is: there is a
conference and each participant in the conference has a Session-ID.  The
Session-ID is comprised of two components, one of which is the same value
for all participants in the conference.
 
> describes these half calls assembled in various ways, how IDs are assigned
> and reassigned to the various pieces, and how and when pairs are formed.

I don't think that's necessary.  We're not creating and kind of new call
flow or call scenario that does not already exist in the market.  We should
simply specify that Alice assigns a value A.  Bob assigns a value B.  To
accommodate those call flows of which we cannot speak, Alice or Bob should
be permitted to change its UUID at any time.  We know it might be for
reasons for which we cannot speak, but officially it would be because either
Alice or Bob may change its UUID.

Paul