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

From: Alan Hawrylyshen <[email-masked]>
Date: Sun, 15 Jun 2003 15:28:44 -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/

_______________________________________________
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: "Rosen, Brian" <[email-masked]>
Date: Mon, 16 Jun 2003 10:38:53 -0400

I don't think your second option works.

The situation is that a call is up to the called party (the one that
gets call waiting).  No amount of 3PCC is going to change the state of
that call such that a tone could be played.  You would have to instruct
the called party to put the existing call on hold, and then accept
(automatically!)
a call from tones/announcement generator without ringing.  No way that
any dumb phone is going to do that.

Brian
-----Original Message-----
From: Satish Bansal! [mailto:[email-masked]]
Sent: Saturday, June 14, 2003 3:28 AM
To: Rosen, Brian
Cc: [email-masked]'
Subject: Re: [Sipping] Call Waiting - who does the tone

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. 
"Rosen, Brian" wrote: 
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
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: "Rosen, Brian" <[email-masked]>
Date: Tue, 17 Jun 2003 11:07:23 -0400

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: 

 
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,

---

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

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

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,

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 17 Jun 2003 13:04:09 -0400

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

> Sent: Tuesday, June 17, 2003 11:56 AM
> To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal!
> Cc: [email-masked]
> 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.
> 
> From: 	Rosen, Brian [mailto:[email-masked]] 
> Sent:	Tuesday, June 17, 2003 11:07 AM
> To:	Dusan Mudric; Alan Hawrylyshen; Satish Bansal!
> Cc:	[email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 17 Jun 2003 15:54:47 -0400

Please look again.  You don't get media for the 486.
The transaction completes, and a new transaction starts
with INVITE.  The media flow occurs as a result of the
INVITE.  You will also note that you see 180 Ringing.

What would you expect the user experience to be?
Using this example, you would experience a call,
two way audio, then the call would have to be cut off 
without warning, your phone would ring, and when you
answered, you would hear a tone or announcement.
I suppose that if you hung up from that "call", you
could get another call, which would be your original
call, resumed, which you could then hang up, and
get yet another call which would be the waiting call.

Also, for that to work at all, the original call,
as well as the waiting call, have to arrive at your
phone via 3PCC.  One of the underlying assumptions
about 3PCC is that the controller is the "other"
participant for both end-participants.  There are no
systems I'm familiar with that do this.

Dusan, I don't think there are any systems out there, or
even contemplated, that would support call waiting implemented
this way.  I also don't think it's a good idea.

I think we probably should keep call waiting a local
function and not a network function.

Brian

> Sent: Tuesday, June 17, 2003 2:13 PM
> 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.
> 
> Sent:	Tuesday, June 17, 2003 1:04 PM
> To:	Dusan Mudric; Rosen, Brian; Alan Hawrylyshen; Satish Bansal!
> Cc:	[email-masked]

---

From: "Dusan Mudric" <[email-masked]>
Date: Tue, 17 Jun 2003 16:49:52 -0400

Call flow is very close. Originating UA-C can experience smoother events: ringing and than media stream with announcement. Terminating party UA-B can get a signal from media server for the call from UA-C waiting for UA-B.  When terminating party UA-B is ready to accept the call (hung up with UA-A), proxy sends INVITE for the second session to the terminating UA-B, UA-B sends 200 OK, and proxy issues re-INVITE to originating party UA-C (assumption is UA-C is still waiting). Media stream is cutoff and original session with calling party is reestablished.
Regards,
Dusan Mudric.

 -----Original Message-----
From: 	Rosen, Brian [mailto:[email-masked]] 
Sent:	Tuesday, June 17, 2003 3:55 PM
To:	Dusan Mudric
Cc:	[email-masked]
Subject:	RE: [Sipping] Call Waiting - who does the tone

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 17 Jun 2003 17:55:06 -0400

Call waiting announcements traditionally are played to the called party
(call waiting tone).

The calling party experiences ringing, and then either answer or
forwarding-no answer behavior.

How does called party B know that C is waiting?  That is the call waiting
problem I first started this thread on.

It's not a problem for call forward-no answer to allow a retry, with
announcements, if that's what you want, but it doesn't have much
to do with call waiting.

Brian

> Sent: Tuesday, June 17, 2003 4:50 PM
> To: Rosen, Brian
> Cc: [email-masked]
> Call flow is very close. Originating UA-C can experience 
> smoother events: ringing and than media stream with 
> announcement. Terminating party UA-B can get a signal from 
> media server for the call from UA-C waiting for UA-B.  When 
> terminating party UA-B is ready to accept the call (hung up 
> with UA-A), proxy sends INVITE for the second session to the 
> terminating UA-B, UA-B sends 200 OK, and proxy issues 
> re-INVITE to originating party UA-C (assumption is UA-C is 
> still waiting). Media stream is cutoff and original session 
> with calling party is reestablished.
> Regards,
> Dusan Mudric.
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 20 Jun 2003 13:32:25 -0400

There is nothing even close to providing what would seem to be needed
to achieve this goal - the ability of a server in the network to
inject a media stream into an existing stream, or, worse,
interrupt the existing stream and play an announcement.
It would take a pretty significant change to SIP to do this,
something like a special INVITE that was explicitly automatically
answered, with no ringing, that pre-empted or mixed with the
existing call.

The security implications alone are daunting.

It would be something that would have to have mandatory-to-implement
characteristics in order to deploy the service.

I'm not interested in such a change.  

In most of the cases where networks presently provide announcements,
the current SIP mechanisms suffice.  Call waiting tone for one line
phones may not be implemented well yet, shame on us, but most 
functions do work.

You might want to cite some more instances where a network announcement
in the middle of a session is needed.  I think MLPP is probably a
UA function also, as Rohan pointed out in his reply to your prior post,
so that's probably not a good example either.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 20, 2003 1:05 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]

In a message dated 6/20/2003 9:47:56 AM Eastern Standard Time,
[email-masked] writes: 

Can't the phone just generate a local beep? Or do you propose a $M 
project to generate the beep from a media server in the network?  :-) 

I can certainly foresee a service provider that wants to provide a Call
Waiting announcement like "You have a call waiting from John Doe." rather
than a beep. And there are many other cases of the need to provide
announcements in the middle of a call. I think Dusan's comments should be
thought of in the general case, not just Call Waiting. While I don't know if
his idea is a good one or possible, we still need a general solution for
this. 

Mike Pierce