Subject: RE: [Sipping] SIP and Call Waiting.

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 17 Mar 2004 16:35:19 -0000

There was a long discussion on this a few months back on the SIPPING list - I'm sure you will find it if you look in the archives.
 
If you want to do this in an intermediate entity, I believe the way to do it was identified in that discussion, and as far as I know, required absolutely no further SIP standardisation. However you end up with a more complex capability than if you implement it in the end terminal. If you can persuade the user to pay for such a service, then well and good!
 
I would also note that even in the ISDN, there are capabilities of call waiting that are entirely implemented in the endpoint. The network only deals with the case where the access capabilities are busy, and the endpoint deals with the case where the access capabilities have sufficient capacity but the end device capabilities are busy.
 
regards
 
Keith

-----Original Message-----
From: Ramesh Ramamurthy [mailto:[email-masked]]
Sent: 17 March 2004 15:03
To: De Leo Walter
Cc: [email-masked]; '???'; Rahul Arvind Jadhav; [email-masked]
Subject: Re: [Sipping] SIP and Call Waiting.

I agree that it will be easier to control Call waiting and other features at the endpoint level.But these are value added services and service providers make money of it. So they would want to do the control on there side. The other assumption that we are making is that all endpoints have every thing implemented. That is almost always not true. 
 Moreover what we have seen in the real world is that more and more users are not educated enough to understand setting up of their endpoint to do all the endpoint feature. This is primarily due to the reason that we have started to move sip to residential lines and not just computer users. Training central office employees in all the different user interface of the endpoint will be a nightmare.If we get these features implemented on the Server side all the supported endpoints will have a same set of features implementation.. You said one thing that is more important, Your employer does not like it as he will be losing revenue if he does not provide value added services.
Moreover the other protocols, MGCP & H323 the two I know, have this implemented on the server side.

Cheers
Ramesh

De Leo Walter wrote:

Isn't it too complicated? I work for an operator and understand the motivations of implementing the service in a network-side-server (Proxy or B2BUA). But terminals can implement it more efficiently. (by the way this is my personal point of view, not my employer's :). A network-side-server should keep state by user and by terminal, and by the way, what if a call is received to a user which is registered in a terminal that is being used by other user. I feel it too complicated.

______________________________________________________ 
Walter D. De Leo 
Defensa 390 Piso 1 (C1065AAF) Buenos Aires. Argentina 
Tel: 54 11 4332-5027 Fax: 54 11 4303-5586 Int 2302 
email: [email-masked] <mailto:[email-masked]>  

-----Mensaje original----- 
De: [email-masked] <mailto:[email-masked]>  [ mailto:[email-masked] <mailto:[email-masked]> ] 
Enviado el: Miércoles, 17 de Marzo de 2004 01:50 a.m. 
Para: Rahul Arvind Jadhav; [email-masked] <mailto:[email-masked]>  
CC: [email-masked] <mailto:[email-masked]>  
Asunto: Re: [Sipping] SIP and Call Waiting. 

That is what I contributed this meeting (though failed to get consensus) 

    http://www.ietf.org/internet-drafts/draft-hwang-sipping-infomidcall-00.txt <http://www.ietf.org/internet-drafts/draft-hwang-sipping-infomidcall-00.txt>     

Since SIP application server know and can manage Subscriber's call status, the call waiting service can be provided by network-based scheme with B2BUA control.

Thank you 

Jinkyung Hwang 
KT 

----- Original Message ----- 
From: "Rahul Arvind Jadhav"  <mailto:[email-masked]> <[email-masked]> 
To:  <mailto:[email-masked]> <[email-masked]> 
Cc:  <mailto:[email-masked]> <[email-masked]> 
Sent: Wednesday, March 17, 2004 1:35 PM 
Subject: Re: [Sipping] SIP and Call Waiting. 

> But SIP endpoint is the one who also receives the call (Invite) 
> request. Moreover if SIP server controls this feature then it has to 
> maintain no of simultaneous calls permission on per user. Now if that 
> limit exceeds only than SIP server can invoke Call waiting 
> funtionality for the caller. Now the reason why SIP server will have 
> to maintain simultaneous calls permission on per user basis is that 
> ,,, a single user can receive multiple calls .... simultaneously.... 
> But thats true that SIP server can still implement call waiting 
> functionality .... but call waiting is a feature which endpoints can 
> manage in a more customized/personalized way than SIP server..... 
> 
> 
> Ramesh Ramamurthy wrote: 
> 
> > Hi all, 
> >   how do we do call waiting indication using SIP? The SIP Server 
> > needs 
> > to controll this feature and we cannot let the Endpoint manage this 
> > service for us. 
> > 
> > Thanks in advance 
> > Ramesh 
> 
> 
> -- 
> Rahul Arvind Jadhav 
> Tech Lead, NetYantra India Pvt. Ltd, India 
> www.netyantra.com <http://www.netyantra.com>  
> 
> 
> 
> _______________________________________________ 
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping <https://www1.ietf.org/mailman/listinfo/sipping>  
> This list is for NEW development of the application of SIP Use 
> [email-masked] <mailto:[email-masked]>  for questions on current sip Use 
> [email-masked] <mailto:[email-masked]>  for new developments of core SIP 
> J*ix&j)b      bm荶? 0汭'~ffX)†"见8bX+DYׯzZ)  ayi'*'跡=K*b霚^       %఺fi素n~ʹ-w.駮ȩRǬ+ࠁ+z਍(}瑨+y"

---

From: Alex Kurganov <[email-masked]>
Date: Wed, 17 Mar 2004 10:39:08 -0600

Actually, it is somewhat limiting to consider the duopoly of endpoints (user
devices) and the network when discussing the evolution of SIP. There is a
third type of entity one must consider and that is network application
platform.  So the choice is not binary: either smart endpoint vs dumb
network or dumb endpoint vs smart network. We should really consider a set
of endpoints some of which are smart and some are dumb vs a set of
federated, collaborating network entities some of which are smart and some
are dumb. Not all the network entities participating in call treatment will
be operated by a single service provider.  Specifically, Call Waiting is for
a smart network entity to deliver in collaboration with a smart endpoint. In
reality, Call Waiting delivered by a smart endpoint can be different from
Call Waiting delivered by a dumb endpoint. 
E.g. a dumb endpoint can deliver whisper call waiting entirely via the
network platform, while smart endpoint can deliver textual, video message
about call waiting in collaboration with the network platform.  Still, the
smart endpoint can deliver whisper call waiting with the caller name
announcement if necessary, e.g. for a person with disability.

Thanks,
Alex 

-----Original Message-----
From: David C. Robbins [mailto:[email-masked]]
Sent: Wednesday, March 17, 2004 9:55 AM
To: [email-masked]
Subject: Re: [Sipping] SIP and Call Waiting.

Time and time again this sort of thing comes up in discussions of 
SIP.  The traditional telecom provider insists on seeing things from 
the legacy point of view, and tries to fit the square PSTN peg into 
the round SIP hole.  (I work for a traditional telecom provider, so I 
know whereof I speak.  My views are my own, and may or may not be 
similar to the views of others in my industry.)

Folks, if you want the network to control all services to a dumb 
endpoint, DON'T USE SIP!  MGCP and H.248 were designed to support 
exactly this model, so use them.  SIP IS DIFFERENT!

SIP assumes that the UA manages the device, or whatever exactly is on 
the user's side of the UA.  SIP makes no assumptions about the 
device, nor should it.  The whole point of SIP is to exploit the 
power of the UA at the endpoint to manage the user's side of the 
communication in whatever way is most appropriate.  In the example at 
hand, the most effective way to handle Call Waiting in SIP is to 
allow the UA to deal with it.

If and only if the service provider owns and/or manages the UA, the 
service provider can manage Call Waiting and similar services.  This 
could be a reasonable model for deployment of SIP in some 
circumstances.  If the service provider does not own or manage the 
UA, then the UA can provide Call Waiting whether the service provider 
wants it to or not.

Yes, this breaks the legacy service model, but so what?  SIP IS 
DIFFERENT.  A SIP service provider will find other, and better, ways 
of making money than by controlling and charging for services that a 
UA can do on its own.

SIP IS DIFFERENT.  It breaks the legacy PSTN model in various and 
interesting, and ultimately beneficial, ways.

>I agree that it will be easier to control Call waiting and other 
>features at the endpoint level.But these are value added services 
>and service providers make money of it. So they would want to do the 
>control on there side. The other assumption that we are making is 
>that all endpoints have every thing implemented. That is almost 
>always not true.
>  Moreover what we have seen in the real world is that more and more 
>users are not educated enough to understand setting up of their 
>endpoint to do all the endpoint feature. This is primarily due to 
>the reason that we have started to move sip to residential lines and 
>not just computer users. Training central office employees in all 
>the different user interface of the endpoint will be a nightmare.If 
>we get these features implemented on the Server side all the 
>supported endpoints will have a same set of features 
>implementation.. You said one thing that is more important, Your 
>employer does not like it as he will be losing revenue if he does 
>not provide value added services.
...snip...
-- 
-------------------------------------------------------------------------
Dave Robbins                                         Verizon Laboratories
E-mail: [email-masked]    40 Sylvan Rd., Waltham, MA 02451-1128

_______________________________________________
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