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

From: "Dusan Mudric" <[email-masked]>
Date: Tue, 17 Jun 2003 11:55:47 -0400

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: Rohan Mahy <[email-masked]>
Date: Thu, 19 Jun 2003 10:27:34 -0700

Dusan,

Every SIP phone that I am aware of offers call waiting natively. It 
requires no cooperation on the part of any service provider, and no 
additional cost by either the end-user nor by any service provider.

- Nobody has provided any compelling benefit to the end-user to do call 
waiting in the network
- Nobody has provided any compelling benefit to the service provider to 
do call waiting in the network
- Nobody has demonstrated that any SIP phones implement any of the 
additional weirdo mechanism that would be required to make network call 
waiting work as well as locally-implemented call waiting, Nor that 
there is any compelling economic reason for them to do so.

thanks,
-rohan

On Tuesday, June 17, 2003, at 08:55 AM, Dusan Mudric wrote:

> 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.
>