Subject: [Insipid] 3.X Tracking sessions transferred from one endpoint to another: evaluation

From: James Polk <[email-masked]>
Date: Mon, 27 Aug 2012 18:21:55 -0500

INSIPID

Here is the set of use-cases and requirements discussed in Vancouver. 
We are to come to consensus on each of these (or not), and if we 
agree the use-case or requirement should be in the document, we need 
to determine acceptable wording for each. The Subject: line will 
contain the specific topic (which use-case or requirement) for this 
thread. PLEASE do not cross contaminate the threads. Any new topic 
SHOULD have its own Subject line. The chairs will monitor and call 
for consensus on each use-case and requirement (and wording of each).

Please make constructive suggestions regarding each you care about.

The Section numbers will be reordered once consensus has been reached 
on all items we're covering, so don't worry about that part.

3.X Tracking sessions transferred from one endpoint to another:

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:

---

From: Brett Tate <[email-masked]>
Date: Tue, 28 Aug 2012 09:53:46 -0700

> 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).

As far as I know, this use case should not be added since it does not meet the "one in / one out case where the To/From header fields could have been preserved" situation (unless the use case can actually be met without changing session identifier within existing dialog).  Thus I think that the use case should not be included within draft.

If such use cases are within scope for insipid, the use case should likely be split into multiple parts or uses cases.  The following are a few parts; however there are likely other interesting related use case.

1) B2BUA connecting 4 dialogs for 2 active calls (A-B and A-C).  B2BUA receives REFER with Refer-To replaces from one party (A) involved in both calls (attended transfer), the B2BUA reconnects the other two parties (B and C) together using re-INVITE.

2) B2BUA connecting two dialogs for active call.  B2BUA reconnects/transfers one party (using re-INVITE) to a new party (such as within RFC 3725 figures 7 and 13).

3) B2BUA connecting two dialogs for active call.  B2BUA receives INVITE with Replaces to replace one of the connections/dialogs.

Thanks,
Brett

---

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

Brett,

With what we had proposed, whether a device uses REFER or not makes no
difference.  In our original proposal, Alice will have some value A that
persists for the duration of the call.  Likewise, Bob and Carol would have
UUIDs that persist.

So, regardless of what the signaling looks like, Alice retains her value A
until the call is terminated.  There might be some debate over whether Alice
should carry the value A even when receiving a REFER and initiating a new
INVITE to Carol, though I would prefer that it did.  However, in all cases
where Alice does not send a new INVITE in response to a REFER, but rather
some intermediary B2BUA handles the transfer, Alice would definitely retain
A.

Do you still think we need to break these out?  Will the expanded
requirements change the signaling flow outside of the B2BUA?  If so, I'll be
happy to add them if you me exactly what you'd like to have in the text in
the form of a requirement.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brett Tate
> Sent: Tuesday, August 28, 2012 12:54 PM
> To: [email-masked]
> Subject: Re: [Insipid] 3.X Tracking sessions transferred from one endpoint
> to another: evaluation
> 
> > It is difficult to track which SIP messages where involved in the same
> > call across transactions, especially when invoking supplementary
> As far as I know, this use case should not be added since it does not meet
> the "one in / one out case where the To/From header fields could have been
> preserved" situation (unless the use case can actually be met without
> changing session identifier within existing dialog).  Thus I think that
> the use case should not be included within draft.
> 
> If such use cases are within scope for insipid, the use case should likely
> be split into multiple parts or uses cases.  The following are a few
> parts; however there are likely other interesting related use case.
> 
> 1) B2BUA connecting 4 dialogs for 2 active calls (A-B and A-C).  B2BUA
> receives REFER with Refer-To replaces from one party (A) involved in both
> calls (attended transfer), the B2BUA reconnects the other two parties (B
> and C) together using re-INVITE.
> 
> 2) B2BUA connecting two dialogs for active call.  B2BUA
> reconnects/transfers one party (using re-INVITE) to a new party (such as
> within RFC 3725 figures 7 and 13).
> 
> 3) B2BUA connecting two dialogs for active call.  B2BUA receives INVITE
> with Replaces to replace one of the connections/dialogs.
> 
> Thanks,
> Brett
> 
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

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

At 11:53 AM 8/28/2012, Brett Tate wrote:
>As far as I know, this use case should not be added since it does 
>not meet the "one in / one out case where the To/From header fields 
>could have been preserved" situation (unless the use case can 
>actually be met without changing session identifier within existing 
>dialog).  Thus I think that the use case should not be included within draft.

The ability to track transferred calls across B2BUAs is a fundamental 
use of this Session-ID. This use-case and requirement needs to stay.

>If such use cases are within scope for insipid, the use case should 
>likely be split into multiple parts or uses cases.  The following 
>are a few parts; however there are likely other interesting related use case.
>
>1) B2BUA connecting 4 dialogs for 2 active calls (A-B and 
>A-C).  B2BUA receives REFER with Refer-To replaces from one party 
>(A) involved in both calls (attended transfer), the B2BUA reconnects 
>the other two parties (B and C) together using re-INVITE.
>
>reconnects/transfers one party (using re-INVITE) to a new party 
>(such as within RFC 3725 figures 7 and 13).
>
>3) B2BUA connecting two dialogs for active call.  B2BUA receives 
>INVITE with Replaces to replace one of the connections/dialogs.

I'm not sure about expanding the call transfer use-case any more than 
it is, mainly because everyone's got a favorite or few scenarios that 
will apply here and this text isn't supposed to be 'that' verbose 
(i.e., for each scenario). I'm not opposed to a few if the WG 
believes that's needed though.

James

---

From: Brett Tate <[email-masked]>
Date: Thu, 30 Aug 2012 05:03:48 -0700

> > > session (i.e., until a BYE is sent).

<snip>

> believes that's needed though.

If the use cases are just to help identify requirements, I agree that they likely are not needed as long as something captures that it is acceptable (or mandatory) to be able to change the session identifier within an existing dialog.

However if the use cases are intended to ensure that the solution draft covers these types of scenarios, these 3 use cases could be useful.

Concerning number 1, is the B2BUA supposed to provide a new Session-ID within re-INVITE?  If not, should the re-INVITE's Session-ID reflect the currently connected dialog or subsequently connected dialog?

Concerning number 2 and figure 13, is the B2BUA supposed to provide a new Session-ID within re-INVITE (4)?  Is the B2BUA supposed to muck with the received re-INVITE 200 (5) Session-ID or just proxy it within INVITE (6)?

Concerning number 3, is the B2BUA supposed to muck with the received INVITE's Session-ID or just proxy it within re-INVITE?

Thanks,
Brett

---

From: James Polk <[email-masked]>
Date: Thu, 30 Aug 2012 15:28:22 -0500

At 07:03 AM 8/30/2012, Brett Tate wrote:
>If the use cases are just to help identify requirements, I agree 
>that they likely are not needed as long as something captures that 
>it is acceptable (or mandatory) to be able to change the session 
>identifier within an existing dialog.
>
>However if the use cases are intended to ensure that the solution 
>draft covers these types of scenarios, these 3 use cases could be useful.

I agree with what you're saying -- i.e., if they are guidance - each 
example isn't set in stone for a solution; but if the WG decides each 
example within a use-case has to be accounted for within any 
solution, we need tight text for each example then. Plus, we can add 
examples that any solution has to account for, much like you've listed above.

James

>Concerning number 1, is the B2BUA supposed to provide a new 
>Session-ID within re-INVITE?  If not, should the re-INVITE's 
>Session-ID reflect the currently connected dialog or subsequently 
>connected dialog?
>
>Concerning number 2 and figure 13, is the B2BUA supposed to provide 
>a new Session-ID within re-INVITE (4)?  Is the B2BUA supposed to 
>muck with the received re-INVITE 200 (5) Session-ID or just proxy it 
>within INVITE (6)?
>
>Concerning number 3, is the B2BUA supposed to muck with the received 
>INVITE's Session-ID or just proxy it within re-INVITE?
>
>Thanks,
>Brett
>