Subject: Re: [Sipping] RE: [SIP] A question about the Music on Hold/Call Park inservice examplesdraft

From: Alan Johnston <[email-masked]>
Date: Thu, 14 Jun 2001 12:28:11 -0500

Jonathan,

OK - I can add the flow to the Service Examples draft in addition to the
existing flow (I'll use Xiaotao's flow below as the basis - send me any
corrections to it).

As for Replaces not being stable, we're pushing for implementations of it right
now since REFER seems stable (agreed?).  If there are open issues (besides the
Call-ID plus tags vs. call leg hash discussed on another thread) we need to
bring them up and discuss them ASAP.  Otherwise, we're going to have all kinds
of interoperability issues.

I'm sure I'm not the only one who is pained every time I read in the press that
SIP still can't do a basic feature like attended call transfer.

Thanks,
Alan.

Jonathan Rosenberg wrote:

> (moved to sipping)
>
>
> > -----Original Message-----
> > From: Alan Johnston [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 5:33 PM
> > To: Xiaotao Wu
> > Cc: [email-masked]
> > Subject: Re: [SIP] A question about the Music on Hold/Call Park in
> > service examplesdraft
> >
> >
> > 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.
>
> Well, B has to maintain call state, so thats not a big burden.
>
> > If B disappears or fails, the call will not be able
> > to be picked up.
>
> That can easily be fixed. The music-on-hold server can implement session
> timer. It will therefore detect the failure at B eventually (say a few
> minutes). It then sends a re-IVNITE to attempt to re-establish, which times
> out or generates a 481. At that point, the music-on-hold server thinks the
> call is down, and ceases listening on its RTP port, and stops sending RTCP.
> This will quickly trigger a call failure at A. A does the same thing,
> sending a re-INVITE to re-establish the call. This fails as well, and then A
> tears down the call.
>
> >
> > 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.
>
> Replaces is not stable yet, and I don't think its that widely supported. So,
> this alternate flow (which I like better), is pretty useful. Perhaps we can
> add it to the existing flow in the service examples draft?
>
> -Jonathan R.
>
> > Xiaotao Wu wrote:
> >
> > > 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.
> >
> >
> > _______________________________________________
> > 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.
> >
>
> ---
> 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
>
> _______________________________________________
> Sipping mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/sipping

---

From: "Benedito, Ernesto" <[email-masked]>
Date: Thu, 14 Jun 2001 16:20:13 -0400

Hi Folks,

My humble opinion on this. Well..I guess this e-mail is a bunch of questions rather than an opinion.

1- When using this B2BUA approach, what will happen with user A's display? Will the UA on user A be able to show "on hold" while the user is parked to the music server? I mean, detecting 0.0.0.0 in the "c" field of the SDP (and the new Invite) will allow the UA to notify the CC that it has to show the "hold" message on the LCD (or display of the device), but having a valid IP in the "c" header (as it would happen in this case, the one from the music server), how does A detects it is a hold and not a simple redirection of the media stream?

2- Why do you name this example as "Music on Hold/Call Park" rather than "Music on hold"? I am used to the traditional "Park" service (where you Park your call and go to another location [e.g. lab] and "pickup" the call from there). There is a reference in the document to the "pickup" scenario where it uses the forced "fork" solution triggered by the register method, but I guess both scenarios presented there can not be related at all. Has anyone thought/visualized the real Call Park/Pickup thing?

3- I came across this e-mail since I am looking for updates on the REFER method ( BTW, yes.. I am one of those that gets really disappointed when the press pounds SIP with poor "Transfer" capabilities). I am really interested to know (since I need "transfer" badly) if REFER is going to fly. Could anyone in this list please provide a status of this method. Thanks in advance.

Kind Regards
EB
 
-----Original Message-----
From: Alan Johnston [mailto:[email-masked]] 
Sent: Thursday, June 14, 2001 1:28 PM
To: Jonathan Rosenberg
Cc: Xiaotao Wu; [email-masked]'
Subject: Re: [Sipping] RE: [SIP] A question about the Music on Hold/Call Park inservice examplesdraft

Jonathan, 

OK - I can add the flow to the Service Examples draft in addition to the existing flow (I'll use Xiaotao's flow below as the basis - send me any corrections to it). 

As for Replaces not being stable, we're pushing for implementations of it right now since REFER seems stable (agreed?).  If there are open issues (besides the Call-ID plus tags vs. call leg hash discussed on another thread) we need to bring them up and discuss them ASAP.  Otherwise, we're going to have all kinds of interoperability issues. 

I'm sure I'm not the only one who is pained every time I read in the press that SIP still can't do a basic feature like attended call transfer. 

Thanks, 
Alan. 

(moved to sipping) 

> From: Alan Johnston [ mailto:[email-masked] <mailto:[email-masked]> ] 

-Jonathan R. 

> > URL   : http://www.cs.columbia.edu/~xiaotaow <http://www.cs.columbia.edu/~xiaotaow>  

--- 
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 <http://www.jdrosen.net>                       PHONE: (973) 952-5000 
http://www.dynamicsoft.com <http://www.dynamicsoft.com>  

_______________________________________________ 
Sipping mailing list 
[email-masked] 
http://www.ietf.org/mailman/listinfo/sipping <http://www.ietf.org/mailman/listinfo/sipping>