Subject: RE: [Sipping] Call Waiting - who does the tone

From: "Dusan Mudric" <[email-masked]>
Date: Tue, 17 Jun 2003 14:12:45 -0400

Media connection can be established on 486 busy. It would be very similar call flow as in draft-ietf-sipping-service-examples-04.txt, 2.7 Call Forwarding - Busy.

Btw, we should add this service description in the mentioned draft.

Regards,
Dusan Mudric.

 -----Original Message-----
From: 	Rosen, Brian [mailto:[email-masked]] 
Sent:	Tuesday, June 17, 2003 1:04 PM
To:	Dusan Mudric; Rosen, Brian; Alan Hawrylyshen; Satish Bansal!
Cc:	[email-masked]
Subject:	RE: [Sipping] Call Waiting - who does the tone

Hmmm, please explain.

I don't think there is any "busy" (which is usually a 400 class
response to an INVITE) that creates a media connection.
Of course, usually call waiting is overlaid (mixed) with live audio,
but even as an independent media stream, you can't use 3PCC to cause
the called party to put his existing call on hold.  You would have to
force both ends of the call to reroute to a mixer.  A middle box
can't do that, and it isn't likely to work smoothly at all.

Brian

> -----Original Message-----
> From: Dusan Mudric [mailto:[email-masked]]
> Sent: Tuesday, June 17, 2003 11:56 AM
> To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal!
> Cc: [email-masked]
> Subject: RE: [Sipping] Call Waiting - who does the tone
> 
> 
> There is an existing SIP busy that can be used to offer 
> multi-party call waiting announcement service. Off-hook from 
> terminating party would be signaled with re-INVITE.
> 
> Regards,
> Dusan Mudric.
> 
>  -----Original Message-----
> From: 	Rosen, Brian [mailto:[email-masked]] 
> Sent:	Tuesday, June 17, 2003 11:07 AM
> To:	Dusan Mudric; Alan Hawrylyshen; Satish Bansal!
> Cc:	[email-masked]
> Subject:	RE: [Sipping] Call Waiting - who does the tone
> 
> If this was desirable, which I don't personally believe it is, 
> I don't think there exists a sip mechanism that would enable it.  
> Are you proposing we create one?  
> 
> Brian
> -----Original Message-----
> From: Dusan Mudric [mailto:[email-masked]]
> Sent: Tuesday, June 17, 2003 11:04 AM
> To: Alan Hawrylyshen; Satish Bansal!
> Cc: Rosen, Brian; [email-masked]
> Subject: RE: [Sipping] Call Waiting - who does the tone
> 
> 
> Call Waiting service in the core of the network offers more flexible
> solution to service providers. They can chose which media 
> server to use and
> type of announcement message to play to the end user waiting 
> on the call.
> This would be a part of service offering (in this particular 
> example, call
> waiting) to a subscriber. In addition, it is UA independent.
>  
> Regards,
> Dusan Mudric.
> Senior Sw Engineer
> Leapstone Systems Inc.
>  
> -----Original Message-----
> From: Alan Hawrylyshen [mailto:[email-masked]]
> Sent: Saturday, June 14, 2003 5:28 PM
> To: Satish Bansal!
> Cc: Rosen, Brian; [email-masked]'
> Subject: Re: [Sipping] Call Waiting - who does the tone
>  
> On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish 
> Bansal! wrote: 
>  
> There could be two options. First as you said,  a dump phone 
> should handle
> call waiting. It would mean that we are making  end nodes 
> intelligent. 
>  
> Second option is that intelligence is in the  network, the 
> inbound proxy
> should be call statefull and should use 3pcc for playing tone & annc.
> through a server to  the party. 
>  
> Certainly both solutions work, but keeping the implementation of this
> feature in the UA would be , in my opinion, more in keeping 
> with the SIP
> design philosophies of keeping the core relatively free of 
> complexity. With
> this support in the end-UAs you will see better user 
> experiences in mixed
> domain deployments (e.g. receipt of a call via direct URL 
> dialing while in a
> pre-existing session established through the proxy handling 
> your registered
> AOR). 
>  
> Although it raises the bar a little bit for the UA 
> implementors, I certainly
> feel that it will scale better and reduce the overall cost to 
> maintain and
> deploy the 'core' portion of a SIP network infrastructure. 
>  
> I would agree w/ Brian on this; this could be appropriate for 
> inclusion in a
> BCP document. 
>  
> De-lurking, 
>  
> Alan Hawrylyshen Jasomi Networks Inc. 
> sip:[email-masked] mailto:[email-masked] 
> http://www.jasomi.com/ 
> 
> 

_______________________________________________
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: Alan Johnston <[email-masked]>
Date: Tue, 17 Jun 2003 14:33:41 -0500

Hi Dusan,

See my comments below.

Thanks,
Alan Johnston
MCI

At 02:12 PM 6/17/2003 -0400, Dusan Mudric wrote:
>Media connection can be established on 486 busy. It would be very similar 
>call flow as in draft-ietf-sipping-service-examples-04.txt, 2.7 Call 
>Forwarding - Busy.

But the media connection is established with a different UA - there is no 
way this flow can be made into a call waiting flow without invoking some 
sort of non-SIP 3rd party control which is not part of the Service Examples.

I agree with Brian that call waiting is a trivial end-point service.