Subject: [Insipid] Backward compability between draft-jones and draft-kaplan

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Aug 2012 22:27:00 +0200

Hi,

In Vancouver, I expressed a wish to make the INSIPID mechanism backward compatible with the draft-kaplan-session-id one, the reason being that it has been around for a relatively long time, and has been implemented and deployed.

I compared the suggested draft-jones solution with the draft-kaplan solution, and I think there are ways to achieve backward compability.

--------------

FIRST, looking purely at the ABNF syntax:

The jones ABNF is:

Session-ID-UUID = "Session-ID-UUID" HCOLON UUID

The kaplan ABNF is:

Session-ID           =  "Session-ID" HCOLON sess-id

                           *( SEMI generic-param )

sess-id              =  32(DIGIT / %x61-7A)  ; 32 chars of [0-9a-z]

Now, assuming 32 chars is enough to carry ONE UUID, jones applications could put the SECOND UUID in a header field parameter (generic-param), rather than combining it with the received UUID.

Of course, the first UUDI (carried in sess-id) can only contains characters 0-9 and a-z.

A UUID can contain characters 0-9 and a-f and A-F.

So, a jones entity would have to be prepared to receive g-z.

And, as kaplan entity is not prepared to receive capital A-F, a jones entity would have to only use small letters. But, that should not be a problem, afaik, as they have the same meaning as far as UUID is concerned.

--------------

SECOND, looking at it would work functionwise:

There are two main alternatives:

1. Second UUID is added even when one entity is kaplan compliant

2. Second UUID is not added when one entity is kaplan compliant

Alternative 1:

When a kaplan entity inserts the first UUID (I use that as a general term, eventhough a kaplan entity does not use UUIDs), one must assume that it is prepared to receive a response from a jones entity which has added the second UUID into the header field parameter.

When a jones entity inserts the first UUID, one must assume that it is prepared to receive a response from a kaplan entity where the second UUID has *not* been added.

Alternative 2:

When a kaplan entity inserts the first UUID, the jones entity detects (using some identify-a-kaplan-entity mechanism) that it comes from a kaplan entity, so it does not insert a seoncd UUID in the first place.

As in alternative 1, when a jones entity inserts the first UUID, it has to be prepared to receive a response where the second UUID has not been added (the identify-a-kaplan-entity mechanism might also inform the jones entity that the response comes from a kaplan entity.

--------------

Now, there will of course be cases, where two UUIDs are required, that won't work. But, kaplan entities would be able to use the session-id for whatever they've used it so far.

Regards,

Christer

---

From: <[email-masked]>
Date: Wed, 15 Aug 2012 13:50:22 +0200

Hi,
I support this approach as we have already an implementation based on draft-kaplan.

Thank you and best Regards
Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Christer Holmberg
Gesendet: Dienstag, 14. August 2012 22:27
An: [email-masked]
Betreff: [Insipid] Backward compability between draft-jones and draft-kaplan

Hi,

--------------

The jones ABNF is:

The kaplan ABNF is:

                           *( SEMI generic-param )

--------------

Alternative 1:

Alternative 2:

--------------

Regards,

Christer

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

---

From: <[email-masked]>
Date: Wed, 15 Aug 2012 14:17:17 +0200

Hi Christer,
You state
...
...

I found in RFC4122 (UUID) the following wording.

     Each field is treated as an integer and has its value printed as a
      zero-filled hexadecimal digit string with the most significant
      digit first.  The hexadecimal values "a" through "f" are output as
      lower case characters and are case insensitive on input.
...
    hexDigit =
            "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" /
            "a" / "b" / "c" / "d" / "e" / "f" /
            "A" / "B" / "C" / "D" / "E" / "F"
...

Is this the "procedure" how a recived UUID has to be interpreted or
does that mean that the UUID is sent only in lower case even that the hexDigit is also defined as upper case in the ABNF?

Than you

Roland

---

From: Shida Schubert <[email-masked]>
Date: Wed, 15 Aug 2012 10:01:02 -0700

As we have the kaplan spec implemented and deployed, 
I support Christer's proposal.

 Regards
  Shida

---

From: Andrew Allen <[email-masked]>
Date: Thu, 16 Aug 2012 22:00:06 +0000

If its at all possible to make the INSIPID solution backwards compatible with the Kaplan draft I would strongly urge we do this. 

With several pre-standards deployments already based on Kaplan draft  there is a real danger that INSIPID solution will become an unimplemented standard if it is not backward compatible with what has already been deployed.

While we don't guarantee to maintain compatibility with earlier versions of drafts it is in our interest to attempt to be compatible with what has been deployed commercially. 

Running code is of course something we desire and believe in!

Andrew 

----- Original Message -----
From: Shida Schubert [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 12:01 PM
To: Christer Holmberg <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Insipid] Backward compability between draft-jones and	draft-kaplan

 Regards
  Shida

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: "Leis, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 17 Aug 2012 11:10:49 +0200

I support the proposal to make the INSIPID mechanism backward compatible
with the mechanism in draft-kaplan-session-id.

Regards
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Andrew Allen
Sent: Friday, August 17, 2012 12:00 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Insipid] Backward compability between draft-jonesand
draft-kaplan

If its at all possible to make the INSIPID solution backwards compatible
with the Kaplan draft I would strongly urge we do this. 

With several pre-standards deployments already based on Kaplan draft
there is a real danger that INSIPID solution will become an
unimplemented standard if it is not backward compatible with what has
already been deployed.

While we don't guarantee to maintain compatibility with earlier versions
of drafts it is in our interest to attempt to be compatible with what
has been deployed commercially. 

Andrew 

----- Original Message -----
From: Shida Schubert [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 12:01 PM
To: Christer Holmberg <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Insipid] Backward compability between draft-jones and
draft-kaplan

 Regards
  Shida

On Aug 14, 2012, at 1:27 PM, Christer Holmberg wrote:

> Hi,
> 
> In Vancouver, I expressed a wish to make the INSIPID mechanism
backward compatible with the draft-kaplan-session-id one, the reason
being that it has been around for a relatively long time, and has been
implemented and deployed.
> 
> I compared the suggested draft-jones solution with the draft-kaplan
solution, and I think there are ways to achieve backward compability.
> Now, assuming 32 chars is enough to carry ONE UUID, jones applications
could put the SECOND UUID in a header field parameter (generic-param),
rather than combining it with the received UUID.
> And, as kaplan entity is not prepared to receive capital A-F, a jones
entity would have to only use small letters. But, that should not be a
problem, afaik, as they have the same meaning as far as UUID is
concerned.
> When a kaplan entity inserts the first UUID (I use that as a general
term, eventhough a kaplan entity does not use UUIDs), one must assume
that it is prepared to receive a response from a jones entity which has
added the second UUID into the header field parameter.
> 
> 
> 
> When a jones entity inserts the first UUID, one must assume that it is
prepared to receive a response from a kaplan entity where the second
UUID has *not* been added.
> 
> 
> 
> 
> 
> Alternative 2:
> 
> 
> 
> When a kaplan entity inserts the first UUID, the jones entity detects
(using some identify-a-kaplan-entity mechanism) that it comes from a
kaplan entity, so it does not insert a seoncd UUID in the first place.
> 
> 
> 
> As in alternative 1, when a jones entity inserts the first UUID, it
has to be prepared to receive a response where the second UUID has not
been added (the identify-a-kaplan-entity mechanism might also inform the
jones entity that the response comes from a kaplan entity.
> 
> 
> 
> 
> 
> --------------
> 
> 
> 
> Now, there will of course be cases, where two UUIDs are required, that
won't work. But, kaplan entities would be able to use the session-id for
whatever they've used it so far.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
_______________________________________________
insipid mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/insipid

---

From: "VAN GEEL Jan (CIS/SCC)" <[email-masked]>
Date: Fri, 17 Aug 2012 09:23:51 +0000

+1

Jan Van Geel
IT and Network Specialist
Belgacom SDE/SDV/PSE/FVC
Tel: +32 2 202 1035
Tel: +32 2 207 9032
Email : [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leis, Peter (NSN - DE/Munich)
Sent: Friday 17 August 2012 11:11
To: [email-masked]; [email-masked]
Subject: Re: [Insipid] Backward compability between draft-jonesand draft-kaplan

I support the proposal to make the INSIPID mechanism backward compatible with the mechanism in draft-kaplan-session-id.

Regards
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Andrew Allen
Sent: Friday, August 17, 2012 12:00 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Insipid] Backward compability between draft-jonesand draft-kaplan

Andrew

----- Original Message -----
From: Shida Schubert [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 12:01 PM
To: Christer Holmberg <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Insipid] Backward compability between draft-jones and draft-kaplan

 As we have the kaplan spec implemented and deployed, I support Christer's proposal.

 Regards
  Shida

> In Vancouver, I expressed a wish to make the INSIPID mechanism
backward compatible with the draft-kaplan-session-id one, the reason being that it has been around for a relatively long time, and has been implemented and deployed.
could put the SECOND UUID in a header field parameter (generic-param), rather than combining it with the received UUID.
> And, as kaplan entity is not prepared to receive capital A-F, a jones
entity would have to only use small letters. But, that should not be a problem, afaik, as they have the same meaning as far as UUID is concerned.
term, eventhough a kaplan entity does not use UUIDs), one must assume that it is prepared to receive a response from a jones entity which has added the second UUID into the header field parameter.
> When a jones entity inserts the first UUID, one must assume that it is
prepared to receive a response from a kaplan entity where the second UUID has *not* been added.
> When a kaplan entity inserts the first UUID, the jones entity detects
(using some identify-a-kaplan-entity mechanism) that it comes from a kaplan entity, so it does not insert a seoncd UUID in the first place.
> As in alternative 1, when a jones entity inserts the first UUID, it
has to be prepared to receive a response where the second UUID has not been added (the identify-a-kaplan-entity mechanism might also inform the jones entity that the response comes from a kaplan entity.
won't work. But, kaplan entities would be able to use the session-id for whatever they've used it so far.

________________________________

***** Disclaimer *****
http://www.belgacom.be/maildisclaimer

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 17 Aug 2012 10:58:41 +0000

AT&T supports the proposal to make the INSIPID mechanism backward compatible with the mechanism in draft-kaplan-session-id.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: Thursday, August 16, 2012 6:00 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Insipid] Backward compability between draft-jones and draft-kaplan

Andrew 

----- Original Message -----
From: Shida Schubert [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 12:01 PM
To: Christer Holmberg <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Insipid] Backward compability between draft-jones and	draft-kaplan

 Regards
  Shida

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Fri, 17 Aug 2012 14:09:40 +0000

I share the view in the comments below, the INSIPID solution needs to be backwards compatible with the Kaplan draft.

Regards,
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: 16 August 2012 23:00
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Insipid] Backward compability between draft-jones and draft-kaplan

Andrew 

----- Original Message -----
From: Shida Schubert [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 12:01 PM
To: Christer Holmberg <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Insipid] Backward compability between draft-jones and	draft-kaplan

 Regards
  Shida

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 17 Aug 2012 16:43:24 +0000

In case it wasn't obvious: +1
FYI, the new draft should be coming out next week or week after.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 17 Aug 2012 17:47:35 +0000

When we talked about this in Vancouver I was thinking there wouldn't be any problem going to/from UUID syntax, because going to/from UUIDs in H.323 was talked about a long, long time ago for session-id.  But I forgot about the bug in the draft-kaplan ABNF...

Since version 01 of draft-kaplan-sip-session-id in 2008, which later became draft-kaplan-dispatch-session-id, the rules for generating the session-id always made it lower-case *hex* characters.  I.e., the g-z range wasn't actually possible.  The ABNF for it didn't get fixed until draft-kaplan-dispatch-session-id-01 in April 2010, but that also dropped it to 16 characters of hex because the algorithm changed, and then 3 months later reverted back to 32 characters and the correct ABNF.

So that begs the question of *which* version of draft-kaplan we want to be backwards compatible with.  Since draft-kaplan-dispatch-session-id-01 only existed for 3 months, I think we can ignore that one.  And since everything else only used hex characters, except the initial 00-draft which itself only existed for 4 months, I think we can ignore that one too.

Therefore, as far as I can tell we shouldn't have a problem converting draft-kaplan session-ids to/from UUIDs for H.323/whatever.

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 17 Aug 2012 14:49:39 -0400

Christer,

The reason for introducing the use of two UUIDs was to address a few
signaling scenarios that I do not think Hadriel's draft addresses. I might
be wrong, so let me present some assertions and ask questions.

If enterprise user A calls enterprise user B, you want to have an identifier
end-to-end for that call.  What if the PBX at B redirects that call to
enterprise user C.  Would you expect to see the same Session-ID or a
different one?  If you want to use the same ID.  I would venture to guess
you have two IDs today in practice.

Let suppose the call to B results in both B and C ringing and 180 messages
coming back from both.  Would you want the same Session-ID on both?  The
draft we submitted would allow for each device to uniquely represent itself,
so we would have two Session-IDs, in effect, with one disappearing when the
call is answered.

Assume Alice calls Bob.  There is a Session-ID between Alice and Bob.  Now,
assume Bob presses a button on his phone that results in transferring the
call to Carol.  Do we retain the same Session-ID or does it change?

Let's assume Alice calls Bob, so we have a Session-ID between Alice and Bob.
Suppose Carol calls Bob.  There is a different Session-ID between Carol and
Bob.  Now, suppose Bob presses a button on his phone such that Alice and
Carol are now talking directly to each other and Bob drops out of the call.
What is the Session-ID?  Are there two Session IDs or one?

Suppose Alice calls Bob.  At or about the same time, Alice transfers the
Alice/Bob call to Sue and Bob transfers the Alice/Bob call to Sue.  What is
the Session-ID between Carol/Sue?

Suppose Alice calls Bob (Session ID A/B).  Suppose Dave calls Alice (Session
ID D/A) and she puts Bob on hold. While waiting, Bob place a separate call
to Sue (Session ID B/S).  Later and at or about the same time, Alice
transfers the Alice/Bob call to Dave and Bob transfers the Alice/Bob call to
Sue.  What is the Session-ID?

We went down this path with H.323 trying to identify a call end-to-end.
Because of the wide variety of ways in which calls can be manipulated, a
single identifier assigned on one end would not work, since there would
always be a conflict over IDs.  I see the same challenge with SIP in some of
these flows.

That's why we suggested concatenating two UUIDs and expecting UUIDs to
change at any time.  Such changes indicate a change in the remote terminal
device.

I have no objection to trying to use similar syntax as what Hadriel had in
his draft, but I do think we need to allow use of two UUIDs to identify the
session end-to-end to address some of the example scenarios above.

So, perhaps we have:

Session-ID: A;p=B
 Where
   A = Alice's UUID
   p = some parameter name
   B = Bob's UUID

Alice would include only A in the INVITE.  Bob could put all of the above in
the reply.

Now, if Bob sends an INVITE to Alice, how would it construct the above
header?  Exactly the same way?

Let's consider the case where Carol calls Bob (C||B2):
  Session-ID: C;p=B2

Bob pushes a button on his phone to transfer the call with Carol to Alice.
The PBX would send an INVITE to Alice.  What would be in the Session-ID?
What we were proposing in the Jones draft is (and given recent discussion of
putting the sender's UUID first):
  Session-ID: C:A

This would tell Alice that the remote device's UUID is now 'C'.  Alice would
know her own UUID, but could reply differently if required (if we had that
odd race condition I mentioned before and above):
  Session-ID: A:C

Trying to fit this with the Kaplan draft, what would the PBX send to Alice?
It might also send an INVITE to Carol.  What would it send?

In one direction or the other, the original Session-ID value must change, I
believe.  I'm not sure if that would be compatible with the current Kaplan
draft.  The challenge is with forcing the requirement that the value
following "Session-ID" can never change, because it will.  Calls get routed
and re-routed from one device to another (IVR, person 1, person 2, music on
hold server, person 3, etc.)

Paul

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Christer Holmberg
> Sent: Tuesday, August 14, 2012 4:27 PM
> To: [email-masked]
> Subject: [Insipid] Backward compability between draft-jones and draft-
> kaplan
> 
> Hi,
> 
> In Vancouver, I expressed a wish to make the INSIPID mechanism backward
> compatible with the draft-kaplan-session-id one, the reason being that it
> has been around for a relatively long time, and has been implemented and
> deployed.
> 
> problem, afaik, as they have the same meaning as far as UUID is concerned.
> 
> 
> 
> --------------
> 
> 
> 
> When a kaplan entity inserts the first UUID (I use that as a general term,
> eventhough a kaplan entity does not use UUIDs), one must assume that it is
> prepared to receive a response from a jones entity which has added the
> second UUID into the header field parameter.
> 
> 
> 
> As in alternative 1, when a jones entity inserts the first UUID, it has to
> be prepared to receive a response where the second UUID has not been added
> (the identify-a-kaplan-entity mechanism might also inform the jones entity
> that the response comes from a kaplan entity.
> 
> 
> 
> 
> 
> --------------
> 
> 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 17 Aug 2012 22:14:19 +0000

I don't know what Christer's proposal would be exactly, but what I proposed in Vancouver would be to make the "second" id a header parameter.
So yes it's like this:
Session-ID: f81d4fae7dec11d0a76500a0c91e6bf6;p=2128675309beef15f00d4dead2fee155

Alice generates the header-value, Bob inserts the param.
Both Alice and Bob use the same header sess-id value and param-value for all in-dialog requests, regardless who's sending what. (ie, upstream requests from Bob still have the same sess-id;param, and there are no re-INVITEs/UPDATEs required to change it because it can't change in that SIP dialog)

Note that the header sess-id value (the "f81d4fae7dec11d0a76500a0c91e6bf6") and the param value (the "2128675309beef15f00d4dead2fee155") are separate keys/values, so if you're a monitoring device you'd have a lookup table with each separate key. 

> Sue.  What is the Session-ID?

I'm going to use U/V/W/X/Y/Z instead of A/B/etc. because the sesssion-id values are just random numbers - they don't identify a user/identity and we tend to think that when we use 'A' for Alice's session-id, and 'B' for Bob's.

The setup is this regardless:
Alice <--> Bob = U;V
Dave <--> Alice = W;X
Bob <--> Sue = Y;Z

As for what happens in the REFER transfer, we (INSIPID WG) get to decide...

OPTION-1:
I believe that following draft-kaplan model strictly, we'd have this:
Alice sends REFER to Bob referring him to Dave, by putting 'W;X' in her REFER's Refer-To.  Bob's new INVITE with Replaces to Dave has a Session-ID of 'W;X'.  That continues to be the Session-ID of the (now) Bob <--> Dave session, so:
Bob <--> Dave = W;X

Later, Bob sends a REFER to Dave referring him to Sue, by putting 'Y;Z' in his REFER's Refer-To.  Dave's new INVITE with Replaces to Sue has a Session-ID of 'Y;Z'.  That continues to be the Session-ID of the (now) Dave <--> Sue session, so:
Dave <--> Sue = Y;Z

The above would be following the rule in draft-kaplan of copying the whole Session-ID being referred-to in the Refer-To.

--
OPTION-2:
However an argument could be made that we could do this instead, and still comply with draft-kaplan model:
Alice sends REFER to Bob referring him to Dave, by putting 'W;V' in her REFER's Refer-To.  Bob's new INVITE with Replaces to Dave has a Session-ID of 'W;V'.  That continues to be the Session-ID of the (now) Bob <--> Dave session, so:
Bob <--> Dave = W;V

Later, Bob sends a REFER to Dave referring him to Sue, by putting 'Y;W' in his REFER's Refer-To.  Dave's new INVITE with Replaces to Sue has a Session-ID of 'Y;W'.  That continues to be the Session-ID of the (now) Dave <--> Sue session, so:
Dave <--> Sue = Y;W

The above would be a rule of copying the Session-ID 'sess-id' field being referred-to, but with a param value of the REFER's target created to the Referer. (ie., "V" in the Alice<-->Bob call, and "W" in the Bob<-->Dave call)  If the REFER's target created both values, the param would be set to the sess-id field of that dialog.

--
OPTION-3:
OR, the rule could just be copying the Session-ID 'sess-id' field being referred-to, but with a param value of the REFER's target sess-id field.
Which means...
Alice sends REFER to Bob referring him to Dave, by putting 'W;U' in her REFER's Refer-To.  Bob's new INVITE with Replaces to Dave has a Session-ID of 'W;U'.  That continues to be the Session-ID of the (now) Bob <--> Dave session, so:
Bob <--> Dave = W;U

Later, Bob sends a REFER to Dave referring him to Sue, by putting 'Y;W' in his REFER's Refer-To.  Dave's new INVITE with Replaces to Sue has a Session-ID of 'Y;W'.  That continues to be the Session-ID of the (now) Dave <--> Sue session, so:
Dave <--> Sue = Y;W

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 18 Aug 2012 01:04:54 +0200

Hi,

>I don't know what Christer's proposal would be exactly, but what I proposed in Vancouver would be to >make the "second" id a header parameter.
>So yes it's like this:
>Both Alice and Bob use the same header sess-id value and param-value for all in-dialog requests, regardless >who's sending what. (ie, upstream requests from Bob still have the same sess-id;param, and there are no re->INVITEs/UPDATEs required to change it because it can't change in that SIP dialog)
>
>Note that the header sess-id value (the "f81d4fae7dec11d0a76500a0c91e6bf6") and the param value (the "
>2128675309beef15f00d4dead2fee155") are separate keys/values, so if you're a monitoring device you'd >have a lookup table with each separate key.

That's a correct description of my proposal :)

(I will look at the use-cases later.)

Regards,

Christer

OPTION-1:

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 19 Aug 2012 21:57:12 -0400

Now let's assume no refer message is sent. For billing reasons, one would want to handle that transfer locally. So, Alice's call agent will send an invite to Dave to get him and Bob talking. I guess this will work the same. I'd expect the invite to contain Dave and Bob's uuid values, but how would we construct those? An invite would also get sent to Bob. What would that look like?

Since the invite to Bob is actually being redirected to Sue in this scenario, I guess Bob's call agent needs to do the proper substitution of a uuid... replacing Bob's with Sue's.

What do these headers look like? Whose ID is a parameter?

Paul

-------- Original Message --------
From: Hadriel Kaplan <[email-masked]>
Sent: Fri Aug 17 18:14:19 EDT 2012
To: "Paul E. Jones" <[email-masked]>
Cc: Christer Holmberg <[email-masked]>, "<[email-masked]>" <[email-masked]>
Subject: Re: [Insipid] Backward compability between draft-jones and	draft-kaplan

OPTION-1:

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 20 Aug 2012 03:40:25 +0000

I think the diagram you're talking about is this:

 +-------+                  +-------+
 | Alice |\                /|  Bob  |
 +-------+ \              / +-------+
          +-----+    +-----+
          |PBX-1|----|PBX-2|
          +-----+    +-----+
 +-------+ /              \ +-------+
 | Dave  |/                \|  Sue  |
 +-------+                  +-------+

The rest inline...

> Now let's assume no refer message is sent. For billing reasons, one would want to handle that transfer locally. So, Alice's call agent will send an invite to Dave to get him and Bob talking. I gues…

Alice makes call to Bob, Session-ID=U;V
Dave calls Alice, Session-ID=W;X
Bob calls Sue, Session-ID=Y;Z.
Later, Alice presses some keys to make PBX-1 transfer Bob to Dave, instead of sending Bob a REFER.
Later, Bob presses some keys to make PBX-2 transfer Alice to Sue, instead of sending Alice a REFER.

Currently draft-kaplan doesn't specify what to do for this, I think, because it's not a REFER-driven transfer.  So it's really up for debate.  By that I mean there's no backwards-compatibility problem/requirement/impact.

Personally, I think it should behave as if it were a REFER situation, i.e. do what a REFER would have made happen. For example PBX-1 could generate an INVITE to Dave with a Session-ID=W;V or W;U, possibly with a Replaces header having a session-id param of 'W;X', depending on how we wanted a real REFER case to work.  If a re-INVITE is sent to Bob/PBX-2 from the PBX-1, it's still U;V on that leg because it doesn't change mid-dialog.  In either case, a monitoring device would be able to correlate them since one of the keys match. 

Likewise, in the second part when Bob transfers Alice (who's now Dave really) to Sue, PBX-2 would send an INVITE to Sue with Session-ID=Y;U or Y;V (again depending on what rule we wanted to impose for REFERs), possibly with a Replaces header having a session-id param of 'Y;Z'.

> Since the invite to Bob is actually being redirected to Sue in this scenario, I guess Bob's call agent needs to do the proper substitution of a uuid... replacing Bob's with Sue's.

Yes, if a PBX performs a transfer by terminating/processing REFER as a UA or based on keys or app-logic, generating dialog-creating INVITEs out of thin air so-to-speak, life gets messy.  It's going to no matter what we do at that point - for example Dave could have just barged in to the Alice-Bob call by calling the PBX as a new call and pressed some keys for barge-in, or the PBX could handle call transfers without ever sending new INVITEs or re-INVITEs, by just switching the media (assuming it was already handling all media).

And we can't mandate the PBXes send re-INVITEs or UPDATEs to change the Session-IDs - we'd just be ignored because many PBXs have a hard time doing it, and many customers don't want them to do it (or have SBCs answer the re-INVITEs to prevent them from going further).  I think the best we can do is have simple rules for the devices generating them, and make sure this Session-ID thing is only used for monitoring/troubleshooting type uses - things that won't cause calls to fail if the INSIPID rules/algorithms don't handle it right.

> What do these headers look like? Whose ID is a parameter?

Anything beyond the normal single session/dialog case and basic REFER scenario is not covered by the current draft-kaplan, so it's up for debate really what it should do.  There's no backwards-compatibility problem/requirement/impact for such cases.

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 20 Aug 2012 21:29:01 -0400

Hadriel,

What I hoped for out of our original proposal was to allow for this kind of
flexibility.

So, Alice transfers to Dave, the INVITE to Dave would look like:
  Session-ID: V;p=W

(I think... using the A/B/D/S naming, it would be Session-ID: B;p=D.  I just
want to make sure I don't suggest the wrong values in my example.)

Now, PBX-1 needs to also send an INVITE to Bob.  This would then look the
same:
  Session-ID: V;p=W

I think this is workable.  If PBX-2 is performing a mid-call endpoint
exchange, it just has to take responsibility for these ensuring proper
values are conveyed.

Now, let's suppose that Bob had called Alice.  In that case, the original
session-ID from Bob to Alice would have been:
  Session-ID: B;p=A

(I know you do not want folks to assume B carries some meaning, but I find
it easier to use these letters.)

Now, Alice transfers the call to Dave. In this case, the Session-ID would be
what?
  Session-ID: B;p=D

This would be replacing "Session-ID: A;p=D" with "Session-ID: B;p=D"

It's this mid-call change of the Session-ID that concerns me w.r.t. backward
compatibility.  During the middle of the call the Session-ID per your
original draft (using just the first 32 bits) changes from A to B.

I mentioned before that we have to have a means of allowing the Session-ID
to change mid-call since one endpoint may be replaced with another at any
time and there may or may not be associated signaling.  Will that work for
you, or would it cause a lot of problems?

Paul

> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: Sunday, August 19, 2012 11:40 PM
> To: Paul E. Jones
> Cc: Christer Holmberg; <[email-masked]>
> > Now let's assume no refer message is sent. For billing reasons, one
> would want to handle that transfer locally. So, Alice's call agent will
> send an invite to Dave to get him and Bob talking. I guess this will work
> the same. I'd expect the invite to contain Dave and Bob's uuid values, but
> how would we construct those? An invite would also get sent to Bob. What
> would that look like?
> 
> Currently draft-kaplan doesn't specify what to do for this, I think,
> because it's not a REFER-driven transfer.  So it's really up for debate.
> By that I mean there's no backwards-compatibility
> problem/requirement/impact.
> 
> Personally, I think it should behave as if it were a REFER situation, i.e.
> do what a REFER would have made happen. For example PBX-1 could generate
> an INVITE to Dave with a Session-ID=W;V or W;U, possibly with a Replaces
> header having a session-id param of 'W;X', depending on how we wanted a
> real REFER case to work.  If a re-INVITE is sent to Bob/PBX-2 from the
> PBX-1, it's still U;V on that leg because it doesn't change mid-dialog.
> In either case, a monitoring device would be able to correlate them since
> one of the keys match.
> 
> Likewise, in the second part when Bob transfers Alice (who's now Dave
> really) to Sue, PBX-2 would send an INVITE to Sue with Session-ID=Y;U or
> Y;V (again depending on what rule we wanted to impose for REFERs),
> possibly with a Replaces header having a session-id param of 'Y;Z'.
> 
> 
> > Since the invite to Bob is actually being redirected to Sue in this
> scenario, I guess Bob's call agent needs to do the proper substitution of
> a uuid... replacing Bob's with Sue's.
> 
> Yes, if a PBX performs a transfer by terminating/processing REFER as a UA
> or based on keys or app-logic, generating dialog-creating INVITEs out of
> thin air so-to-speak, life gets messy.  It's going to no matter what we do
> at that point - for example Dave could have just barged in to the Alice-
> Bob call by calling the PBX as a new call and pressed some keys for barge-
> in, or the PBX could handle call transfers without ever sending new
> INVITEs or re-INVITEs, by just switching the media (assuming it was
> already handling all media).
> 
> And we can't mandate the PBXes send re-INVITEs or UPDATEs to change the
> Session-IDs - we'd just be ignored because many PBXs have a hard time
> doing it, and many customers don't want them to do it (or have SBCs answer
> the re-INVITEs to prevent them from going further).  I think the best we
> can do is have simple rules for the devices generating them, and make sure
> this Session-ID thing is only used for monitoring/troubleshooting type
> uses - things that won't cause calls to fail if the INSIPID
> rules/algorithms don't handle it right.
> 
> 
> Anything beyond the normal single session/dialog case and basic REFER
> scenario is not covered by the current draft-kaplan, so it's up for debate
> really what it should do.  There's no backwards-compatibility
> problem/requirement/impact for such cases.
> 
> -hadriel

---

From: Atle Monrad <[email-masked]>
Date: Tue, 28 Aug 2012 09:37:47 +0200

All

Considerations on backwards compatibility with the draft-kaplan-session-id would be useful. 

As Christer indiates below, there are implementations and deployments around and it would be good to consider these and specify a backwards compatible solution if possible.

The session-id is a 3GPP Rel-9 dependency.

Thanks
/atle

Atle Monrad
3GPP CT Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management 
Ericsson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 14. elokuuta 2012 23:27
To: [email-masked]
Subject: [Insipid] Backward compability between draft-jones and draft-kaplan

Hi,

--------------

The jones ABNF is:

The kaplan ABNF is:

                           *( SEMI generic-param )

--------------

Alternative 1:

Alternative 2:

--------------

Regards,

Christer

---

From: James Polk <[email-masked]>
Date: Wed, 29 Aug 2012 15:11:14 -0500

At 05:00 PM 8/16/2012, Andrew Allen wrote:

>If its at all possible to make the INSIPID solution backwards 
>compatible with the Kaplan draft I would strongly urge we do this.
>
>With several pre-standards deployments already based on Kaplan 
>draft  there is a real danger that INSIPID solution will become an 
>unimplemented standard if it is not backward compatible with what 
>has already been deployed.

err, "...will become an unimplemented standard..."  really?

Is everyone who will ever implement the Session-ID RFC implementing 
the individual draft version now?  I highly think not.

Therefore I don't believe this is justification or a valid threat to 
this WG to tune our standard towards what previously hasn't yet been 
accepted in the years it's been available by any WG in the IETF.

>While we don't guarantee to maintain compatibility with earlier 
>versions of drafts it is in our interest to attempt to be compatible 
>with what has been deployed commercially.
>

yes, if that code meets all the reasonable requirements. Running code 
that only meets some of the requirements is only a partial 
implementation, by definition.

James

> backward compatible with the draft-kaplan-session-id one, the 
> reason being that it has been around for a relatively long time, 
> and has been implemented and deployed.
> >
> > I compared the suggested draft-jones solution with the 
> draft-kaplan solution, and I think there are ways to achieve 
> backward compability.
> >
> >
> > --------------
> >
> >
> > Now, assuming 32 chars is enough to carry ONE UUID, jones 
> applications could put the SECOND UUID in a header field parameter 
> (generic-param), rather than combining it with the received UUID.
> >
> >
> >
> > And, as kaplan entity is not prepared to receive capital A-F, a 
> jones entity would have to only use small letters. But, that should 
> not be a problem, afaik, as they have the same meaning as far as 
> UUID is concerned.
> >
> >
> >
> > --------------
> >
> >
> >
> > When a kaplan entity inserts the first UUID (I use that as a 
> general term, eventhough a kaplan entity does not use UUIDs), one 
> must assume that it is prepared to receive a response from a jones 
> entity which has added the second UUID into the header field parameter.
> >
> >
> >
> > When a jones entity inserts the first UUID, one must assume that 
> it is prepared to receive a response from a kaplan entity where the 
> second UUID has *not* been added.
> >
> >
> >
> >
> >
> > Alternative 2:
> >
> >
> >
> > When a kaplan entity inserts the first UUID, the jones entity 
> detects (using some identify-a-kaplan-entity mechanism) that it 
> comes from a kaplan entity, so it does not insert a seoncd UUID in 
> the first place.
> >
> >
> >
> > As in alternative 1, when a jones entity inserts the first UUID, 
> it has to be prepared to receive a response where the second UUID 
> has not been added (the identify-a-kaplan-entity mechanism might 
> also inform the jones entity that the response comes from a kaplan entity.
> >
> >
> >
> >
> >
> > --------------
> >
> >
> >
> > Now, there will of course be cases, where two UUIDs are required, 
> that won't work. But, kaplan entities would be able to use the 
> session-id for whatever they've used it so far.
> >
> >
> >
> >
> >
> > Regards,
> >
> >
> >
> > Christer
> >
> >
> >
> >
> >
> >
> >
> >
>This transmission (including any attachments) may contain 
>confidential information, privileged material (including material 
>protected by the solicitor-client or other applicable privileges), 
>or constitute non-public information. Any use of this information by 
>anyone other than the intended recipient is prohibited. If you have 
>received this transmission in error, please immediately reply to the 
>sender and delete this information from your system. Use, 
>dissemination, distribution, or reproduction of this transmission by 
>unintended recipients is not authorized and may be unlawful.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Aug 2012 22:27:18 +0200

Hi,

> accepted in the years it's been available by any WG in the IETF.

Assuming that people will deploy the INSIPID solution is in my opinion a good reason why we should aim at making it backward compatible.

Me and Hadriel have presented some ideas on how it could be done. I think we can get pretty far simply by alligning the syntax.

>implementation, by definition.

I believe the draft implementations meet the requirements that were used to justify the implementation of the draft.

I am not suggesting that we should not be allowed to specify additional requirements for the INSIPID solution. Draft implementations will still only support the requirements they support today, but they will be able to communicate with INSIPID implementations.

Regards,

Christer

---

From: Atle Monrad <[email-masked]>
Date: Wed, 29 Aug 2012 22:39:50 +0200

James

I understand Andrews comments as a reminder to consider backwards compatibility due to deployed implementations . Obviously people implement drafts on their own risk, but lets not throw the coding updside down just for fun.

My understanding is that Christer and Hadriel have some ideas on how to do the coding.  I hope this can be further considered.

/atle

Atle Monrad
3GPP CT Chairman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of James Polk
Sent: 29. august 2012 22:11
To: Andrew Allen; [email-masked]; Christer Holmberg
Cc: [email-masked]
Subject: Re: [Insipid] Backward compability between draft-jones and draft-kaplan

Is everyone who will ever implement the Session-ID RFC implementing the individual draft version now?  I highly think not.

Therefore I don't believe this is justification or a valid threat to this WG to tune our standard towards what previously hasn't yet been accepted in the years it's been available by any WG in the IETF.

>Running code is of course something we desire and believe in!

yes, if that code meets all the reasonable requirements. Running code that only meets some of the requirements is only a partial implementation, by definition.

James

> draft-kaplan solution, and I think there are ways to achieve backward 
> compability.
> >
> >
> > --------------
> >
> >
> not be a problem, afaik, as they have the same meaning as far as UUID 
> is concerned.
> >
> >
> >
> > --------------
> >
> >
> >
> general term, eventhough a kaplan entity does not use UUIDs), one must 
> assume that it is prepared to receive a response from a jones entity 
> which has added the second UUID into the header field parameter.
> >
> >
> >
> detects (using some identify-a-kaplan-entity mechanism) that it comes 
> from a kaplan entity, so it does not insert a seoncd UUID in the first 
> place.
> >
> >
> >
> it has to be prepared to receive a response where the second UUID has 
> not been added (the identify-a-kaplan-entity mechanism might also 
> inform the jones entity that the response comes from a kaplan entity.
> >
> >
> >
> >
> >
> > --------------
> >
> >
> >
>non-public information. Any use of this information by anyone other 
>than the intended recipient is prohibited. If you have received this 
>transmission in error, please immediately reply to the sender and 
>delete this information from your system. Use, dissemination, 
>distribution, or reproduction of this transmission by unintended 
>recipients is not authorized and may be unlawful.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 29 Aug 2012 22:22:54 -0400

Christer,

> Assuming that people will deploy the INSIPID solution is in my opinion a
> good reason why we should aim at making it backward compatible.
> 
> Me and Hadriel have presented some ideas on how it could be done. I think
> we can get pretty far simply by alligning the syntax.

I agree that it looks like we can perhaps make this compatible through
syntax.

I'm still concerned about use of that syntax, though.  I asked before, but I
don't think I got an answer to (what I think is) an important question.

Let's assume Alice calls Bob.  We might have this:
  Session-ID: A ; p=B

Let's also assume Carol calls Bob.  We might have this:
  Session-ID: C ; p=B

Now, suppose Bob transfers the call with Alice to Carol.  Bob's PBX does the
magic and Bob drops out of the call.  Is it OK if the PBX sends Alice this?
  Session-ID: C; p=A

This is a real-world scenario where two call legs are joined by the PBX.

Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Aug 2012 09:30:57 +0200

Hi Paul,

>This is a real-world scenario where two call legs are joined by the PBX.

What do you mean by "sends Alice this"? Do you mean that the session-id, on the exisiting dialog between Alice and the PBX, is updated? 

Regards,

Christer

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 31 Aug 2012 21:00:10 -0400

Christer,

> >Now, suppose Bob transfers the call with Alice to Carol.  Bob's PBX
> >does the magic and Bob drops out of the call.  Is it OK if the PBX sends
> Alice this?
> >  Session-ID: C; p=A
> >
> What do you mean by "sends Alice this"? Do you mean that the session-id,
> on the exisiting dialog between Alice and the PBX, is updated?

Yes.  The Session-ID changes from:

Session-ID: A; p=B
To
Session-ID: C; p=A

In this way, we still have a single Session-ID end-to-end (namely, A || C or
C || A, depending on how we order the values).  However, the change in the
Session-ID from A || B to A || C is necessary to indicate that an end device
changed.

If we do not allow for this, we do not have an end-to-end ID any longer.  We
will have two IDs, one going into the PBX and one coming out.  And that
defeats the purpose.

So, the question is whether it's acceptable to make this change.  If so, I
think we can go with a solution like that.  The signaling will contain the
two UUID values, one representing each device, but the values might change
as described above.  This is the best backward-compatible approach I can
think of and still ensure that, going forward, we have an ID we can see as
end-to-end for the duration of the call where the same two devices are in
direct communication.

Paul