Subject: RE: [Sipping] Call transfer implementation on a SIP-IP phone

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 3 Aug 2001 16:52:07 -0400

The transfer target will respond with a 200 OK to the request pretty quickly
though, and if this happens before the onhook, you will need to mix the
media.

-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

> -----Original Message-----
> From: VIDHI RASTOGI [mailto:[email-masked]]
> Sent: Tuesday, July 31, 2001 7:33 AM
> To: Gonzalo Camarillo
> Cc: [email-masked]
> Subject: RE: [Sipping] Call transfer implementation on a SIP-IP phone
> 
> 
> Hi Gonzalo,
> Thanks for the reply..
> 
> I just modified the blind transfer call-flow a bit.. so that no mixing
> capabilities are required at the transferor phone. Please see 
> the following
> call-flow:
> 
> 
>  	A 		SIP-IP phone (POTS interface) 	C
>     (Transferee)		(Transferor)		    
> (transfer target)
>       |                       |
> 	|     active call       |
> 	|XXXXXXXXXXXXXXXXXXXXXXX|
> 	|                       |flash
> 	|INV (c=0)/200OK/ACK    |
> 	|<----------------------|
> 	|				|digits
> 	|	                  |                         |
> 	|	                  |        INV              |
>                               |------------------------>|
> 	|                       |onhook                   |
>       |                       |        CANCEL/200 OK    |
>       |                       |------------------------>|
>       |      REFER(Refer-To:C)|                         |
> 	|<----------------------|
> 
> 
> PLease give your comments?
> 

_______________________________________________
Sipping mailing list  http://www.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: Gonzalo Camarillo <[email-masked]>
Date: Mon, 06 Aug 2001 19:35:28 +0300

Hello,

The modified flow you propose does not do what you want it to do. The
phone of the 3rd party will begin ringing. When you send the CANCEL, it
will stop ringing, and when the entity that received the REFER sends the
INVITE, the phone will start ringing again.

I proposed that you wait until your first INVITE is answered and then
transfer the session using REFER. If you do not want to be acting as a
mixer for a couple of seconds, you run into a much more complex
scenario. What you want to do is to INVITE a 3rd party and then let
another user agent (different that yours) handle the INVITE. That is, it
will receive any provisional or final responses, early media, etc. You
could try to come up with a method for doing that using replaces, 490
transaction replaced and REFER. However, you would find lots of open
issues trying to do so.

Regards,

Gonzalo

VIDHI RASTOGI wrote:
> capabilities are required at the transferor phone. Please see the following
> call-flow:
> 
>     (Transferee)                (Transferor)                (transfer target)
>       |                       |
>         |     active call       |
> regards
> Vidhi
> > From: Gonzalo Camarillo [mailto:[email-masked]]
> > Sent: Tuesday, July 31, 2001 12:52 AM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [Sipping] Call transfer implementation on a SIP-IP phone
> >
> >
> > Hello,
> >
> > Comments inline:
> >
> > > On a POTS phone transfer is initiated by pressing FLASH and then dialing
> > > digits. Feature invoked by the sequence 'FLASH + DIGITS' can be Blind
> > > transfer (if transferor hangs up before the called party answers),
> > > consultation transfer (if transferor hangs up after the called party
> > > answers)
> >
> > I assume that in consultation transfer the 3 parties are in a small
> > conference call for a while, right?
> >
> > > or consultation hold (if the user falshes again). In PSTN scenario
> > > where the intelligence lies in the switch, the switch decides
> > which feature
> > > was invoked based on the user's last action. We are having problems in
> > > mapping the same action "FLASH+DIGITS" to a transfer feature on a SIP IP
> > > phone.
> > >
> > > The blind & consultation call flows are entirely different in
> > case of SIP
> > > call flows (draft-ietf-sip-cc-transfer-05.txt). Can you give
> > some clues on
> > > how to map the blind and consultation transfer call flows in
> > SIP to "FLASH +
> > > DIGITS" on a POTS phone. Providing a feature code to initiate
> > transfer from
> > > a POTS like SIP phone may not be appealing to the user.
> >
> > Your UA sends an INVITE to the 3rd party.
> >
> > 1) If you (the user of the POTS-alike phone) hang up before the 200 OK
> > arrives it means that you are in a blind transfer scenario. You wait
> > until the 200 OK arrives and for the first moments of the coversation
> > act as a mixer. You get the audio from the 3rd party and send it to the
> > first party and vice versa. Then, you send a REFER (using Replaces) to
> > the first party. The first party will INVITE the 3rd party and you will
> > be out of the call.
> >
> > 2) If you do not hang up it is because you wanted a consultation
> > transfer. When the 200 OK from the 3rd party arrives you will act as a
> > mixer. You will be effectively in a 3 party conferece call where you are
> > the mixer (end use mixing conference model). After speaking for a while,
> > you can get out of the call the same way as you did in 1)
> >
> > 3) If you flash it is because you want a consultation hold. In this case
> > you will send an INVITE with a hold SDP to the first party. When the 3rd
> > party answers the first party will not hear anything of what you are
> > saying.
> >
> > Best regards,
> >
> > Gonzalo
> >
> > >
> > > Any response on this issue would be very helpful.
> > >
> > > regards
> > > Vidhi
> > >
> > >
> > ------------------------------------------------------------------------
> > >                            Name: Wipro_Disclaimer.txt
> > >    Wipro_Disclaimer.txt    Type: Plain Text (text/plain)
> > >                        Encoding: 7bit
> >
> > --
> > Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> > Columbia University                  Mobile:  +358 40 702 35 35
> > 472 Computer Science Building        Fax   :  +358  9 299 30 52
> > 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> > New York, NY 10027
> > USA                              [email-masked]
> >
> 
>   ------------------------------------------------------------------------
>                            Name: Wipro_Disclaimer.txt
>    Wipro_Disclaimer.txt    Type: Plain Text (text/plain)
>                        Encoding: 7bit

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]