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

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Sep 2012 13:36:02 +0200

Hi Paul,

Just for me to understand the use-case a little better: is there a reason why the PBX can't keep the same value when contacting Carol?

Regards,

Christer

-----Original Message-----
From: Paul E. Jones [mailto:[email-masked]] 
Sent: 1. syyskuuta 2012 4:00
To: Christer Holmberg; 'James Polk'; 'Andrew Allen'; [email-masked]
Cc: [email-masked]
Subject: RE: [Insipid] Backward compability between draft-jones and draft-kaplan

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

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 7 Sep 2012 19:42:38 -0400

Christer,

There are two possible transfer examples.  In one case, the PBX could just
keep the same value, as it initiates the call to Carol.  However, consider
the two examples where it does not work:

1) Alice calls Bob.  Carol calls Bob.  Bob puts Alice on hold and talks to
Carol for a moment.  Bob then transfers the Bob/Carol call to Alice.  What
Session-ID it sent to Alice?  What Session-ID is sent to Carol?  Are these
two values?  (Note: in our proposal, Alice would always retain the UUID A
and Carol the UUID C.  After the transfer, the new "Sessio-ID" would be A ||
C (ordered).)
2) Alice calls Bob.  Bob puts Alice on hold and calls Carol.  Bob then
transfers Alice to Carol.  What Session-ID it sent to Alice?  What
Session-ID is sent to Carol?  Are these two values?  (Note: in our proposal,
Alice would always retain the UUID A and Carol the UUID C.  After the
transfer, the new "Sessio-ID" would be A || C (ordered).)

Note the same set of questions and we propose the same solution.

Paul

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Christer Holmberg
> Sent: Wednesday, September 05, 2012 7:36 AM
> To: Paul E. Jones; 'James Polk'; 'Andrew Allen'; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Insipid] Backward compability between draft-jones and draft-
> kaplan
> 
> Hi Paul,
> 
> Just for me to understand the use-case a little better: is there a reason
> why the PBX can't keep the same value when contacting Carol?
> 
> Regards,
> 
> Christer
> 
> 
> 
> 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
> 
> 
> 
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid