Subject: RE: [Sipping] Re: Challenges when interworking QSIG and SIP Call Transfer

From: "Francois Audet" <[email-masked]>
Date: Fri, 13 Dec 2002 12:28:43 -0800

> >1) Attended transfer.
> >
> >The Transferor is in QSIG and the Transferee and the Transfer Target 
> >are in SIP. When the Transferor performs a Call Transfer by join, it 
> >will send a notification to both the Transferee and the 
> Transfer Target 
> >and then connect the B-channels of the respective calls.
> 
> Interesting - this is a very different model.

My take on the transfer by join service is that it may not have much to
do with REFER.

I think solving the transfer by join scenario is very important as it is
very frequently used in TDM networks.

Let's say A and B are in a session. B and C are also in a session. B wants
to transfer A to C. In a transfer by join (in traditional networks), B
will be kept in the signalling path, will bridge the A and C locally, and
them tell A and C that they are now talking to a different user (done
after the transfer). The important is that from a signalling point of
view, there is still a "call" from A to B and another one from B to C.

In SIP, it seems to me that this is very similar to third party call control
scenario
(http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-02.txt).

B would re-INVITE A with C's SDP, and re-INVITE C with A's SDP. (There might
be some a=sendonly sent to place calls on hold but that is OK). 
At that point A and C would be communicating. 

I believe the "replaces" mechanism 
(http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-02.txt) 
can be used to update the identity of the party.

Comments?

---

From: "Patrick Mourot" <[email-masked]>
Date: Mon, 16 Dec 2002 09:38:32 +0100

RE: [Sipping] Re: Challenges when interworking QSIG and SIP Call
TransferFrancois et al,

See comments inline [pm],

Regards,

Patrick
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
Francois Audet
  Sent: Friday, December 13, 2002 9:29 PM
  To: 'Alan Johnston'; [email-masked]'; [email-masked]'
  Cc: [email-masked]'
  Subject: RE: [Sipping] Re: Challenges when interworking QSIG and SIP Call
Transfer

  In SIP, it seems to me that this is very similar to third party call
control
  scenario
(http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-02.txt).

  B would re-INVITE A with C's SDP, and re-INVITE C with A's SDP. (There
might
  be some a=sendonly sent to place calls on hold but that is OK).
  At that point A and C would be communicating.

  [pm] In some cases the transferror does not the SDP description of the
transferree and the transfer target  (i.e A & C behind 2 different GWs)...
so re-INVITE is not sufficient. I think we need another INVITE towards A & C
and then use QSIG  "Facilitiy PathReplacePropose " to update media path.

  [pm] Same Problem as above. Moreover We never see re-INVITE containing a
replaces.

  Comments?