Subject: [Insipid] Session-ID construction choices

From: James Polk <[email-masked]>
Date: Wed, 11 Jul 2012 14:43:34 -0500

INSIPID

 From yesterday's interim call, we discussed several things, 
including some items already discussed on the list in the last 24 
hours. I want to focus on the identifier construction, now that we 
have decided to communicate both parts of the Session-ID, built by 
both sides, on the wire once the SIP response is transmitted.

    Sidebar: no one has given us authors any technical reason
             why this is not a good idea, other than the length
             of the overall header-value, which many believe is
             outweighed by the certainty of always having the
             full Session-ID to analyze in every message (once
             the response has been transmitted).

There are at least 4 ways to construct the whole Session-ID if both 
halves are present. Whichever way we chose in the final RFC will be 
unquestionably the only way to do it.

Option#1 - attach a prefix (e.g., From: and To:) to each
            half

Option#2 - group together in any order, but each half
            remains unchanged

Option#3 - the half with the lowest value is first,
            with the higher value half second

Option#4 - the initiator of the SIP request half key
            is first, the responder half key is second.

The technical disadvantage for Option #1 is - there is none we are 
aware of, and might be the cleanest or most clear to humans and 
servers (i.e., processes/searches/analysis). However, once there is a 
call join, the From: label loses its meaning. The To: will remain correct.
Option #1 does follow call transfer scenarios nicely, and is easiest analyze.

The technical disadvantage for Option #2 is - loss of directionality, 
if that is ever an issue. The UUID/GUID halves are each unique 
regardless, so searching for a specific value will not be an issue 
during or after the fact.

The technical disadvantage for Option #3 is - loss of directionality, 
if that is ever an issue. The UUID/GUID halves are each unique 
regardless, so searching for a specific value will not be an issue 
during or after the fact. Could lead to confusion to human analysis 
having values switched in order.

The technical disadvantage for Option #4 is - identical to Option #1 
except for tags, which could lead to loss of directionality without 
ever knowing it, if that is ever an issue. The UUID/GUID halves are 
each unique regardless, so searching for a specific value will not be 
an issue during or after the fact.

We have a proposal going forward: insert the From:/To: tags from Option #1.

Does anyone have a technical reason why this wouldn't work?

James

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Jul 2012 17:08:27 -0400

Comment at end.

On 7/11/12 3:43 PM, James Polk wrote:
> INSIPID
>
>  From yesterday's interim call, we discussed several things, including
> some items already discussed on the list in the last 24 hours. I want to
> focus on the identifier construction, now that we have decided to
> communicate both parts of the Session-ID, built by both sides, on the
> wire once the SIP response is transmitted.
>
> The technical disadvantage for Option #1 is - there is none we are aware
> of, and might be the cleanest or most clear to humans and servers (i.e.,
> processes/searches/analysis). However, once there is a call join, the
> From: label loses its meaning. The To: will remain correct.
> The technical disadvantage for Option #2 is - loss of directionality, if
> that is ever an issue. The UUID/GUID halves are each unique regardless,
> so searching for a specific value will not be an issue during or after
> the fact.
>
> The technical disadvantage for Option #3 is - loss of directionality, if
> that is ever an issue. The UUID/GUID halves are each unique regardless,
> so searching for a specific value will not be an issue during or after
> the fact. Could lead to confusion to human analysis having values
> switched in order.
>
> except for tags, which could lead to loss of directionality without ever
> knowing it, if that is ever an issue. The UUID/GUID halves are each
> unique regardless, so searching for a specific value will not be an
> issue during or after the fact.
>

Do you mean to assign From and To once, and then keep it fixed for the 
duration of the dialog? ISTM that From and To are not well defined in 
all cases.

For instance, consider a BTBUA that sets up a session by inviting both 
endpoints. Which is From and which is To? IIUC, the reason for labeling 
this way is so that someone observing a session id in a message can tell 
which half corresponds to which end. Using From and To won't satisfy 
that unless those tags are reassigned for each request.
(This is a special case of a conference focus, which you already call 
out as an exception.)

Identifying which end is which is easy for any single transaction, but 
hard if you want to use the same identifiers in every message. The 
endpoints can easily figure this out, because they should know their 
half, and the half that isn't theirs is the other end's. But its not 
simple for middleboxes.

The solution that is used for dialog ids is to use To and From, but they 
must be reassigned depending on the direction of the message. We could 
do the same for session id, but only if they are remapped based on the 
direction of the request.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Jul 2012 23:16:56 +0200

Hi,

I didn't call in for the interim, so maybe the following was discussed.

First, if we would use the To/From tags, do we assume that the tag values are always passed by an SBC? If an SBC modifies the tag values in the To/From headers, and is aware that they are also present in the session id, it may remove/modify the session id - which is what we want to prevent :)

Second, maybe I've missed something, but if we would use the To/From tags (and assume they are passed unchanged end-to-end), why would we need anything else?

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of James Polk
Sent: 11. heinäkuuta 2012 22:44
To: [email-masked]
Subject: [Insipid] Session-ID construction choices

INSIPID

 From yesterday's interim call, we discussed several things, including some items already discussed on the list in the last 24 hours. I want to focus on the identifier construction, now that we have decided to communicate both parts of the Session-ID, built by both sides, on the wire once the SIP response is transmitted.

There are at least 4 ways to construct the whole Session-ID if both halves are present. Whichever way we chose in the final RFC will be unquestionably the only way to do it.

The technical disadvantage for Option #1 is - there is none we are aware of, and might be the cleanest or most clear to humans and servers (i.e., processes/searches/analysis). However, once there is a call join, the From: label loses its meaning. The To: will remain correct.
Option #1 does follow call transfer scenarios nicely, and is easiest analyze.

The technical disadvantage for Option #2 is - loss of directionality, if that is ever an issue. The UUID/GUID halves are each unique regardless, so searching for a specific value will not be an issue during or after the fact.

The technical disadvantage for Option #3 is - loss of directionality, if that is ever an issue. The UUID/GUID halves are each unique regardless, so searching for a specific value will not be an issue during or after the fact. Could lead to confusion to human analysis having values switched in order.

The technical disadvantage for Option #4 is - identical to Option #1 except for tags, which could lead to loss of directionality without ever knowing it, if that is ever an issue. The UUID/GUID halves are each unique regardless, so searching for a specific value will not be an issue during or after the fact.

James

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Jul 2012 17:25:42 -0400

> Second, maybe I've missed something, but if we would use the To/From tags (and assume they are passed unchanged end-to-end), why would we need anything else?

Christer - AFAIK the proposal is not to use the tag= values on From and 
To headers. Rather it is to label the two halves of the session id as to 
which corresponds to From and which corresponds to To.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Jul 2012 23:29:27 +0200

Hi, 

>> First, if we would use the To/From tags, do we assume that the tag 
>> values are always passed by an SBC? If an SBC modifies the tag values 
>> in the To/From headers, and is aware that they are also present in the 
>> session id, it may remove/modify the session id - which is what we 
>> want to prevent :)
>>
> Christer - AFAIK the proposal is not to use the tag= values on From and To headers. Rather it is to label the two halves of the session id as to which corresponds to From and which corresponds to To.

Ok. Thanks for the clarification.

Regards,

Christer

---

From: James Polk <[email-masked]>
Date: Wed, 11 Jul 2012 17:23:06 -0500

At 04:08 PM 7/11/2012, Paul Kyzivat wrote:
>Do you mean to assign From and To once, and then keep it fixed for 
>the duration of the dialog? ISTM that From and To are not well 
>defined in all cases.
>
>For instance, consider a BTBUA that sets up a session by inviting 
>both endpoints. Which is From and which is To? IIUC, the reason for 
>labeling this way is so that someone observing a session id in a 
>message can tell which half corresponds to which end. Using From and 
>To won't satisfy that unless those tags are reassigned for each request.
>(This is a special case of a conference focus, which you already 
>call out as an exception.)

The desire is to have the same half in the same position throughout 
the transaction or dialog (whichever it is).  I believe in the case 
of a B2BUA initiating or originating the transaction or dialog on 
behalf of other endpoint UAs, the B2BUA would pick which Session-ID 
is the From and which is the To. IOW - we don't make it a requirement 
on an implementation that Alice is always inserting her half in 
first, and Bob in as the second half. If the B2BUA is sending an 
INVITE to both Alice and Bob, then that's 2 separate Session-IDs 
because it's two different dialogs, even if a 3rd party isn't part 
(i.e., listening) of the media flow. This would be a hub and 2 spokes 
in which the hub doesn't listen or interact with the media of the 2 UAs.

We could also have text that says for this scenario, that an INVITE 
normally inserts the From half of the Session-ID, but that in this 
scenario it can insert the To: half and the invitee inserts the To half.

>Identifying which end is which is easy for any single transaction,

agreed

>but hard if you want to use the same identifiers in every message. 
>The endpoints can easily figure this out, because they should know 
>their half, and the half that isn't theirs is the other end's. But 
>its not simple for middleboxes.

remember that each half is a UUID or GUID, which will always be a 
unique value through space and time.

>The solution that is used for dialog ids is to use To and From, but 
>they must be reassigned depending on the direction of the message. 
>We could do the same for session id, but only if they are remapped 
>based on the direction of the request.

I guess I'm no getting why the halves need to switch places yet 
depending on whether it's in a request or response. Or are you saying 
that for one complete transaction they are in a certain order, but in 
a related transaction(s) they are possibly in the reverse order - 
depending on who sent the message?

James

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Jul 2012 19:37:38 -0400

On 7/11/12 6:23 PM, James Polk wrote:
...
>>> Option#1 - attach a prefix (e.g., From: and To:) to each
...
>> endpoints. Which is From and which is To? IIUC, the reason for
> The desire is to have the same half in the same position throughout the
> transaction or dialog (whichever it is). I believe in the case of a
> B2BUA initiating or originating the transaction or dialog on behalf of
> other endpoint UAs, the B2BUA would pick which Session-ID is the From
> and which is the To. IOW - we don't make it a requirement on an
> implementation that Alice is always inserting her half in first, and Bob
> in as the second half. If the B2BUA is sending an INVITE to both Alice
> and Bob, then that's 2 separate Session-IDs because it's two different
> dialogs, even if a 3rd party isn't part (i.e., listening) of the media
> flow. This would be a hub and 2 spokes in which the hub doesn't listen
> or interact with the media of the 2 UAs.
>
>> but hard if you want to use the same identifiers in every message. The
> remember that each half is a UUID or GUID, which will always be a unique
> value through space and time.
>
>
>> they must be reassigned depending on the direction of the message. We
>> could do the same for session id, but only if they are remapped based
>> on the direction of the request.
>
> that for one complete transaction they are in a certain order, but in a
> related transaction(s) they are possibly in the reverse order -

When a message is sent in the reverse direction from the dialog 
establishing message, the From URI and To URI are reversed, as well as 
the From and To tags. If the session id still has its halves tagged 
consistent with the from and to of the dialog establishing request, then 
you will get confused about which half goes with which end.

There is no problem for servers that keep state and remember the values 
for each end. For them we don't need to tag the halves at all.

There is also no problem for those who don't *care* which end is which. 
And there may be a lot of those.

This tagging is only there for those who don't keep state yet need to 
know. Maybe there aren't any of those, in which case we can stop 
worrying about it.

I guess an example that might matter is something analyzing logs, and 
doesn't have a complete set of logs available to it - in particular it 
doesn't have a log of the initial signaling that set up the session, so 
it can't figure out which half-id belongs to which end.

Then it sees a change - it sees a message where half of the id matches 
prior things, but the other half doesn't - is new. From this it can 
perhaps infer that there was a transfer. And in that case it will want 
to know which end remains and which was replaced. But it can't figure 
that out from which half of the id changed without knowing the mapping 
from half to end.

But I will be the first to say that this case is somewhat implausible. 
In practice there will be lots of stuff in the messages being analyzed 
that should support figuring this out. Perhaps this just isn't a good 
example, and there is another that is better. But I don't know a better 
one. Anybody else? (I think Paul J was the one who raised this concern, 
so maybe he has an example.)

If we can't find a plausible reason why we need to do this mapping, then 
I propose that we just not bother. In that case I think representation 
#3 is attractive. It provides for the easiest comparison between id 
values - a single string comparison is sufficient. And its among the 
most compact representations. I'd recommend:

	session-id: SmallestHalf:BiggestHalf

Or just

	session-id: FirstHalf

before the half for the far end has been assigned.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 12 Jul 2012 08:15:27 +0200

> Second, maybe I've missed something, but if we would use the To/From tags (and assume they are passed unchanged end-to-end), why would we need anything else?

Using the from/to-tags, do we reveal information that could be misused as these are used for Invite/Replaces and other things? There are a lot of assumptions in SIP that if you know the identifiers of the dialog/transaction you have the right to operate on it.

/O
> Does anyone have a technical reason why this wouldn't work?

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 12 Jul 2012 08:32:50 +0000

> which corresponds to From and which corresponds to To.

OK Yes I think this is what is being proposed but I am struggling to understand how this can work in 3PCC scenarios but having said that I am not sure how any of the proposed solutions work in 3PCC scenarios would they need a re-negotiation of the session-id after the completion of 3PCC procedures?

I think we previously agreed to include a 3PCC use case in the requirements draft but I don't see it so I will provide some proposed text for the requirements. 

Regards
Andy

> hours. I want to focus on the identifier construction, now that we have
> decided to communicate both parts of the Session-ID, built by both
> sides, on the wire once the SIP response is transmitted.
> >
> aware of, and might be the cleanest or most clear to humans and servers
> (i.e., processes/searches/analysis). However, once there is a call
> join, the From: label loses its meaning. The To: will remain correct.

---

From: James Polk <[email-masked]>
Date: Thu, 12 Jul 2012 13:26:06 -0500

At 01:15 AM 7/12/2012, Olle E. Johansson wrote:

> > First, if we would use the To/From tags, do 
> we assume that the tag values are always passed 
> by an SBC? If an SBC modifies the tag values in 
> the To/From headers, and is aware that they are 
> also present in the session id, it may 
> remove/modify the session id - which is what we want to prevent :)
> >
> > Second, maybe I've missed something, but if 
> we would use the To/From tags (and assume they 
> are passed unchanged end-to-end), why would we need anything else?
>
>Using the from/to-tags,

we're not using the from and to tags, period. 
There are many reasons why not that have been said already.

James

>do we reveal information that could be misused 
>as these are used for Invite/Replaces and other 
>things? There are a lot of assumptions in SIP 
>that if you know the identifiers of the 
>dialog/transaction you have the right to operate on it.
>
>/O
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of James Polk
> > From yesterday's interim call, we discussed 
> several things, including some items already 
> discussed on the list in the last 24 hours. I 
> want to focus on the identifier construction, 
> now that we have decided to communicate both 
> parts of the Session-ID, built by both sides, 
> on the wire once the SIP response is transmitted.
> >
> > There are at least 4 ways to construct the 
> whole Session-ID if both halves are present. 
> Whichever way we chose in the final RFC will be 
> > The technical disadvantage for Option #1 is - 
> there is none we are aware of, and might be the 
> cleanest or most clear to humans and servers 
> (i.e., processes/searches/analysis). However, 
> once there is a call join, the From: label 
> loses its meaning. The To: will remain correct.
> > The technical disadvantage for Option #2 is - 
> loss of directionality, if that is ever an 
> issue. The UUID/GUID halves are each unique 
> regardless, so searching for a specific value 
> will not be an issue during or after the fact.
> >
> > The technical disadvantage for Option #3 is - 
> loss of directionality, if that is ever an 
> issue. The UUID/GUID halves are each unique 
> regardless, so searching for a specific value 
> will not be an issue during or after the fact. 
> Could lead to confusion to human analysis having values switched in order.
> >
> > The technical disadvantage for Option #4 is - 
> identical to Option #1 except for tags, which 
> could lead to loss of directionality without 
> ever knowing it, if that is ever an issue. The 
> UUID/GUID halves are each unique regardless, so 
> searching for a specific value will not be an issue during or after the fact.
> >

---

From: James Polk <[email-masked]>
Date: Thu, 12 Jul 2012 13:37:37 -0500

At 03:32 AM 7/12/2012, Hutton, Andrew wrote:
>OK Yes I think this is what is being proposed 
>but I am struggling to understand how this can 
>work in 3PCC scenarios but having said that I am 
>not sure how any of the proposed solutions work 
>in 3PCC scenarios would they need a 
>re-negotiation of the session-id after the completion of 3PCC procedures?
>
>I think we previously agreed to include a 3PCC 
>use case in the requirements draft but I don't 
>see it so I will provide some proposed text for the requirements.

We need a proposed use-case as well as proposed 
requirements text. IOW, saying "3PCC" is not 
enough for some (many?) to understand what all 
there is to the scenario that needs to be 
accounted for. At the same time, the use-case 
needs to be concise (good luck, huh?).

Actually, what also wouldn't be bad to have is a 
single PPT slide explaining the 3PCC scenario as 
you see it. This gives a visual for the WG in the 
session. For example, I can imagine a 3PCC 
scenario as a remote application (perhaps sitting 
on a server) that contacts a B2BUA or a 
conference bridge to INVITE both Alice and Bob to 
a dialog.  The conference bridge aspect we 
already cover in the MCU requirement that we're 
had in our slides for a while (treated as a pt2pt 
between the MCU and Alice, and another between 
the MCU and Bob). The application getting a B2BUA 
to initiate a call between Alice and Bob via the 
B2BUA not acting as a MCU is another scenario. 
I'm not sure that is what you're after, or 
detailed enough if it is what you're after.

James

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Jul 2012 14:58:52 -0400

On 7/12/12 2:37 PM, James Polk wrote:

> We need a proposed use-case as well as proposed requirements text. IOW,
> saying "3PCC" is not enough for some (many?) to understand what all
> there is to the scenario that needs to be accounted for. At the same
> time, the use-case needs to be concise (good luck, huh?).

The following is from RFC 3725. There are many alternative flows there, 
but for this discussion it doesn't matter so this is a simple one:

              A              Controller               B
              |(1) INVITE no SDP  |                   |
              |<------------------|                   |
              |(2) 200 offer1     |                   |
              |------------------>|                   |
              |                   |(3) INVITE offer1  |
              |                   |------------------>|
              |                   |(4) 200 OK answer1 |
              |                   |<------------------|
              |                   |(5) ACK            |
              |                   |------------------>|
              |(6) ACK answer1    |                   |
              |<------------------|                   |
              |(7) RTP            |                   |
              |.......................................|

This establishes an e2e session between A and B with a B2BUA in the 
middle. Presumably we want to end up with a session id that has one half 
associated with A and one half associated with B. But both A and B think 
they are the "To" party in establishing the session.

This also presents a difficulty for message (1). What half id does the 
controller assign for the From half in the INVITE?

	Thanks,
	Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 12 Jul 2012 19:13:02 +0000

Hi Paul,

Thanks, This it is exactly the scenario and problem I was referring to.

Regards
Andy

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 12 July 2012 20:59
> To: James Polk
> Cc: Hutton, Andrew; [email-masked]
> Subject: Re: [Insipid] Session-ID construction choices
>

---

From: James Polk <[email-masked]>
Date: Thu, 12 Jul 2012 14:26:20 -0500

At 01:58 PM 7/12/2012, Paul Kyzivat wrote:
>The following is from RFC 3725. There are many alternative flows 
>there, but for this discussion it doesn't matter so this is a simple one:
>
>              A              Controller               B
>              |(1) INVITE no SDP  |                   |
>              |<------------------|                   |
>              |(2) 200 offer1     |                   |
>              |------------------>|                   |
>              |                   |(3) INVITE offer1  |
>              |                   |------------------>|
>              |                   |(4) 200 OK answer1 |
>              |                   |<------------------|
>              |                   |(5) ACK            |
>              |                   |------------------>|
>              |(6) ACK answer1    |                   |
>              |<------------------|                   |
>              |(7) RTP            |                   |
>middle. Presumably we want to end up with a session id that has one 
>half associated with A and one half associated with B. But both A 
>and B think they are the "To" party in establishing the session.

One way of addressing this - that Laura might not like - is to allow 
a null header-value with the stipulation that UA A MUST populate this 
header with their "half" upon receipt of a SIP request that has an 
unpopulated/null Session-ID header-value. This will result in the 200 
OK in message 2 to have UA A's half, and the INVITE in message 3 
includes that half awaiting the 200 OK in message 4 to include the 
other half of the Session-ID.

This alternative means that the offer from A (message 2) must be 
received before the message 3 INVITE is sent to B. Is that 
acceptable? It seems to be wrt containing the offer1 SDP.

A slightly different alternative to the above is to make a rule that 
UA A adds a Session-ID to any request it receives without a 
Session-ID, and add it's half of the header-value. Where a B2BUA is 
not involved, the ACK would contain the other half.

James

>This also presents a difficulty for message (1). What half id does 
>the controller assign for the From half in the INVITE?
>
>         Thanks,
>         Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 12 Jul 2012 19:46:58 +0000

Hi,

I propose the following text as a new use case for section 3.3 of draft-ietf-insipid-session-id-reqts

3.3 3PCC Use Case.

Third party call control refers to the ability of one entity to create a call in which communication is actually between other parties. For example a B2BUA acting as a third party controller may establish a call between two SIP UA's using 3PCC procedures as described in section 4.1 of RFC 3725 the flow for which is reproduced below.

              A              Controller               B
              |(1) INVITE no SDP  |                   |
              |<------------------|                   |
              |(2) 200 offer1     |                   |
              |------------------>|                   |
              |                   |(3) INVITE offer1  |
              |                   |------------------>|
              |                   |(4) 200 OK answer1 |
              |                   |<------------------|
              |                   |(5) ACK            |
              |                   |------------------>|
              |(6) ACK answer1    |                   |
              |<------------------|                   |
              |(7) RTP            |                   |

Such a flow must result in a single session identifier being used for the communication session between UA A and UA B.

New REQ10:

REQ10: It must be possible to correlate two end-to-end sessions when the sessions are created by a third party controller using 3PCC procedures as described in RFC 3575. 

Regards
Andy

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Jul 2012 15:49:43 -0400

On 7/12/12 3:26 PM, James Polk wrote:
>> half associated with A and one half associated with B. But both A and
>> B think they are the "To" party in establishing the session.
>
> One way of addressing this - that Laura might not like - is to allow a
> null header-value with the stipulation that UA A MUST populate this
> unpopulated/null Session-ID header-value. This will result in the 200 OK
> in message 2 to have UA A's half, and the INVITE in message 3 includes
> that half awaiting the 200 OK in message 4 to include the other half of
> the Session-ID.

Yes, this is analogous to the offerless invite.

> received before the message 3 INVITE is sent to B. Is that acceptable?
> It seems to be wrt containing the offer1 SDP.

There are lots of different ways to do 3pcc, but this is probably 
acceptable.

> A slightly different alternative to the above is to make a rule that UA
> A adds a Session-ID to any request it receives without a Session-ID, and
> add it's half of the header-value. Where a B2BUA is not involved, the
> ACK would contain the other half.

That would work *if* there is no intervening B2BUA that takes 
responsibility for inserting the first half id. But that is a bad bet to 
make - there are no doubt lots of cases where that is exactly what would 
happen.

Another way is for the controller to provide a half id (say X) for 
itself in (1). It then gets both halves back from A in (s). (Say X:A)
Then it provides X again in (3), and gets back X:B in (4). Finally it 
constructs an ID (A:B) for the e2e call and sends that in (5) and (6). 
But this is pretty ugly.

	Thanks,
	Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 12 Jul 2012 20:04:50 +0000

See below.

Regards
Andy

> Sent: 12 July 2012 21:50
> and
> a
> OK

[AndyH] - Yes I kind of like that.

> acceptable?

[AndyH] - I think this most likely would be ok.

> UA

[AndyH] - We have to assume that there could be a B2BUA/SBC between the controller and the UA this is very common scenario.

> the

---

From: James Polk <[email-masked]>
Date: Thu, 12 Jul 2012 14:41:52 -0500

>Thanks, This it is exactly the scenario and problem I was referring to.

ok, cool. This is probably the simplest case I know of. I was afraid 
you wanted some totally whacked out corner case, and I'm thankful you don't.

;-)

Now, what do you think of my response in the other message as to 
potential ways forward on this topic?

James

---

From: James Polk <[email-masked]>
Date: Thu, 12 Jul 2012 15:29:28 -0500

At 02:46 PM 7/12/2012, Hutton, Andrew wrote:
>Third party call control refers to the ability of one entity to 
>create a call in which communication is actually between other 
>parties. For example a B2BUA acting as a third party controller may 
>establish a call between two SIP UA's using 3PCC procedures as 
>described in section 4.1 of RFC 3725 the flow for which is reproduced below.
>
>               A              Controller               B
>               |(1) INVITE no SDP  |                   |
>               |<------------------|                   |
>               |(2) 200 offer1     |                   |
>               |------------------>|                   |
>               |                   |(3) INVITE offer1  |
>               |                   |------------------>|
>               |                   |(4) 200 OK answer1 |
>               |                   |<------------------|
>               |                   |(5) ACK            |
>               |                   |------------------>|
>               |(6) ACK answer1    |                   |
>               |<------------------|                   |
>               |(7) RTP            |                   |
>Such a flow must result in a single session identifier being used 
>for the communication session between UA A and UA B.
>
>New REQ10:
>
>REQ10: It must be possible to correlate two end-to-end sessions when 
>the sessions are created by a third party controller using 3PCC 
>procedures as described in RFC 3575.

For this new req10, I'm concerned about opening up the Session-ID to 
a MUST comply with all that's described in RFC 3725. For example, the 
above diagram is Figure 1 from that RFC. Whereas figures 2 and 4 from 
that RFC make things a fair amount more complicated wrt following the 
offer/answer model.

If we limit our req(whatever number) to just 'must support 3PCC as 
described in Figure 1 of RFC 3725', then I'm far more open to it.

In other words, if our solution, based on this req<#?> covers more 
3PCC scenarios, great, but I'd like that not to be a must for our 
solution. Remember, our solution must solve each of the reqs in our 
reqs document - because the chairs have said they will not progress 
whatever solution draft forward if it doesn't address each. I don't 
want certain 3PCC scenarios to be what kills this effort. Just like 
Adam doesn't want focus based conferencing to kill it either.

Is this agreeable?

James

---

From: James Polk <[email-masked]>
Date: Thu, 12 Jul 2012 15:33:23 -0500

At 02:49 PM 7/12/2012, Paul Kyzivat wrote:
>There are lots of different ways to do 3pcc, but this is probably acceptable.
>
>responsibility for inserting the first half id. But that is a bad 
>bet to make - there are no doubt lots of cases where that is exactly 
>what would happen.
>
>Then it provides X again in (3), and gets back X:B in (4). Finally 
>it constructs an ID (A:B) for the e2e call and sends that in (5) and 
>(6). But this is pretty ugly.

that's a little convoluted, but if the results are always valid 
(i.e., doesn't break), I'm ok with it.

Each UA will be paying attention to only its half of the id. One 
problem would be intermediary B2BUAs and stateful proxies tracking 
the full id value, and seeing the change in overall value. This would 
normally be the case for a call transfer, but here there's been no 
change - other than half the value changed. Is that acceptable?

James

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 24 Jul 2012 22:51:36 -0400

Paul,

Following up on this thread, as I did not see an outcome.  I think this
message might be the last in the series on this topic.

I think your proposal is along the lines of what we originally proposed. As
I understand, there is a desire to always include both A and B's halves.
That's fine, so long as devices understand they might change from one
message to the next.

So given these two abbreviated UUIDs:

UUID 1: 0xaeffa652
UUID 2: 0xbe11afc8

We would have:

Session-ID: 0xaeffa652be11afc8

If we agree to encode it in hex and agree on the size (a 16 octet UUID),
that means this will always be a 64-byte hex string and there is no need to
put a :.  We could also base64 encode the 64 octet binary value, which would
encode in 44 octets (shaving off 20 octets).  Do we want to go for reduced
size or more readable hex string?

As for putting the entire Session-ID into messages, there are many
situations where the Session-ID will be wrong.  Let me give you just one
example.

Syntax:
  A == B means A is in a call with B

A == B && A == C  (A in call with B; A has a separate call with C.)

       && B == D  (B has a separate call with D)

A & B are talking.  A puts B on hold.
A starts talking to C.
Meanwhile B puts A on hold and talks to D.

A performs some action to join B and C, while at the same time
B performs some action to join D and C

Assuming a PBX does this magic, we might have some INVITE messages going
down the wire like this:

        +  INVITE ----> C (so C can talk to B)  (Session-ID: B || C)
PBX1 ---|
        +  INVITE ----> B (so B can talk to C)  (Session-ID: B || C)

And we have

        +  INVITE ----> A (so A can talk to D)  (Session-ID: A || D)
PBX2 ---|
        +  INVITE ----> D (so D can talk to A)  (Session-ID: A || D)

Now, these messages are passing on the wire at the same time.  So that
message from PBX1 heading toward B is actually now heading toward D.

So, what D receives is Session-ID "B || C".  D thought the Session-ID was A
|| D.  It will be confused.  Perhaps PBX2 can massage the Session-ID, but
it's not supposed to do that.  We really don't want intermediaries to touch
it.

To avoid these kinds of race conditions, adding complexity to try to
straighten it out, etc., I very much prefer to have only the Session-ID-UUID
header that contains only the UUID of the sender of the message.  If we did
that, the endpoints in the above scenario would not be confused and the
correct Session-ID could be noted in logs.

Paul

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Wednesday, July 11, 2012 7:38 PM
> To: James Polk
> Cc: [email-masked]
> >>> Option#1 - attach a prefix (e.g., From: and To:) to each half
> ...
> > the transaction or dialog (whichever it is). I believe in the case of
> > a B2BUA initiating or originating the transaction or dialog on behalf
> > of other endpoint UAs, the B2BUA would pick which Session-ID is the
> > From and which is the To. IOW - we don't make it a requirement on an
> > implementation that Alice is always inserting her half in first, and
> > Bob in as the second half. If the B2BUA is sending an INVITE to both
> > Alice and Bob, then that's 2 separate Session-IDs because it's two
> > different dialogs, even if a 3rd party isn't part (i.e., listening) of
> > the media flow. This would be a hub and 2 spokes in which the hub
> > doesn't listen or interact with the media of the 2 UAs.
> >
> establishing message, the From URI and To URI are reversed, as well as the
> From and To tags. If the session id still has its halves tagged consistent
> with the from and to of the dialog establishing request, then you will get
> confused about which half goes with which end.
> 
> know. Maybe there aren't any of those, in which case we can stop worrying
> about it.
> 
> doesn't have a log of the initial signaling that set up the session, so it
> can't figure out which half-id belongs to which end.
> 
> perhaps infer that there was a transfer. And in that case it will want to
> know which end remains and which was replaced. But it can't figure that
> out from which half of the id changed without knowing the mapping from
> half to end.
> 
> one. Anybody else? (I think Paul J was the one who raised this concern, so
> maybe he has an example.)
> 
> If we can't find a plausible reason why we need to do this mapping, then I
> propose that we just not bother. In that case I think representation
> #3 is attractive. It provides for the easiest comparison between id values
> - a single string comparison is sufficient. And its among the most compact
> representations. I'd recommend:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jul 2012 10:59:59 -0400

> size or more readable hex string?

I don't have a strong feeling about hex vs. base64.
But I think it would be good to have a separator (I'm not attached to 
":" - that is just an example.) I realize it isn't logically necessary 
as long as the halves are fixed length. But its not very friendly, and I 
think it is worth "wasting" *1* byte on.

If we go with base64, I agree that we don't need to preserve the 
trailing "==".

> A == B&&  A == C  (A in call with B; A has a separate call with C.)
>
> A&  B are talking.  A puts B on hold.
> A starts talking to C.

I can't fully follow the above. My problem is that I don't know where 
PBX1 and PBX2 fit into the topology of A,B,C,D. So I'm not going to 
speculate much.

> message from PBX1 heading toward B is actually now heading toward D.

???

> it's not supposed to do that.  We really don't want intermediaries to touch

Can you please map out the full topology, and a lot more of the call 
flow you have in mind. (Including REFERs, or some other indication of 
how the PBXs are being instructed what to do.) (There are a million ways 
this could be done.)

> correct Session-ID could be noted in logs.

I'm not ready to leap to this conclusion until I understand the cases 
better.

	Thanks,
	Paul K

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 26 Jul 2012 11:49:42 -0400

Paul,

The topology is basically this:

C --- PBX0
       |
       |
       |
A --- PBX1 --- PBX2 --- B
                |
                |
                |
                D

A is in two separate calls, one with B and one with C.
B is in two separate calls, one with A and one with D.

At about the same time, A transfers the A-B call to C and B transfers the
A-B call to D.

There does not necessarily have to be a REFER. Ideal world, but the PBX
might handle this locally.  Let's just assume the PBX managing these calls
sends a new INVITE, perhaps doing a delayed offer exchange to get C and D
talking.

So, PBX2 sends an INVITE toward A, but PBX1 directs it toward C.
And, PBX1 sends an INVITE toward B, but PBX2 directs it toward D.

Those invite messages would have the wrong session-ID since PBX1 assumed the
ID would be B || C and PBX2 assumed the ID would be A || D.  Since the
endpoints now involved in the call are C and D, the Session-ID should be C
|| D.

If REFER had been used, A would send a REFER to B (referring to C) and B
would send a REFER to A (referring to D) at the same time.  I'm not even
sure how that race condition would be handled.  Perhaps both sides would
reject?  Or would the outcome be that B is in a call with C and A with D? Or
would both cancel the transfer?

Anyway, this is one of those unusual corner cases, I admit.  Still, if it
might happen, we should consider it.

Paul

> Sent: Thursday, July 26, 2012 11:00 AM
> To: Paul E. Jones
> Cc: 'James Polk'; [email-masked]
> > Following up on this thread, as I did not see an outcome.  I think
> > this message might be the last in the series on this topic.
> >
> > I think your proposal is along the lines of what we originally
> > proposed. As I understand, there is a desire to always include both A
> and B's halves.
> > If we agree to encode it in hex and agree on the size (a 16 octet
> > UUID), that means this will always be a 64-byte hex string and there
> > is no need to put a :.  We could also base64 encode the 64 octet
> > binary value, which would encode in 44 octets (shaving off 20 octets).
> > Do we want to go for reduced size or more readable hex string?
> 
> But I think it would be good to have a separator (I'm not attached to ":"
> - that is just an example.) I realize it isn't logically necessary as long
> as the halves are fixed length. But its not very friendly, and I think it
> is worth "wasting" *1* byte on.
> 
> If we go with base64, I agree that we don't need to preserve the trailing
> "==".
> 
> > situations where the Session-ID will be wrong.  Let me give you just
> > one example.
> >
> > Syntax:
> > A performs some action to join B and C, while at the same time B
> > performs some action to join D and C
> >
> > Assuming a PBX does this magic, we might have some INVITE messages
> > going down the wire like this:
> >
> > || D.  It will be confused.  Perhaps PBX2 can massage the Session-ID,
> > || but
> > it's not supposed to do that.  We really don't want intermediaries to
> > touch it.
> 
> Can you please map out the full topology, and a lot more of the call flow
> you have in mind. (Including REFERs, or some other indication of how the
> PBXs are being instructed what to do.) (There are a million ways this
> could be done.)
> 
> > straighten it out, etc., I very much prefer to have only the
> > Session-ID-UUID header that contains only the UUID of the sender of
> > the message.  If we did that, the endpoints in the above scenario
> > would not be confused and the correct Session-ID could be noted in logs.
> 
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Paul Kyzivat
> >>>> message can tell which half corresponds to which end. Using From
> >>>> and To won't satisfy that unless those tags are reassigned for each
> >> request.
> >>> is the  From and which is the To. IOW - we don't make it a
> >>> requirement on an implementation that Alice is always inserting her
> >>> half in first, and Bob in as the second half. If the B2BUA is
> >>> sending an INVITE to both Alice and Bob, then that's 2 separate
> >>> Session-IDs because it's two different dialogs, even if a 3rd party
> >>> isn't part (i.e., listening) of the media flow. This would be a hub
> >>> and 2 spokes in which the hub doesn't listen or interact with the
> media of the 2 UAs.
> >>>
> >>> depending on whether it's in a request or response. Or are you
> >>> saying that for one complete transaction they are in a certain
> >>> order, but in a related transaction(s) they are possibly in the
> >>> reverse order - depending on who sent the message?
> >>
> >> establishing message, the From URI and To URI are reversed, as well
> >> as the  From and To tags. If the session id still has its halves
> >> tagged consistent with the from and to of the dialog establishing
> >> request, then you will get confused about which half goes with which
> end.
> >>
> >> There is no problem for servers that keep state and remember the
> >> values for each end. For them we don't need to tag the halves at all.
> >>
> >> doesn't have a complete set of logs available to it - in particular
> >> it doesn't have a log of the initial signaling that set up the
> >> session, so it can't figure out which half-id belongs to which end.
> >>
> >> Then it sees a change - it sees a message where half of the id
> >> matches prior things, but the other half doesn't - is new. From this
> >> it can perhaps infer that there was a transfer. And in that case it
> >> will want to know which end remains and which was replaced. But it
> >> can't figure that out from which half of the id changed without
> >> knowing the mapping from half to end.
> >>
> >> In practice there will be lots of stuff in the messages being
> >> analyzed that should support figuring this out. Perhaps this just
> >> isn't a good example, and there is another that is better. But I
> >> don't know a better one. Anybody else? (I think Paul J was the one
> >> who raised this concern, so maybe he has an example.)
> >>
> >> If we can't find a plausible reason why we need to do this mapping,
> >> then I propose that we just not bother. In that case I think
> >> representation
> >> values
> >> - a single string comparison is sufficient. And its among the most
> >> compact representations. I'd recommend:
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jul 2012 13:09:48 -0400

> A --- PBX1 --- PBX2 --- B

OK. That is helpful.

> sends a new INVITE, perhaps doing a delayed offer exchange to get C and D

The following is still too scant for me to follow. I'll fill in some 
questions. But basically I'd like to see a call flow for the whole thing.

> So, PBX2 sends an INVITE toward A, but PBX1 directs it toward C.

I suppose you mean that PBX2 is acting on B's desire to connect A to D?
And its sending the request within the PBX1:PBX2 dialog of the 
A:PBX1:PBX2:B session.

> And, PBX1 sends an INVITE toward B, but PBX2 directs it toward D.

And similarly this is PBX1 acting on A's desire to connect B to C, 
sending the request, also within the PBX1:PBX2 dialog of the 
A:PBX1:PBX2:B session.

> ID would be B || C and PBX2 assumed the ID would be A || D.

You are making a bunch of assumptions here.
Why would the session id be changed this early in the process? It isn't 
yet known if this will work.

In reality, these two INVITEs should end up failing due to glare. After 
the backoff the situation will be clearer.

But this depends on the details of the call flow, which is why I want to 
see the detailed call flow before reaching specific conclusions.

> Since the
> sure how that race condition would be handled.

I think in many cases the transfer will be initiated via REFER (because 
it's one of the endpoints that knows it wants the transfer, and the 
REFER is the standard way to act on that.) But then the REFER would be 
intercepted by the PBX, which then finishes it using reINVITEs because 
it isn't confident that the other end supports REFER.

OTOH, REFER has been around for a long time now, so it's not 
unreasonable to let it pass. Both scenarios are worth exploring.

> Perhaps both sides would
> reject?

The REFER would include a Replaces param on the resulting INVITE. That 
would identify the specific dialog being replaced.

In the presence of B2BUAs you then must make some assumptions that they 
will update the dialog id in the Replaces if they forward the REFER. But 
that still leaves a lot of variables.

> Or would the outcome be that B is in a call with C and A with D? Or

Yes, I think so. But I see no alternative to working out the entire call 
flow. And there will be multiple call flows that could work. We can't 
consider them all, but we should explore the popular alternatives.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 26 Jul 2012 14:43:00 -0400

Paul,

> > At about the same time, A transfers the A-B call to C and B transfers
> > the A-B call to D.
> >
> > There does not necessarily have to be a REFER. Ideal world, but the
> > PBX might handle this locally.  Let's just assume the PBX managing
> > these calls sends a new INVITE, perhaps doing a delayed offer exchange
> > to get C and D talking.
> 

Right.  PBX2 might formulate an INVITE that perhaps tries to put A on hold.
It might also put D on hold at the same time, as it prepares to join these
calls.
 
> And similarly this is PBX1 acting on A's desire to connect B to C, sending
> the request, also within the PBX1:PBX2 dialog of the A:PBX1:PBX2:B
> session.

Right.

> > Those invite messages would have the wrong session-ID since PBX1
> > assumed the ID would be B || C and PBX2 assumed the ID would be A || D.
> 

Let's assume the call hold is accepted.  Now PBX2 wants to take the call off
hold and switch the call to D.

We presently have this topology:

C --- PBX0
        |
        |
        |
      PBX1 --- PBX2
                 |
                 |
                 |
                 D

So, as far as the PBXes are concerned, A and B are gone. However, the
opposite PBX is unaware of that.  PBX2 intends to send an INVITE to 'A'
(which is gone) with D's SDP, perhaps.  In any case, it wants to take 'A'
and 'D' off hold and get them communicating.

> the backoff the situation will be clearer.

Using the call hold scenario, both devices are on hold, but the transition
is made as far as the PBX is concerned.  So, the next INVITE that comes from
PBX2 will have an INVITE contains A || D.  PBX1 could forward that to C to
take C off hold, but the problem is the Session-ID is wrong.  This forces
PBX1 to manipulate the Session-ID.

> see the detailed call flow before reaching specific conclusions.

You're right.  Sometimes we might get into glare conditions, but I think the
flow could be constructed to avoid that situation.  It occurs when both
PBXes switch endpoints locally and do it without the more verbose call
transfer signaling.  And, generally one would not want to send a REFER from
PBX1 to PBX2.  It gets into all of the nasty "who pays the bill" problem.

> > If REFER had been used, A would send a REFER to B (referring to C) and
> > B would send a REFER to A (referring to D) at the same time.  I'm not
> > even sure how that race condition would be handled.
> 
> it's one of the endpoints that knows it wants the transfer, and the REFER
> is the standard way to act on that.) But then the REFER would be
> intercepted by the PBX, which then finishes it using reINVITEs because it
> isn't confident that the other end supports REFER.
> 
> OTOH, REFER has been around for a long time now, so it's not unreasonable
> to let it pass. Both scenarios are worth exploring.

I've not given a lot of thought to what issues we might encounter using
REFER.  I assume that would present less problems, as it might force one
side to fail to transfer.  So long as we do not allow a race condition to
occur, we will not have it.

I've been focused on the case where the PBX just performs a transfer locally
(i.e., no REFER).
 
> > Anyway, this is one of those unusual corner cases, I admit.  Still, if
> > it might happen, we should consider it.
> 

But this gets back to my original point on this part: if an endpoint only
send the sender's UUID (not the whole Session-ID), then we avoid this
problem.  The endpoint always knows the Session-ID is its UUID and the
remote UUID.  The remote UUID might change at any time and it could record
this fact.  Intermediaries that care can also not such changes during
mid-call.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 26 Jul 2012 14:52:01 -0400

Paul,

Let me come back to just this part of the dialog.  If we do decide to signal
both UUIDs, perhaps rather than order them as "smaller:larger", how about we
insert them as "Sender:recipient"?

If we always have the sender place his UUID into the "Session-ID:" field
first, then if the second value (recipient) does not match the recipient, it
could ignore that.  It would see that the first value is different and
assume that some kind of mid-call change happened.  When the receiving
endpoint responds, it would send over the correct pair of values.  So, while
the INVITE might have D:A (as in my other example), the reply would contain
C:D.  The reply would be right.

When logging session IDs, we should order them low/high so we can search on
one value.

Paul

> Of Paul E. Jones
> Sent: Tuesday, July 24, 2012 10:52 PM
> To: 'Paul Kyzivat'; 'James Polk'
> Cc: [email-masked]
> I think your proposal is along the lines of what we originally proposed.
> As I understand, there is a desire to always include both A and B's
> halves.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jul 2012 15:07:37 -0400

> When logging session IDs, we should order them low/high so we can search on

It sounds like you are trying to have your cake and eat it too. :-)

By ordering the halves cannonically (e.g. smaller:larger) its easy to 
compare two of them for equality. But then one can't figure out which 
half belongs to which end.

Ordering them sender:recipient makes it straightforward to figure out 
which half belongs to which end. But then comparisons aren't so easy.

And sending sender:receiver but logging smaller:larger presents its own 
issues. If you are logging the messages themselves you won't want to do 
that.

Finally, using sender:receiver means constant rearrangement. (Would you 
have the UAS put its own half first in responses too? Or does it just 
copy the header field from the request?)

Either way can work. Depends on which issues people think are most 
important.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 27 Jul 2012 12:02:56 -0400

Paul,

> > Let me come back to just this part of the dialog.  If we do decide to
> > signal both UUIDs, perhaps rather than order them as "smaller:larger",
> > how about we insert them as "Sender:recipient"?
> >
> > If we always have the sender place his UUID into the "Session-ID:"
> > field first, then if the second value (recipient) does not match the
> > recipient, it could ignore that.  It would see that the first value is
> > different and assume that some kind of mid-call change happened.  When
> > the receiving endpoint responds, it would send over the correct pair
> > of values.  So, while the INVITE might have D:A (as in my other
> > example), the reply would contain C:D.  The reply would be right.
> >
> > When logging session IDs, we should order them low/high so we can
> > search on one value.
> 

What's the point of having a cake if you can't eat it?

> compare two of them for equality. But then one can't figure out which half
> belongs to which end.

Right.
 
> which half belongs to which end. But then comparisons aren't so easy.

Also right.

> issues. If you are logging the messages themselves you won't want to do

What issues?

> have the UAS put its own half first in responses too? Or does it just copy
> the header field from the request?)

The sender of the SIP message would place its UUID first.  So, if Alice
calls Bob, the Session-ID header would be:
  Session-ID: A
(Alice does not know Bob's UUID, so it is absent.)

And the 200 OK from Bob would be:
  Session-ID: B:A

If Alice later sends a re-INVITE, then the Session-ID would be:
  Session-ID: A:B

We could use "Session-ID-UUID" as the header to make it clear that the
fields are the UUIDs, not the actual Session-ID.  The Session-ID should
always be ordered UUIDs, IMO.

We might also want to prescribe what Alice would do if Alice received:
  Session-ID: B:D

What happened here is some kind of transfer/join took place the message
being directed toward Alice was originally targeted to Bob.  Alice should
log "A:B" (or the ordered pair) and send "A:B" back in any response.  This
allows Bob to also see that "D" is replaced with "A".

It does bug me a little that messages contain A:B one way and B:A the other
way.  But, only a little. These are two independent halves and the
procedures should be clear.

> Either way can work. Depends on which issues people think are most

Yeah, I have no strong preference, so long  as we avoid any possible
confusion.  I think ordering the SIP header with Sender:Receiver would
address issues related to timing of messages.

Paul