Subject: [SIP] REFER questions

From: Dvir Oren <[email-masked]>
Date: Mon, 5 Mar 2001 21:39:37 +0200 (IST)

Please forgive me if I'm asking questions that were already covered
(or are very stupid).  It simply has become impossible to try and read 
this mailing list or even effectively search for a solution or a
statue on some subject.

Anyway, after reading the relevant internet drafts, I can't understand 
a couple of things:

Basically, when I think of "call transferring" I think of the
following situation:

A calls B
B puts A on hold
B calls C
B now reroutes the call with A to C

How is this done with REFER?  That is, should B send A a REFER message 
telling him to call C, or should it send C the REFER?  How does either 
side know that the REFER is referring to the call with B?

Suppose B send A a REFER (with the same Call-ID, hence A knows what B
is referring to).  A will want to send an INVITE to C.  How does C
recognize that this is transferred call from B?

I couldn't find the following headers which were referenced in the
call examples:
Accept-Contact
Replaces

Where can I find them?

Also, normally (in the telephone world) when B wants to transfer the
call to C, he will hang up the phone (otherwise he would press
'flash').  However, hanging up the phone would normally cause a BYE to 
be sent (to both A and C???)  Is this valid?  When can B hang up the
call with C?  And if B hung up the phone with A, what point is there
with the NOTIFY then?  Suppose B receives a NOTIFY claiming that the
transfer failed.  B no longer has a call with A.  This NOTIFY is
pointless.  I would imagine that A, having the transfer fail, should
INVITE B again.

And one last thing:

If I would want B to 'blindly' transfer a call to C (from A), in the
telephony world I imagine that would be pressing 'flash', dialing in
the number, and immediately hanging up.  This would cause quite a
complex chain of messages to be sent.  First an INVITE, then a CANCEL, 
and then a REFER to A, and a BYE to A.

I understand that theoretically, there is a cleaner way to do this.
But limiting myself to only a plain old telephone, I don't know how a
user could identify that he/she wants only a blind transfer, without
going through that.

Any help, ideas?

-- 
Dvir Oren               <[email-masked]>
Lucid Voice Ltd.   <http://www.lucidvoice.com>
5 Jabotinski St., Ramat-Gan, 52520      Israel
Tel: 972 3 5757488          Fax: 972 3 5757499

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Alan Johnston <[email-masked]>
Date: Mon, 05 Mar 2001 18:30:45 -0600

Dvir,

See my comments below.

Thanks,
Alan Johnston
WorldCom
sip:[email-masked]

> Anyway, after reading the relevant internet drafts, I can't understand

I assume you have read draft-ietf-sip-service-examples-01.txt which has
just appeared in the archives but has not yet been announced to the list.

> side know that the REFER is referring to the call with B?

This is exactly flow 2.5 from the document.  If you want the flow to have
a similar feel to today's transfers, something in referred INVITE from C
to A needs to tell A that it should not ring the phone (or worse, send a
486) but instead accept the INVITE and send a BYE to B.  This is almost
implied by the Referred-By: B header in the INVITE, but not quite.  Doing
these calls convinced me that we need the Replaces header
(draft-biggs-sip-replaces-00.txt) to do these important services.  Flow
2.2 Music on Hold/Call Park would also greatly benefit from the Replaces
header.

> recognize that this is transferred call from B?

If  you chose to do it this way, the Referred-By header in the INVITE
would contain Referred-By: B.  But that just tells you that this INVITE
was generated at the request of B, not necessarily that this call replaces
the existing call between A and B.

I neglected to include references to them.  Accept-Contact is in
draft-ietf-sip-callerprefs-03.txt and I have already mentioned the
reference for Replaces.

> pointless.  I would imagine that A, having the transfer fail, should

These are user interface questions, not protocol issues.  The answer is
that you should be able to make any sequence of button pushes, flashooks,
etc generate the correct SIP messages to accomplish what you desire.  The
result may be some NOTIFY messages that are ignored (except for a 200 OK
response to stop retransmissions).  This is simpler than trying to specify
in the REFER whether a NOTIFY is wanted or not.

> and then a REFER to A, and a BYE to A.

Actually, this is flow 2.4 and would just involve a REFER then a BYE.