Subject: [Insipid] Questions on draft-jones-insipid-session-id-01.txt

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

Hi,

a couple of quick questions on the following draft:

http://www.ietf.org/id/draft-jones-insipid-session-id-01.txt

The draft talks a few times about using a re-INVITE for call transfer.
What does the re-INVITE exactly do? Does it change the target URI of the
dialog, does it do something to the media streams?

In Section 10.2, Alice calls Bob and they end up using a session ID
value of A,B. Then, Bob transfers the call to Carol and Alice and Carol
end up using a session ID value of A,C. Now, if we extend the call flow
and have Alice transfer the call to David, Carol and David will end up
using a session ID value of C,D, which has nothing to do with the
original session ID value of A,B that created the communication session
in the beginning. I just want to make sure this is the type of behavior
people are after in a call transfer environment.

Cheers,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Oct 2012 11:38:14 -0400

> dialog, does it do something to the media streams?

AFAIK this is referring to a 3pcc based transfer, where the initiator of 
the reINVITE is the 3pcc controller.

Of course this begs the question of how the controller comes to know 
that a transfer is required. I think Cisco PBXs have a way to do this 
out of band. But it can also be achieved in a sip way by using a REFER 
based transfer that is handled in the 3pcc controller, using a reINVITE 
to the transferred party to map the existing dialog to the new party.

	Thanks,
	Paul

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 26 Oct 2012 02:17:08 -0400

Gonzalo,

> dialog, does it do something to the media streams?

This might be done via proprietary signaling or via REFER, as Paul K.
mentioned.
 
> people are after in a call transfer environment.

This is the type of behavior I was seeking.  This allows us to have a unique
end-to-end session identifier.  It also allows us to look at log files and
see these transitions occur, even if we looked at no specific signaling.  It
also allows us to correlate these kinds of changes when they occur between
protocols like H.323 and SIP.

Note also that on any transfer, a transferred-to device might actually be
many devices (e.g., David's desk phone, mobile phone, tablet, etc.)  So, we
might actually see a series of identifier pairs {C,D1}, {C, D2}, {C, D3},
... as the call is forked.  In the end, only one survives, of course, but
all of this would be captured in logs.

Paul