Subject: Re: [Insipid] INSIPID Req#2 - comments?

From: Brett Tate <[email-masked]>
Date: Thu, 3 May 2012 07:10:13 -0700

> REQ2: It must be possible to identify the end-to-end session
> when a session is transferred or if two different sessions
> are joined together via an intermediary (e.g., a PBX).

As worded, this requirement appears to cause the session identifier to be renegotiated and/or changed within a dialog.

For instance, a B2BUA is aware of two separate session identifiers: X1A and X2B.  X1 is connected to A through B2BUA; X2 is connected to B through B2BUA. The B2BUA is stimulated to connect A part of X1A to B part of X2B using existing dialogs (and releasing the other halves of the dialogs because X is dropping out).  Does the requirement cause the session identifier to be changed and/or renegotiated when the B2BUA connects the two already existing dialogs?

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 04 May 2012 05:06:34 -0400

Brett,

I did not fully follow your example, but when a call is joined with 
another, the session identifiers may (and likely will) change.  I'd 
argue they must, actually.

If Alice calls Bob, there would be some Session-ID X.
If Carol calls Bob, there would be some Session-ID Y.
Now, if Bob does something such that Alice and Carol are now 
communicating directly, the Session-ID for either or both Alice and 
Carol must change.  If the ID did not change, then we would not be able 
to identify the session end-to-end.  Without change, Alice would think 
the ID is X and Carol would think the ID is Y.  The two ends should have 
a common understanding of what the Session-ID is.

There are a few ways to accomplish this and we've proposed one in our 
draft.  What we proposed is that Alice would have a UUID that is unique 
to her and Bob would have one unique to him.  Likewise Carol would have 
a unique UUID.  These are unique per SIP session.  So, following our 
solution proposal:

If Alice calls Bob, there would be a Session-ID A||B1 (where || means 
order concatenation, but that's not so significant; we could keep these 
as separate components)
If Carol calls Bob, there would be a Session-ID C||B2 (note Bob would 
not use the same value since these are separate SIP sessions)
Now, if Bob does something such that Alice and Carol are now 
communicating directly, the Session-ID that both Alice and Carol would 
use is A||C.  (Here, the value A and C did not change, but the 
Session-ID did since the two components changed.  What is important is 
that both endpoints, Alice and Carol, have a common understanding of the 
Session-ID.)

Paul

On 5/3/2012 10:10 AM, Brett Tate wrote:
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: Brett Tate <[email-masked]>
Date: Fri, 4 May 2012 04:22:48 -0700

Thanks for the response.

> I did not fully follow your example, but when a call is 
> joined with another, the session identifiers may (and 
> likely will) change.  I'd argue they must, actually.

Your interpretation/restatement of the example is correct (Bob equates to my example's X).

My current understanding is that REQ2 is the requirement implying that the session identifier must change.  If so, I recommend REQ2 (or whichever requirement implies such a thing) be modified to explicitly indicate that meeting the requirement may cause the session identifier to change within an existing dialog.  I recommend being explicit because it appears to go beyond the current charter.  And if I recall correctly, it was one of the controversial topics during the chartering process.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 04 May 2012 09:14:21 -0400

While I'm not opposed to making an explicit statement that the ID must 
change, that's not the requirement.  I believe it must change, but 
others may feel differently.

The requirement is to be able to identify the session end-to-end, even 
when a call is transferred, joined, or otherwise subjected to mid-call 
interaction.  If there is a way to do that without changing the value of 
the IDs, then we could meet the requirement.  I can see where this would 
be possible with a typical transfer where the transferred-to party is 
not already in a call.  The call join is the more challenging case.

I don't think we should make it a requirement to change the ID.  
Changing the ID might be a part of the solution, but I don't see why the 
solution should dictate the requirements.

Paul

---

From: Brett Tate <[email-masked]>
Date: Fri, 4 May 2012 08:47:06 -0700

Thanks for the response.

> While I'm not opposed to making an explicit statement 
> that the ID must change, that's not the requirement.  
> I believe it must change, but others may feel differently.

As far as I know, "the ID must change" is currently an implied requirement since nobody has communicated how REQ2 could be met (for the example) without the session identity changing within an existing dialog.

<snip>

> I don't think we should make it a requirement to change 
> the ID.  Changing the ID might be a part of the solution, 
> but I don't see why the solution should dictate the 
> requirements.

I'm concerned that as the working group reviews the requirements draft, the reviewers may not realize that an implied requirement/consequence of REQ2 is that a B2BUA connecting/joining two existing dialogs would potentially result in the session identifier changing within the dialog.

I prefer that the topic be debated as part of the requirements process instead of after the requirements draft becomes an RFC.  This is mostly because I prefer a non explicit "approved requirement" not subsequently be used as justification to change session identifiers within a dialog (or justification for a more severe remedy to meet REQ2).

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 9 May 2012 12:50:38 +0200

Hi,

I agree with Brett we need to get it out in the open in the requirements drafts that the identifier can change during a dialog and use transfer use case to bring this requirement out.

A 3PCC use case or two would also I think be appropriate.

Regards
Andy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Brett Tate
> Sent: 04 May 2012 16:47
> To: Paul E. Jones; [email-masked]
> Subject: Re: [Insipid] INSIPID Req#2 - comments?
> 
> Thanks for the response.
> 
> As far as I know, "the ID must change" is currently an implied
> requirement since nobody has communicated how REQ2 could be met (for
> the example) without the session identity changing within an existing
> dialog.
> 
> <snip>
> 
> I'm concerned that as the working group reviews the requirements draft,
> the reviewers may not realize that an implied requirement/consequence
> of REQ2 is that a B2BUA connecting/joining two existing dialogs would
> potentially result in the session identifier changing within the
> dialog.
> 
> I prefer that the topic be debated as part of the requirements process
> instead of after the requirements draft becomes an RFC.  This is mostly
> because I prefer a non explicit "approved requirement" not subsequently
> be used as justification to change session identifiers within a dialog
> (or justification for a more severe remedy to meet REQ2).
> 
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 09 May 2012 09:23:49 -0400

While I'm not stubbornly opposed to making such an explicit statement in 
the requirements document, having such a requirement seems to be a 
solution, not a requirement.  The requirement should not be to change an 
ID, but if the solution requires it to satisfy the requirement, then 
that's the solution.

Perhaps someone can come up with some interesting idea not already 
considered that would not require a change in the IDs used.  I doubt 
they can, but I'll never dismiss any possibility.

In any case, changing the ID isn't a requirement, but an answer to the 
requirement.

Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 9 May 2012 20:35:10 +0200

Hi,

The draft and even the working group charter are full of solution type stuff already so we are already going down that path.

Is it just me or is there a problem with terminology in the draft it seems to me after reading the terminology section that "session", "end-to-end session" and "communication session" all mean the same thing which makes some of the requirements really hard to understand if you read them literally.

I agree that specifying that the identifier can be changed within a dialog is really solution but can I ask whether there is already some assumption about whether this is a single identifier or whether it could be a more complex structure which somehow links things together after a transfer for example?

Some of the requirements seem to assume a single identifier, for example REQ3, and that was my assumption so far. If we have already decided that this is a single identifier then of course it is going to have to change in certain scenarios.

Regards
Andy

> From: Paul E. Jones [mailto:[email-masked]]
> Sent: 09 May 2012 14:24
> To: Hutton, Andrew
> Cc: Brett Tate; [email-masked]
> > I agree with Brett we need to get it out in the open in the
> requirements drafts that the identifier can change during a dialog and
> use transfer use case to bring this requirement out.
> >

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 09 May 2012 18:10:05 -0400

> The draft and even the working group charter are full of solution type stuff already so we are already going down that path.

If that's the case, we might want to change the wording a bit.  Feel 
free to propose suggested changes.

> Is it just me or is there a problem with terminology in the draft it seems to me after reading the terminology section that "session", "end-to-end session" and "communication session" all mean the…

Without looking at the document, I'd assume these are all the same.  
We're talking about a "session" and I think that it's not well-defined 
(nor is it defined elsewhere), but I believe we have the same notion of 
what we mean.  We had proposed defining that, but that was stricken from 
the charter.

> I agree that specifying that the identifier can be changed within a dialog is really solution but can I ask whether there is already some assumption about whether this is a single identifier or whe…

Our solution document defines a "session-ID" that is comprised of 
components. However, the proposed solution should not dictate the 
requirements.  I would like to have "a thing" we can point a finger at 
and call it a session ID.  I do not care how it's constructed, though I 
would like it to be usable across a plurality of protocols, including 
SIP, H.323, whatever RTCWeb goes with, and XMPP.

> Some of the requirements seem to assume a single identifier, for example REQ3, and that was my assumption so far. If we have already decided that this is a single identifier then of course it is go…

I believe it should be possible to view it as a single ID, though it 
might be comprised of components.  I've been down this path more than 
once already and each time I pick a single ID at one end, I encounter 
problems.  Once a call is in a steady state, though, there should be 
something we call the Session-ID (versus the session ID parts).  That 
said, at least one person did suggest that it might be better to view 
the session ID as a collection of parts.  I think we should only make 
that decision once we get the requirements solidified and start to work 
on a solution.

Paul

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 10 May 2012 16:19:01 -0500

I'm with Paul J. here, let's not make it a requirement to have to 
change the session-ID, though we can add some text to a motivation 
part around this REQ by saying it will likely change the ID. We 
shouldn't mandate the change, else we'll end up in a dog fight as to 
exactly what the scope of the change is.

For example, is changing 1 bit value in a Session-ID enough, or does 
at least or more than half of the ID need to change to satisfy this 
new mandatory aspect of this REQ?

James

At 08:23 AM 5/9/2012, Paul E. Jones wrote:
>While I'm not stubbornly opposed to making such an explicit 
>statement in the requirements document, having such a requirement 
>seems to be a solution, not a requirement.  The requirement should 
>not be to change an ID, but if the solution requires it to satisfy 
>the requirement, then that's the solution.
>
>In any case, changing the ID isn't a requirement, but an answer to 
>the requirement.
>
>Paul
>
>>requirements drafts that the identifier can change during a dialog 
>>and use transfer use case to bring this requirement out.
>>

---

From: Brett Tate <[email-masked]>
Date: Mon, 14 May 2012 04:34:41 -0700

> I'm with Paul J. here, let's not make it a requirement 
> to have to change the session-ID, though we can add 
> some text to a motivation part around this REQ by 
> saying it will likely change the ID. 

I agree; that was basically my suggested change.

"I recommend REQ2 (or whichever requirement implies such a thing) be modified to explicitly indicate that meeting the requirement may cause the session identifier to change within an existing dialog.  I recommend being explicit because it appears to go beyond the current charter.  And if I recall correctly, it was one of the controversial topics during the chartering process."

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 16 May 2012 10:52:05 -0400

How is this:

REQ2: It must be possible to identify the end-to-end session when a session
is transferred or if two different sessions are joined together via an
intermediary (e.g., a PBX).  Note that this might result in a change in the
value of the end-to-end Session-Identifier.

Paul

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brett Tate
> Sent: Monday, May 14, 2012 7:35 AM
> To: James M. Polk; [email-masked]
> > part around this REQ by saying it will likely change the ID.
> 
> "I recommend REQ2 (or whichever requirement implies such a thing) be
> modified to explicitly indicate that meeting the requirement may cause the
> session identifier to change within an existing dialog.  I recommend being
> explicit because it appears to go beyond the current charter.  And if I
> recall correctly, it was one of the controversial topics during the
> chartering process."
>