Subject: [Insipid] Handling (or not) of call transfer

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 6 Oct 2012 21:52:07 +0200

(As WG cochair)

We currently have a use case in the requirements document as follows:

"3.6. Tracking transferred sessions

   It is difficult to track which SIP messages where involved in the
   same call across transactions, especially when invoking supplementary
   services such as call transfer or call join. The ability to track
   communications sessions as they are transferred, one side at a time,
   through until completion of the session (i.e., until a BYE is sent).

   Derived Requirements: REQ1, REQ2, REQ10"

This results in requirement 2 as follows:

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

>From the discussion in the virtual interim it appears that we do not have the right requirement that corresponds to the scope, however there seemed to be a need to have something.

Please contribute to the mailing list on what you think the requirement should now be, and as such, what impact this has on the use case.

Regards

Keith

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 7 Oct 2012 14:19:18 -0400

Personally, I like the requirement.  The primary objective of the work is to
identify a session end-to-end.  The reasons are several, but one strong use
case is to be able to troubleshoot.  Service interaction can make this
challenging, since two separate calls can be merged into one, calls can be
transferred, etc.  When there are such service interactions, we do not want
to lose the ability to identify the resulting session and the ability to
relate that to the former end-to-end session.  That's why we proposed the
solution we proposed.  In all cases where Alice calls Bob and, through
whatever mechanism, Alice ends up in communication with Carol, Alice retains
here Session-ID-UUID value.  Likewise, Carol retains her distinct value.
These two UUIDs then serve to identify a session end-to-end.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of DRAGE, Keith (Keith)
> Sent: Saturday, October 06, 2012 3:52 PM
> To: [email-masked]
> Subject: [Insipid] Handling (or not) of call transfer
> 
> (As WG cochair)
> 
> From the discussion in the virtual interim it appears that we do not
> have the right requirement that corresponds to the scope, however there
> seemed to be a need to have something.
> 
> Please contribute to the mailing list on what you think the requirement
> should now be, and as such, what impact this has on the use case.
> 
> Regards
> 
> Keith
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 7 Oct 2012 21:17:23 +0200

Hi,

First, I think we can remove the last sentence in the REQ2 text. The REQUIREMENT is about being able to correlate end-to-end sessions. Whether the session id changes or not is not relevant from a requirement perspective, as long as there is A way to correlate.

Second, if we want to be able to correlate sessions, do we limit the scope transfer? What if users have other use-cases where sessions are considered to be correlated? Just because SIP sessions are joined toghether via an intermediary, I doesn't have to be transfer. One example is the 3GPP voice continuity function, where an application server joins together SIP sessions coming from the same user (but via different access technologies). I don't think we call that "transfer" (at least not user transfer).

Third, I know we've had discussions about this, but from reading the requirement I can't figure out what "end-to-end session" means. Maybe we should talk about correlating SIP sessions.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of DRAGE, Keith (Keith) [[email-masked]]
Sent: Saturday, October 06, 2012 10:52 PM
To: [email-masked]
Subject: [Insipid] Handling (or not) of call transfer

(As WG cochair)

Regards

Keith

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 7 Oct 2012 15:46:49 -0400

Christer,

> First, I think we can remove the last sentence in the REQ2 text. The
> REQUIREMENT is about being able to correlate end-to-end sessions.
> Whether the session id changes or not is not relevant from a requirement
> perspective, as long as there is A way to correlate.

I think that sentence is useful.  Under some circumstances, the end-to-end
session identifier might change.  Under other circumstances, it might remain
the same.  In our proposal, it would always change if either endpoint in the
session changes.  However, there may be a workable solution where the change
is not necessary; I just don't know what solution that would be.
 
> Second, if we want to be able to correlate sessions, do we limit the
> scope transfer? What if users have other use-cases where sessions are
> considered to be correlated? Just because SIP sessions are joined
> toghether via an intermediary, I doesn't have to be transfer. One
> example is the 3GPP voice continuity function, where an application
> server joins together SIP sessions coming from the same user (but via
> different access technologies). I don't think we call that "transfer"
> (at least not user transfer).

I think that might be an example of where sessions might be "joined"
together.  Arguably, that's still a "transfer", but it is important to
differentiate between cases where two existing calls are "spliced" together
vs. a case where a call between A and B is transferred such that B drops out
and a call between A and C exists.  The latter might be via a REFER or it
might not.  In any case, we need to cover "transferred" calls and calls that
are "joined" together.

> Third, I know we've had discussions about this, but from reading the
> requirement I can't figure out what "end-to-end session" means. Maybe we
> should talk about correlating SIP sessions.

The definition of "session" is itself overused, but we do not have a better
word.  However, we did define it in Section 2:

   The term "end-to-end" in this document means the communication
   session from the point of origin, passing through any number of
   intermediaries, to the ultimate point of termination. It is
   recognized that legacy devices may not support the "end-to-end"
   session identifier, though an identifier might be created by an
   intermediary when it is absent from the session signaling.

Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 7 Oct 2012 22:18:37 +0200

Hi,

> is not necessary; I just don't know what solution that would be.

I don't think the requirements should talk about your proposal :)

> might not.  In any case, we need to cover "transferred" calls and calls that

Of course, calls may also be joined together by the endpoints, ie there is no intermediary doing it.

So, IF we decide to keep the requirement, can't it simply say that it shall be possible to correlate multiple sessions?

       "REQ2: It must be possible to correlate multiple end-to-end sessions."

> word.  However, we did define it in Section 2:

Yes, I noted that. Comment withdrawn :)

Regards,

Christer

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 7 Oct 2012 17:10:59 -0400

Christer,

> > I think that sentence is useful.  Under some circumstances, the
> > end-to-end session identifier might change.  Under other
> > circumstances, it might remain the same.  In our proposal, it would
> > always change if either endpoint in the session changes.  However,
> > there may be a workable solution where the change is not necessary; I
> just don't know what solution that would be.
> 

It doesn't. I was only mentioning it as one where the end-to-end ID would
always change whenever one endpoint is exchanged for another.  Regardless of
the solution, it might be necessary to change the ID.  I think this
consideration should not be ignored.
 
> > differentiate between cases where two existing calls are "spliced"
> > together vs. a case where a call between A and B is transferred such
> > that B drops out and a call between A and C exists.  The latter might
> > be via a REFER or it might not.  In any case, we need to cover
> > "transferred" calls and calls that are "joined" together.
> 

This is true, but this bleeds into the "conferencing" scenarios.  In that
case, though, rather than having a conference on an MCU, the conference is
local to the phone.
 
> So, IF we decide to keep the requirement, can't it simply say that it
> shall be possible to correlate multiple sessions?
> 

That loses the original intent.  We want to ensure that we give
consideration to what happens when calls are transferred or joined together.
This is not the conferencing form of "joining" together, though.  (I do wish
we would still give consideration to conferencing, but I'm OK with ignoring
those cases.  In the case where a phone conferences three people together,
those are two distinct SIP sessions.  So, it would be logical to have two
distinct session IDs.  Correlating those would be nice, but I think we need
to somehow reintroduce the conferencing requirement.)

Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 8 Oct 2012 00:19:59 +0200

But does this just come down to a requirement that it must be possible to allow session ID changes in what I, from my viewpoint (be it a proxy or an end UE) still think is the same session (whatever we mean by that).

If two existing calls are spliced at a B2BUA, then what causes that change of session ID is outside the SIP world. Is the B2BUA allowed to force a change in the SIP world of session ID?

Regards

Keith

> From: Paul E. Jones [mailto:[email-masked]]
> Sent: 07 October 2012 22:11
> To: 'Christer Holmberg'; DRAGE, Keith (Keith); [email-masked]
> Subject: RE: [Insipid] Handling (or not) of call transfer
> 
> Christer,
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 7 Oct 2012 21:12:45 -0400

Keith,

In many scenarios I've considered, there is a need to allow the Session-ID
to change.  For some calls, I cannot see how we can avoid it.  The example
I've used is this:

Alice calls Bob.  (Session-ID = "1")
Carol calls Bob.  (Session-ID = "2")
Bob pushes a button on his phone and joins the call legs between Alice and
Carol, dropping out of the call.  In that case, we still want an end-to-end
identifier.  It might be "1", "2", or perhaps "3" ... but we need something
both ends agree to.

I've mentioned race condition examples in the past where, as an example,
when Bob presses a button to merge Alice and Carol, Alice presses the same
magic button to merge Bob and Sue (where Alice and Sue were previously
talking).  Now, Bob taking action to join call legs at the same time that
Carol does means that the resulting call is between Sue and Carol.  What
would be Session-ID be then?

With the solution we proposed, the answer is predictable.  It would be S ||
C.

Do we need more language than simply saying the call ID might change?  I
think so, because if we send a REFER message, we want to ensure that the
endpoints behave as expected.  We would want to correlate the new call with
the previous one.  We want that regardless of how the transfer or "join"
takes place.

Paul

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Sunday, October 07, 2012 6:20 PM
> To: Paul E. Jones; 'Christer Holmberg'; [email-masked]
> But does this just come down to a requirement that it must be possible
> to allow session ID changes in what I, from my viewpoint (be it a proxy
> or an end UE) still think is the same session (whatever we mean by that).
> 
> If two existing calls are spliced at a B2BUA, then what causes that
> change of session ID is outside the SIP world. Is the B2BUA allowed to
> force a change in the SIP world of session ID?
> 
> Regards
> 
> Keith
> 
> > > > circumstances, it might remain the same.  In our proposal, it
> > > > would always change if either endpoint in the session changes.
> > > > However, there may be a workable solution where the change is not
> > > > necessary; I
> > It doesn't. I was only mentioning it as one where the end-to-end ID
> > would always change whenever one endpoint is exchanged for another.
> > Regardless of the solution, it might be necessary to change the ID.  I
> > think this consideration should not be ignored.
> >
> > > > together.  Arguably, that's still a "transfer", but it is
> > > > important to differentiate between cases where two existing calls
> are "spliced"
> > > > together vs. a case where a call between A and B is transferred
> > > > such that B drops out and a call between A and C exists.  The
> > > > latter might be via a REFER or it might not.  In any case, we need
> > > > to cover "transferred" calls and calls that are "joined" together.
> > >
> > This is true, but this bleeds into the "conferencing" scenarios.  In
> > that case, though, rather than having a conference on an MCU, the
> > conference is local to the phone.
> >
> > > So, IF we decide to keep the requirement, can't it simply say that
> > > it shall be possible to correlate multiple sessions?
> > >
> > This is not the conferencing form of "joining" together, though.  (I
> > do wish we would still give consideration to conferencing, but I'm OK
> > with ignoring those cases.  In the case where a phone conferences
> > three people together, those are two distinct SIP sessions.  So, it
> > would be logical to have two distinct session IDs.  Correlating those
> > would be nice, but I think we need to somehow reintroduce the
> > conferencing requirement.)
> >
> > Paul
> >

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 8 Oct 2012 08:37:29 +0200

Hi,

>>> there may be a workable solution where the change is not necessary; 
>>> I just don't know what solution that would be.
>>
> It doesn't. I was only mentioning it as one where the end-to-end ID would always change whenever one endpoint is exchanged for another.  Regardless of the
> solution, it might be necessary to change the ID.  I think this consideration should not be ignored.

Maybe not, but it's not a requirement.
 
>>> together.  Arguably, that's still a "transfer", but it is important 
>>> to differentiate between cases where two existing calls are "spliced"
>>> that B drops out and a call between A and C exists.  The latter 
>>> might be via a REFER or it might not.  In any case, we need to cover 
> This is true, but this bleeds into the "conferencing" scenarios.  In that case, though, rather than having a conference on an MCU, the conference is local to the phone.
> 
> That loses the original intent.  We want to ensure that we give consideration to what happens when calls are transferred or joined together.
> This is not the conferencing form of "joining" together, though.  (I do wish we would still give consideration to conferencing, but I'm OK with ignoring those cases.  
> In the case where a phone conferences three people together, those are two distinct SIP sessions.  So, it would be logical to have two distinct session IDs.  

Why? Someone may want to, for troubleshooting purpose, correlate these SIP sessions.

> Correlating those would be nice, but I think we need to somehow reintroduce the conferencing requirement.)

It is not about introducing a conferencing requirement. It's about whether we need to put restrictions on what "correlation" means, or whether users can define that themselves - and e.g. use the session-id also to correlate sessions associated with a conference.

Regards,

Christer

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 8 Oct 2012 05:57:00 -0400

Christer,

> Maybe not, but it's not a requirement.

I'm struggling with this one.  I can concede that changing the Session-ID is
not, in and of itself, a requirement.  However, I cannot see any other way
to make these flows work without changing the Session-ID in some instances
(my most recent call flow is one such example).  So, how do we address that?
Perhaps we should say that it is a requirement that endpoints accept changes
to the Session-ID.  If we do not make it a requirement, does that suggest
it's a requirement that it stay fixed?
 
> with ignoring those cases.
> > In the case where a phone conferences three people together, those are
> two distinct SIP sessions.  So, it would be logical to have two distinct
> session IDs.
> 

I agree, they might.  To allow that to happen, we will have to do something
along the lines of what we were proposing for the conference focus.  When
the phone bridges three users together, it would use the same UUID (using
our proposed solution) for the two call legs.  It could send a new INVITE
down each side and inform endpoints of the change in the end-to-end
Session-ID.

I'm certainly OK with that, but folks wanted the conferencing requirements
removed.

> > Correlating those would be nice, but I think we need to somehow
> > reintroduce the conferencing requirement.)
> 
> It is not about introducing a conferencing requirement. It's about
> whether we need to put restrictions on what "correlation" means, or
> whether users can define that themselves - and e.g. use the session-id
> also to correlate sessions associated with a conference.

Without calling this a conference and speaking about it in those terms, I'm
not sure how we would describe this.  I'm open to suggestions :)

Paul

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 8 Oct 2012 13:48:48 +0300

> it's a requirement that it stay fixed?
what about changing the last sentence of the REQ2

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

with the following sentence (or an improved one):

"This must be possible regardless of any eventual change in the value of 
the end-to-end Session-Identifier."

in this way we provide the freedom for the solution, whatever it will 
be, to do whatever it has to do with the Session-Identifier.
The important here is not the value of the Session-Identifier per se, 
but the fact that can successfully be used to correlate sessions!

my two cents

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 9 Oct 2012 20:32:59 -0400

Sal,

> in this way we provide the freedom for the solution, whatever it will be,
> to do whatever it has to do with the Session-Identifier.

Yeah, that would work.  The intent with the original phrasing was to allow
the door to be open on this one.  I cannot see how we avoid changing the
identifier in some signaling scenarios, but I'm certainly open to a proposal
that might make it possible.

I'm going to submit a revision of the draft with changes agreed to during
the last call, but I'll exclude any changes to REQ2 right now.  If there is
agreement on this change, I can submit another revision again this week.

Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 25 Oct 2012 12:57:57 +0300

Hi,

this thread has discussed a requirement on being able to change the
session ID but still correlate sessions. That is a second level of
correlation you need to define very clearly in the requirements draft so
that people understand what it means and can comment on it.

If we assume that identifiers change but that there is a higher level of
correlation that will know about the different identifiers being
correlated, we are back into what we currently have with Call-IDs. A
B2BUA that changes the Call-ID in a request knows that both Call-IDs are
correlated even if they are different. The problem is that other
elements do not know about that. By defining several levels of
correlation we may very soon run into this type of problem.

Of course, anyone who was involved in SPLICES will recognize that these
are the same discussions we had in that WG.

Cheers,

Gonzalo

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 26 Oct 2012 01:50:03 -0400

Gonzalo,

This is REQ2 in the requirements document.  Use case is in 3.6.

How a transferred call is correlated would be defined by the solution.  The
requirement is merely that it must be possible.  We're not even concerned
necessarily with how the calls correlate, but merely that they are.

With the solution we've proposed, Alice would have some identifier A that
should would use for the life of a communication session -- from the time
she sends an INVITE to the time she sends or receives the final BYE. That
is, when the "call is over" as far as the human is concerned.  No matter how
many times she is transferred, she continues to use A in signaling.  This
allows for correlation.

There is no higher-level correlation than that.

Paul

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Thursday, October 25, 2012 5:58 AM
> To: Paul E. Jones
> Cc: Salvatore Loreto; [email-masked]
> Subject: Re: [Insipid] Handling (or not) of call transfer
> 
> Hi,
> 
> >> "This must be possible regardless of any eventual change in the value
> >> of the end-to-end Session-Identifier."
> >>
> > Yeah, that would work.  The intent with the original phrasing was to
> > allow the door to be open on this one.  I cannot see how we avoid
> > changing the identifier in some signaling scenarios, but I'm certainly
> > open to a proposal that might make it possible.
> >
> > I'm going to submit a revision of the draft with changes agreed to
> > during the last call, but I'll exclude any changes to REQ2 right now.
> > If there is agreement on this change, I can submit another revision
> again this week.
> >
> > Paul
> >
> >
> >
> >

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 27 Oct 2012 18:57:39 +0300

> necessarily with how the calls correlate, but merely that they are.

I already suggested to somehow relax the last sentence of REQ.2 so that
it does not include any possible link to the specific solution.
Having thought more on it, I do think it would be even better remove 
completely the
last sentence of REQ.2.
In this way the requirement would be really merely that it must be possible!

> many times she is transferred, she continues to use A in signaling.  This

yep but again, I would like to have the requirement been solution agnostic

/Sal

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 27 Oct 2012 17:09:15 -0400

Sal,

> > How a transferred call is correlated would be defined by the solution.
> > The requirement is merely that it must be possible.  We're not even
> > concerned necessarily with how the calls correlate, but merely that
> they are.
> 
> completely the last sentence of REQ.2.

My current draft has this sentence you provided:
    "This must be possible regardless of any eventual change in the
     value of the end-to-end Session-Identifier."

I think we should say something.  If we say nothing, then somebody might be
quite surprised to discover that the Session ID changes.  It would be nice
if the ID never changed, but there are flows that occur in normal operation
where I cannot see how we could not change the Session ID.  It only happens
in cases of call transfer, merging/joining calls, etc.  So, having this as a
comment tacked onto the end of this requirement is helpful.

We could remove that sentence, but I would not want somebody to say a
solution is not acceptable because the ID changes in certain flows.

Paul

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 28 Oct 2012 08:37:42 +0200

> solution is not acceptable because the ID changes in certain flows.

from my point of view the important is *the possibility to correlate 
sessions*,
and this is what the requirement should emphasize.

The fact that we correlate them through a header value that doesn't change,
or change only partially or change in a predictable way are all solution 
choices that would
meet the requirement.

/Sal

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 28 Oct 2012 14:18:33 -0400

Ok.. I removed the last sentence from REQ2.

Paul

> From: Salvatore Loreto [mailto:[email-masked]]
> Sent: Sunday, October 28, 2012 2:38 AM
> To: Paul E. Jones
> Cc: 'Gonzalo Camarillo'; [email-masked]
> >> I already suggested to somehow relax the last sentence of REQ.2 so
> >> that it does not include any possible link to the specific solution.
> > I think we should say something.  If we say nothing, then somebody
> > might be quite surprised to discover that the Session ID changes.  It
> > would be nice if the ID never changed, but there are flows that occur
> > in normal operation where I cannot see how we could not change the
> > Session ID.  It only happens in cases of call transfer,
> > merging/joining calls, etc.  So, having this as a comment tacked onto
> the end of this requirement is helpful.
> >
> sessions*, and this is what the requirement should emphasize.
> 
> The fact that we correlate them through a header value that doesn't
> change, or change only partially or change in a predictable way are all
> solution choices that would meet the requirement.
> 
> /Sal
> >
> > Paul
> >
> >
>