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

From: "Elwell, John" <[email-masked]>
Date: Mon, 16 Dec 2002 10:32:04 +0000

Patrick,
 
Inline
 
John

John Elwell
e-mail: mailto:[email-masked] <mailto:[email-masked]>  

 -----Original Message-----
From: Patrick Mourot [mailto:[email-masked]]
Sent: 16 December 2002 08:39
To: Francois Audet; 'Alan Johnston'; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] Re: Challenges when interworking QSIG and SIP Call
Transfer

Francois 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

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

[JRE] I think re-INVITE is indeed sufficient (along with the other two
solutions suggested in the message from Frank that started this thread). The
gateway between the transferor and the transferee would send re-INVITE to
the transferee. The gateway between the transferor and the transfer target
would send re-INVITE to the transfer target. The interesting thing is that
SDP would not normally change. The only think that would change would be the
identify of the source of the re-INVITE request (e.g., in the
P-Asserted-Identity header).

Another alternative, similar to re-INVITE, would be UPDATE.

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

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

Comments? 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Dec 2002 22:37:29 -0500

inline.

> P-Asserted-Identity header).

THis is not the intended use of P-Asserted-ID, and falls outside the 
scope of its applicability. P-Asserted-ID allows one element, who has 
authenticated the requestor, to inform another element (over a trusted 
link) about the identity of the requestor.

Here, you are trying to have one element tell another element that its 
media is actually coming from a different source. We have no way to do 
that in SIP.

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

Replaces has nothing to do with it.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Patrick Mourot" <[email-masked]>
Date: Tue, 17 Dec 2002 09:45:46 +0100

Jonathan,

In Frank's e-mail  3 possible solutions are described to  tackle the
Problem.
Does your answer mean that we should use 1 of them ? or are there other
solutions that we have missed ?

Best Regards,

Patrick

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, December 17, 2002 4:37 AM
> To: Elwell, John
> Cc: 'Patrick Mourot'; Francois Audet; 'Alan Johnston';
> [email-masked]; [email-masked]
> Subject: Re: [Sipping] Re: Challenges when interworking QSIG and SIP
> Call Transfer
>
>
> inline.
>
> Elwell, John wrote:
> > Patrick,
>