Subject: [Insipid] Query on solution draft

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 26 Jun 2012 12:30:11 +0200

(As individual)

The scenario I was trying to explain on the call yesterday was as follows.

(I agree it is a bit contrived as stated, but I am convinced all the elements of it exist in the multiple call multiple in progress transfers that exist on attendants consoles on enterprise networks).

A calls B
A makes a second call to B

B calls C
B makes a second call to B

B transfers the first call from A to the first call to C
B transfers the second call from A to the second call to C

Does the solution provided in draft-jones-insipid-session-id-00 allow me to:

-	identify from the session identifier the relationship between the first call before transfer and the first call after transfer, and 

-	the relationship between the second call before transfer and the second call after transfer 

at both the UA of user A and at the UA of user C, and if so how?

There may be readers who are also interested in doing this at an SBC near each of these users, but that is not my question.

Regards

Keith

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 27 Jun 2012 22:38:04 -0400

Keith,

> (I agree it is a bit contrived as stated, but I am convinced all the
> elements of it exist in the multiple call multiple in progress transfers
> that exist on attendants consoles on enterprise networks).

No worries.  I like corner cases, myself, as I hate it when things do not
work.
 
> A calls B

Session ID would be A1 || B1

> A makes a second call to B

Session ID would be A2 || B2

> B calls C

Session ID would be B3 || C1

> B makes a second call to B

I assume you meant C, in which case

Session ID would be B4 || C2
 
> B transfers the first call from A to the first call to C

Do you mean is truly transferred a particular call to a particular call?  As
in a call join? In the case of joining, then A1 || B1 disappears.  Also, B3
|| C1 disappears.  The joined call would have a Session ID of A1 || C1.

Now, had B just transferred that first call with A to C, then the session ID
might have been A1 || C3 (or something).  Then the call B3 || C1 disappears.

> B transfers the second call from A to the second call to C

Again, I assume this is a call join.  We would have a resulting call between
A and C with the Session ID A2 || C2.
 
> -	identify from the session identifier the relationship between the
> first call before transfer and the first call after transfer, and

One cannot necessarily understand what the relationship is, but one could
observe that there is a relationship.
 
> second call after transfer

Same thing.  Nothing about the IDs explain what the relationships are.

> There may be readers who are also interested in doing this at an SBC near
> each of these users, but that is not my question.

Exactly what would people want to do?  Understand there is a relationship or
understand there is a particular type of relationship?

Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 28 Jun 2012 12:46:40 +0200

I was only interested in identifying if a relationship could be identified, not the form of that relationship, i.e. that in some way call 1 from A-C is some reincarnation of call 1 from A-B (as opposed to call 2), not that this occurred because B transferred the call to C (that should be handed by service specific mechanisms where privacy of that information may well be defined).

But part of my lack of understanding is what happens on the protocol when only half ID's are sent.

Any chance of indicating (according to the current draft) which messages carry which half IDs?

Keith

-----Original Message-----
From: Paul E. Jones [mailto:[email-masked]] 
Sent: 28 June 2012 03:38
To: DRAGE, Keith (Keith); [email-masked]
Subject: RE: [Insipid] Query on solution draft

Keith,

 

 

 

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 28 Jun 2012 11:48:37 -0400

Keith,

The current thinking was that all messages from Alice would contain Alice's
Session-ID-UUID header.  Likewise, all messages from Bob would contain Bob's
Session-ID-UUID.

We've had some discussion about having endpoints insert the entire
Session-ID value once it is known.  In that case, Bob would include the
entire Session-ID in 1xx, 2xx messages.  However, I've not fully considered
what happens in that case when calls are joined to different calls on two
ends at the same time. I think there are some race condition opportunities
in that case.  So, it might be that, rather than including the entire
Session-ID concatenated as we prescribed, we could include each as separate
components like:
  Session-ID: L:local_value; R:remote_value

Local and remote is a matter of perspective, but we could work out the
language.

Bottom line is that we have something proposed, but are willing to consider
other approaches.

Paul

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of DRAGE, Keith (Keith)
> Sent: Thursday, June 28, 2012 6:47 AM
> To: Paul E. Jones; [email-masked]
> Subject: Re: [Insipid] Query on solution draft
> 
> I was only interested in identifying if a relationship could be
> identified, not the form of that relationship, i.e. that in some way call
> 1 from A-C is some reincarnation of call 1 from A-B (as opposed to call
> 2), not that this occurred because B transferred the call to C (that
> should be handed by service specific mechanisms where privacy of that
> information may well be defined).
> 
> > elements of it exist in the multiple call multiple in progress
> > transfers that exist on attendants consoles on enterprise networks).
> 
> Do you mean is truly transferred a particular call to a particular call?
> As in a call join? In the case of joining, then A1 || B1 disappears.
> Also, B3
> Now, had B just transferred that first call with A to C, then the session
> ID might have been A1 || C3 (or something).  Then the call B3 || C1
> disappears.
> 
> Again, I assume this is a call join.  We would have a resulting call
> between A and C with the Session ID A2 || C2.
> 
> > Does the solution provided in draft-jones-insipid-session-id-00 allow
> > me
> > to:
> >
> > There may be readers who are also interested in doing this at an SBC
> > near each of these users, but that is not my question.
> 
> Exactly what would people want to do?  Understand there is a relationship
> or understand there is a particular type of relationship?
> 
> Paul
> 
> 
> 
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: James Polk <[email-masked]>
Date: Thu, 28 Jun 2012 14:46:17 -0500

Keith

I believe it is harder to determine the 'relationship' if only half 
keys are sent in SIP (after the initial INVITE which can only have 1 
half key). The only issue IMO is Session-ID header-value size (i.e., 
it'll be twice as long, and there will be a lot of characters in any 
UUID/GUID).

If we agree that once the whole Session-ID is compiled, meaning the 
GUID from UA1 and the GUID from UA2 are concatenated in some order, 
that header value remains on in all SIP messages between those 2 UAs 
until session termination or a transfer or join operation occurs.

I think this is the right way forward. Is this agreeable to everyone?

If that is agreeable, once a session (UA1|UA2) is transferred by UA2 
for UA1 to 'talk' to UA3, UA1's same GUID is what survives intact in 
this new Session-ID value (UA1|UA3). Knowing the GUIDs from each UA 
MUST be different for different sessions, it doesn't matter how many 
times any two or more UAs call other UAs. Further, by doing simple 
tracking of a database of GUIDs for previous sessions, it will be 
fairly trivial to track the evolution of the same session that was 
transferred or joined several times throughout its lifetime by tracking GUIDs.

In other words, once a GUID (i.e., half key) is assigned to a 
session, it is paired with another GUID to form a Session-ID. If that 
session is transferred or joined to another UA, only 1 of the GUIDs 
is replaced during that join or transfer, meaning there is a retained 
relationship. The same is true during the next transfer or join (one 
GUID is retained and the other is replaced), which can be tracked 
fairly easily.

Is this clearer?

James

At 05:46 AM 6/28/2012, DRAGE, Keith (Keith) wrote:
>identified, not the form of that relationship, i.e. that in some way 
>call 1 from A-C is some reincarnation of call 1 from A-B (as opposed 
>to call 2), not that this occurred because B transferred the call to 
>C (that should be handed by service specific mechanisms where 
>privacy of that information may well be defined).
>

---

From: James Polk <[email-masked]>
Date: Thu, 28 Jun 2012 14:47:05 -0500

>   Session-ID: L:local_value; R:remote_value

I think this is unnecessary.

James

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Jun 2012 16:09:40 -0400

> I think this is unnecessary.

There is no fundamental difference between:

   Session-ID: L:local_value; R:remote_value
and
   Session-ID: local_value:remote_value

And regarding which order they are concatenated, there are two choices:

- Order them when concatenated, and use literal string compare.
   E.g. always arrange <first>:<second> such that <first> < <second>

- Transmit the two parts in arbitrary order, but order them
   at time of comparison. E.g. if you want to compare A:B to C:D,
   compare min(A,B) to min(C,D) and max(A,B) to max(C,D)

Regarding size to carry both parts rather than one part, a UUID is 128 
bits in binary. That's 32 bytes in hex, or 24 bytes in base 64. Two of 
them is double that. Perhaps add one for a separator. E.g.

   Session-ID: hVpd7YQgRW2nD22h7q60JQ==:srfBElmCRp2QB23b7Mpk0w==

(That is standard base 64 rep. The == at the end is artifact of that 
encoding when the number of bits isn't a multiple of 6. If its known 
that the length is always 32 bits, then the == could be dropped.)

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 28 Jun 2012 22:19:04 -0400

James,

> If we agree that once the whole Session-ID is compiled, meaning the GUID
> from UA1 and the GUID from UA2 are concatenated in some order, that header
> value remains on in all SIP messages between those 2 UAs until session
> termination or a transfer or join operation occurs.
> 

I'm OK with that so long as we indicate directionality.  In the rare event
that two ends are joined to different calls are roughly the same time, I
would want intermediaries and the remote system to be able to tell which of
the two values UUIDs belong to the remote device.  Thus, something like:

  Session-ID: S:x;R:y

(referring to the sender (S) of the message and the assumed recipient (R)).

If we do not do this, then Carol might receive this:
  
  Session-ID: XY

And Carol knows her UUID is L and has no idea which value (X or Y) belongs
to the remote device.  It's a rare case, but we can avoid it ever becoming
an issue by keeping the two UUIDs separated somehow.  This can be through
"S:" tags or the order of placement (sender || receiver).

Paul

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 29 Jun 2012 15:10:53 +0300

> (referring to the sender (S) of the message and the assumed recipient (R)).
I agree that if we choose to insert the entire Session-ID concatenated
it would be better also have a way to separate the components so to 
discriminate them

but I am not completely convinced that we need the entire Session-ID 
concatenated

Salvatore

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Jun 2012 09:53:33 -0400

> "S:" tags or the order of placement (sender || receiver).

Be careful here. You seem to be trying to pile on two different 
semantics. On one hand you are trying to associate each "half" of the id 
with the end that assigned it. On the other hand, for comparing two IDs 
you don't care what end is associated with what half - you want the IDs 
from two messages sent in opposite directions to compare equal.

For precedent, what you are describing is very comparable to the 
from-tag and to-tag.

What Paul J is suggesting (S:, R:) can work as long as comparison rules 
are properly defined. E.g. (as I already proposed) to compare IDs X and 
Y, compare min(Xs, Xr) to min(Ys, Yr) and max(Xs, Xr) to max(Ys, Yr).

I'm inclined to suggest the following format:

   Session-ID: from=x; to=y

to show the similarity to from and to tags.

	Thanks,
	Paul

---

From: James Polk <[email-masked]>
Date: Fri, 29 Jun 2012 13:22:38 -0500

At 08:53 AM 6/29/2012, Paul Kyzivat wrote:
>semantics. On one hand you are trying to associate each "half" of 
>the id with the end that assigned it. On the other hand, for 
>comparing two IDs you don't care what end is associated with what 
>half - you want the IDs from two messages sent in opposite 
>directions to compare equal.
>
>What Paul J is suggesting (S:, R:) can work as long as comparison 
>rules are properly defined. E.g. (as I already proposed) to compare 
>IDs X and Y, compare min(Xs, Xr) to min(Ys, Yr) and max(Xs, Xr) to max(Ys, Yr).
>

What I originally proposed was to order Alice's GUID first, then 
Bob's, but make it implicit in which all observers of the Session-ID 
header value could easily determine which was the initiator and which 
was the responder - but only if the GUIDs were always of a 
known/fixed length (i.e., always 24 or 32 bytes for each GUID). This 
is instead of the analysis of which GUID is a greater value vs. which 
is a lessor value and concatenate that way.

With that model, when Bob transfers Alice to Carol, Alice's GUID 
would remain part of the Session-ID while Bob's would be replaced by 
Carol's (once she responds).

Now, I know I haven't thought about all versions of joins to 
appreciate if there is a corner case of join that breaks this model. 
But, I'm not sure we need to include the 'S:' & 'R:' or 'from=' & 
'to=' unless we determine we need to be explicit. If that's the case, 
I'd like to see (i.e., a diagram of) an example of that corner case.

WRT the idea of whether or not to have the GUIDs present in the 
Session-ID header value, this is clean and not left to assumption as 
to what is the other GUID value that is not in that SIP message. It's 
not like we're attempting to hide one GUID from being seen on the 
wire, that's what TLS is for if that's a concern.

James

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 30 Jun 2012 11:54:04 -0400

On 6/29/12 2:22 PM, James Polk wrote:
>>>> GUID
>> semantics. On one hand you are trying to associate each "half" of the
>> id with the end that assigned it. On the other hand, for comparing two
>> IDs you don't care what end is associated with what half - you want
>> the IDs from two messages sent in opposite directions to compare equal.
>>
> What I originally proposed was to order Alice's GUID first, then Bob's,
> but make it implicit in which all observers of the Session-ID header
> value could easily determine which was the initiator and which was the
> responder - but only if the GUIDs were always of a known/fixed length
> (i.e., always 24 or 32 bytes for each GUID). This is instead of the
> analysis of which GUID is a greater value vs. which is a lessor value
> and concatenate that way.

I don't understand. Once a dialog is established, it needs to be the 
case that the sessionid is the same for messages sent by Alice and those 
sent by Bob. And I don't think you can count of figuring out which end 
initiated the dialog. (In some cases with B2BUAs, both ends may 
initiate, or sometimes the middle initiates toward both ends.)

	Thanks,
	Paul

> With that model, when Bob transfers Alice to Carol, Alice's GUID would
> remain part of the Session-ID while Bob's would be replaced by Carol's
> (once she responds).
>
> Now, I know I haven't thought about all versions of joins to appreciate
> if there is a corner case of join that breaks this model. But, I'm not
> sure we need to include the 'S:' & 'R:' or 'from=' & 'to=' unless we
> determine we need to be explicit. If that's the case, I'd like to see
> (i.e., a diagram of) an example of that corner case.
>
> Session-ID header value, this is clean and not left to assumption as to
> what is the other GUID value that is not in that SIP message. It's not
> like we're attempting to hide one GUID from being seen on the wire,
> that's what TLS is for if that's a concern.
>
> James
>
>
>> Thanks,
>> Paul