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

From: "Dusan Mudric" <[email-masked]>
Date: Fri, 20 Jun 2003 08:48:40 -0400

Call waiting signal would be an announcement from a media server. Some UA's support audio mix. If not, proxy can put UA-A on hold while letting a media server play a short message to UA-B.

Regards,
Dusan Mudric.

 -----Original Message-----
From: 	weng zhiqiang [mailto:[email-masked]] 
Sent:	Friday, June 20, 2003 3:53 AM
To:	Dusan Mudric; Rosen, Brian
Cc:	[email-masked]
Subject:	Re: [Sipping] Call Waiting - who does the tone

hi :
   what do you suppose the call wait signal to be ? 
   a pure sip message or an announcement from media server ? 
   if it is an announcment , have we had to hold UA-A cause UA-B may  not support audio mix ?

BR
JohnyWeng
    
----- Original Message ----- 
From: "Dusan Mudric" <[email-masked]>
To: "Rosen, Brian" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, June 18, 2003 10:40 PM
Subject: RE: [Sipping] Call Waiting - who does the tone

> As mentioned "Terminating party UA-B can get a signal from media server for the call from UA-C waiting for UA-B." Terminating party UA-B can get call waiting signal from media on behalf on UA-C (proxy connects media to UA-B) while session with UA-A is in progress.
> 
> Calling party UA-C might experience a ringing or even more advanced services, like announcement, music, ..., while it is waiting for UA-B to finish the call.
> 
> Regards,
> Dusan Mudric.
> 
>  -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]] 
> Sent: Tuesday, June 17, 2003 5:55 PM
> To: Dusan Mudric
> Cc: [email-masked]
> Subject: RE: [Sipping] Call Waiting - who does the tone
> 
> 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
> 
> > -----Original Message-----
> > From: Dusan Mudric [mailto:[email-masked]]
> > Sent: Tuesday, June 17, 2003 4:50 PM
> > To: Rosen, Brian
> > Cc: [email-masked]
> > Subject: RE: [Sipping] Call Waiting - who does the tone
> > 
> > 
> > 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
> > 
> > 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
> > 
> > > -----Original Message-----
> > > From: Dusan Mudric [mailto:[email-masked]]
> > > Sent: Tuesday, June 17, 2003 2:13 PM
> > > To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal!
> > > Cc: [email-masked]
> > > Subject: RE: [Sipping] Call Waiting - who does the tone
> > > 
> > > 
> > > 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
> > > 
> > 
> > 
> 
> 
> 
> _______________________________________________
> 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

_______________________________________________
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: Henry Sinnreich <[email-masked]>
Date: Fri, 20 Jun 2003 08:42:08 -0500

Dusan,

I have followed your mail on this with some astonishment, and now the
latest:

> Call waiting signal would be an announcement from a media 
> server. Some UA's support audio mix. If not, proxy can put 
> UA-A on hold while letting a media server play a short 
> message to UA-B.

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?  :-)

Henry

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Dusan Mudric
> Sent: Friday, June 20, 2003 7:49 AM
> To: weng zhiqiang; Rosen, Brian
> Cc: [email-masked]
> Call waiting signal would be an announcement from a media 
> server. Some UA's support audio mix. If not, proxy can put 
> UA-A on hold while letting a media server play a short 
> message to UA-B.
> 
> Regards,
> Dusan Mudric.
> 
> > As mentioned "Terminating party UA-B can get a signal from media 
> > server for the call from UA-C waiting for UA-B." Terminating party 
> > UA-B can get call waiting signal from media on behalf on 
> UA-C (proxy 
> > connects media to UA-B) while session with UA-A is in progress.
> > 
> > Calling party UA-C might experience a ringing or even more advanced 
> > services, like announcement, music, ..., while it is 
> waiting for UA-B 
> > to finish the call.
> > 
> > Regards,
> > Dusan Mudric.
> > 
> > Call waiting announcements traditionally are played to the called 
> > party (call waiting tone).
> > 
> > How does called party B know that C is waiting?  That is the call 
> > waiting problem I first started this thread on.
> > 
> > announcements, if that's what you want, but it doesn't have 
> much to do 
> > with call waiting.
> > 
> > Brian
> > 
> with INVITE.  
> > > The media flow occurs as a result of the INVITE.  You 
> will also note 
> > > that you see 180 Ringing.
> > > 
> > > 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 think we probably should keep call waiting a local function and 
> > > not a network function.
> > > 
> > > Brian
> > > 
> 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
> > > > 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
> 
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>