Subject: [SIP] A question about the Music on Hold/Call Park in service examples draft

From: Xiaotao Wu <[email-masked]>
Date: Fri, 25 May 2001 15:04:51 -0400 (EDT)

For the Music on Hold/Call Park in the SIP service examples draft,
it requires the User A (can be considered as the customer's SIP user
agent) to understand the Replaces header as in the
draft-biggs-sip-replaces-00.txt.

Why not just simply let the user B send INVITE to the Music server with
the customer's (user A) UA's RTP info and re-INVITE customer's UA with
Music server's RTP info to perform this service. The call flow is as the
following figure.

                A                   B                   C

                |                   |                   |
                +-----INVITE------->+                   |
                |                   |                   |
                +------200----------+                   |
                |                   |                   |
                +------ACK----------+                   |
                |                   |                   |
                |             User B park call          |
                |                   |                   |
                |                   +---INVITE with---->+
                |                   |     A's SDP       |
                |                   +<-----200 ---------+
                |                   |                   |
                +<--re-INVITE with--+                   |
                |     C's SDP       |                   |
                +-----200---------->+                   |
                |                   |                   |
                +<----ACK-----------+                   |
                |                   +------ACK--------->+
                |                   |(If user B gets BYE before
                |                   | the user B picks up the call
                |                   | the user B will BYE to music server)
                |                   |                   |
                |             User B picks up           |
                |                   |                   |
                |                   +----- BYE--------->+
                |                   |                   |
                |                   +<-----200----------+
                |                   |                   |
                +<---re-INVITE with-+                   |
                |     B's SDP       |                   |
                +------200--------->+                   |
                |                   |                   |
                +<-----ACK----------+                   |
                |                   |                   |
                +------- BYE ------>+                   |
                |                   |                   |
                +<----- 200 --------+                   |

The user B works like a B2BUA. Since it's the user B initiate the service,
it's reasonable to put the complexity in the user B's user agent instead
of adding complexity to user A (the customer)'s user agent.

And by this way, there is no need to use REFER and NOTIFY.

-Xiaotao

=========================================================
Name  : Xiaotao Wu
Email : [email-masked], [email-masked]
URL   : http://www.cs.columbia.edu/~xiaotaow
Phone : (212)939-7087, (212)939-7133,  Fax: (801)751-0217
SIP   : sip:[email-masked]
Office: Room 623, Schapiro (CEPSR), West 120th
=========================================================

_______________________________________________
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: Fri, 25 May 2001 16:32:50 -0500

Xiaotao,

Your call flow will work - it is one way to implement this service.  It does,
however, require B to keep state on the session as long as the call is
parked.  If B disappears or fails, the call will not be able to be picked up.

Many services can be implemented using either SIP primitives such as REFER or
using B2BUA approaches.  I agree that this does simplify requirements for A,
but I believe that REFER and Replaces will be supported by most UAs.

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