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

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 12 Jun 2003 15:05:46 -0400

Robert

If you have a UA that handles multiple calls, you don't need call waiting.
Another INVITE appears, you show it in your UI (lights, LCD, whatever),
and eventually the user decides to answer or ignore it.

What if you are a really simple UA?  A second call comes in.  Who does what?
It would seem that the really best answer is that the dumb UA puts the
call waiting tone into the current audio.  The user can then either
hang up the current call and let the second call ring through, or it can
press the "flash" button (if implemented), alternating between the two.  
It's all local.

What doesn't seem to work at all is to let some "tones and announcements"
server handle it - there is no way the dumb phone will create a media
connection to such a server if it has an active call.  That means call
waiting CANNOT be implemented by any other element but the called UA.

So, is this something that goes in a BCP?  Even a dumb phone should handle
call waiting.

Brian
_______________________________________________
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: "Satish Bansal!" <[email-masked]>
Date: Sat, 14 Jun 2003 12:57:30 +0530

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.

rgds
Satish Bansal
Senior Research Engineer
Intelligent Networks.

> So, is this something that goes in a BCP?  Even a dumb phone should handle

Life at its best is a series of challenges.
A big enough challenge will bring out strengths
and abilities you never knew you had.
Take on the challenges and you will bring yourself
to life

---

From: Alan Hawrylyshen <[email-masked]>
Date: Sat, 14 Jun 2003 15:28:20 -0600

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/