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

From: De Leo Walter <[email-masked]>
Date: Wed, 17 Mar 2004 09:56:26 -0300

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]

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] 
Enviado el: Miércoles, 17 de Marzo de 2004 01:50 a.m.
Para: Rahul Arvind Jadhav; [email-masked]
CC: [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

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" <[email-masked]>
To: <[email-masked]>
Cc: <[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
> 
> 
> 
> _______________________________________________
> 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
> J*ix&j)b	bm荶?0汭'~ffX)†"见8bX+DYׯzZ)	ayi'*'跡=K*b霚^
%఺fi素n~ʹ-w.駮ȩRǬ+ࠁ+z਍(}瑨+y"

---

From: Ramesh Ramamurthy <[email-masked]>
Date: Wed, 17 Mar 2004 08:02:33 -0700

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

-----Mensaje original-----

CC: [email-masked]

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

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

Cc: <[email-masked]>

> J*ix&j)b      bm荶? 0汭'~ffX)†"见8bX+DYׯzZ)  ayi'*'跡=K*b霚^       %఺fi素n~ʹ-w.駮ȩRǬ+ࠁ+z਍(}瑨+y"

---

From: "David C. Robbins" <[email-masked]>
Date: Wed, 17 Mar 2004 10:54:58 -0500

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.

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

---

From: Ramesh Ramamurthy <[email-masked]>
Date: Wed, 17 Mar 2004 10:17:42 -0700

The issue has been misunderstood. The question is not about doing Call 
waiting  but only controlling these features from the server side. If 
there is a way to controll the entire feature operation,  it will be 
better but control of the feature is more important than actually doing 
it. All these feature when we intract with the PSTN takes up expensive 
access lines. We need to control who connects to the backbone and who 
does not. My worry is  is more a control of the access lines than 
controll of the endpoint from the business stand point.

Cheers
Ramesh

David C. Robbins wrote:

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

---

From: "David C. Robbins" <[email-masked]>
Date: Wed, 17 Mar 2004 12:46:48 -0500

What you're most interested in is a policy implemented by the server. 
The server can decide whether to send an INVITE to the UA.  The 
policy may be to not send an INVITE to a UA if it knows that the UA 
has an active dialog, or for other reasons (e.g., its knowledge about 
current network utilization).

This is quite different from the notion of controlling a feature such 
as Call Waiting.  For Call Waiting and other features, it makes no 
sense to me to think of a network server controlling the feature.  It 
does make sense to think in terms of policy regarding whether to 
offer a call to a UA.  And it makes sense to think in those policy 
terms without linking that thinking to specific features that might 
or might not be implemented in the UA.

I don't see why it would be better for a network server to control 
the entire feature operation.  Isn't it more appropriate in a SIP 
world to think of the network doing what networks do best and the UA 
doing what UAs do best?  There is interaction between the behavior of 
the UA and the behavior of the network, but you just can't assume 
that the network can reach inside of the UA to control what the UA 
does, nor can you assume that the UA is managing any particular kind 
of device (or indeed any device at all).  You can only design your 
network service to interact with the UA in terms of the applicable 
RFCs.  You can demand that the UA conform to a specific set of RFCs, 
and refuse to interoperate with UAs that don't meet your 
requirements.  That's a network policy decision, and perfectly 
reasonable.

I don't think we need to beat this to death.  My point is mainly to 
suggest that we let ourselves be guided by the device-agnostic nature 
of SIP, and let go of some of our PSTN-inspired thinking about where 
and how services are implemented.  As I said in my previous message, 
SIP IS DIFFERENT!  The key difference, for the purpose of this little 
discussion, is that what we view in the PSTN as a simple feature is 
really a combination of a network-policy decision and a user-device 
capability.  In a SIP world, we need to separate these items.

At 10:17 AM -0700 3/17/04, Ramesh Ramamurthy wrote:
>The issue has been misunderstood. The question is not about doing 
>Call waiting  but only controlling these features from the server 
>side. If there is a way to controll the entire feature operation, 
>it will be better but control of the feature is more important than 
>actually doing it. All these feature when we intract with the PSTN 
>takes up expensive access lines. We need to control who connects to 
>the backbone and who does not. My worry is  is more a control of the 
>access lines than controll of the endpoint from the business stand 
>point.
...snip...

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Mar 2004 18:14:48 -0500

Ramesh Ramamurthy wrote:

> service providers make money of it. So they would want to do the control 
> on there side. 

Changes in technology drive changes in the services offered by providers 
and the value they bring. In a world where the analog-based network 
access made it hard to actually have two calls at once, providing a call 
waiting feature in the network was both appropriate and of value to the 
customer.

In a SIP-based network, the technical assumptions that held in the PSTN 
no longer apply, and in particular, the ease with which one can signal 
an incoming call when one is in progress, make the SIP design the 
appropriate one. Does that change the value equation compared to the 
PSTN? Yes. I think that SIP brings a lot of other capabilities to the 
table which make up for the fact that consumers will find it cheaper to 
buy phones that do call waiting locally, rather than pay for it from 
their provider.

Indeed, I might even argue that SIP has a way to do functional signaling 
for call waiting. When a call arrives, the network sends a message to 
the phone telling it who is calling, what they want, etc. THe user can 
send a message back to tell the network to pass the call onto the phone. 
It just so happens that, in SIP, these two messages are INVITE and 200 
OK respectively.

The other assumption that we are making is that all
> endpoints have every thing implemented. That is almost always not true.
> users are not educated enough to understand setting up of their endpoint 
> to do all the endpoint feature.

This makes no sense to me. What is required to set this up? I think it 
takes more work on the part of the user to set it up in the 
network-centralized (i.e., mgcp) case, since the feature must be 
explicitly provisioned.

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

Which is also a bad thing, IMHO.

In the original PSTN, where all devices were equal, and there was only 
one service (telephony), this was a reasonable design choice.

In a SIP network, where there is wide variation in the types of devices 
and the services and features they can signal (presence, IM, voice, 
video, web integration, etc.), uniformity of service definition and 
offering makes no sense. In such a network, you ideally put features on 
the endpoints when you can, since they know best what their capabilities 
are. Furthermore, even when doing stimulus signaling for network 
resident features, you need to have a negotiation framework (see 
draft-ietf-sipping-app-interaction-framework) to deal with variation in 
devices.

Perhaps you see this variation as a bug; I see it as a key feature. If 
you think its a bug I suggest that MGCP is a better match for the 
problems you want to solve.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Ramesh Ramamurthy <[email-masked]>
Date: Wed, 17 Mar 2004 16:45:03 -0700

Thanks to you and David Robbins, I have bought into the fact that it is 
better to let the Endpoint to handle the features. My primary concern 
was with regard to controlling the usage of the feature than doing the 
feature itself. I was looking for a draft that has the proper call flow 
on how to control Call waiting and other Call features from the server. 
As these features have resource implication in a statefull SIP server.

Cheers
Ramesh

Jonathan Rosenberg wrote:

>> control on there side. 
> Changes in technology drive changes in the services offered by 
> providers and the value they bring. In a world where the analog-based 
> network access made it hard to actually have two calls at once, 
> providing a call waiting feature in the network was both appropriate 
> and of value to the customer.
>
> In a SIP-based network, the technical assumptions that held in the 
> PSTN no longer apply, and in particular, the ease with which one can 
> signal an incoming call when one is in progress, make the SIP design 
> the appropriate one. Does that change the value equation compared to 
> the PSTN? Yes. I think that SIP brings a lot of other capabilities to 
> the table which make up for the fact that consumers will find it 
> cheaper to buy phones that do call waiting locally, rather than pay 
> for it from their provider.
>
> Indeed, I might even argue that SIP has a way to do functional 
> signaling for call waiting. When a call arrives, the network sends a 
> message to the phone telling it who is calling, what they want, etc. 
> THe user can send a message back to tell the network to pass the call 
> onto the phone. It just so happens that, in SIP, these two messages 
> are INVITE and 200 OK respectively.
>
>
>
>
>> endpoint to do all the endpoint feature.
>
>
>> we have started to move sip to residential lines and not just 
>> computer users. Training central office employees in all the 
>> endpoints will have a same set of features implementation..
>
>
> In a SIP network, where there is wide variation in the types of 
> devices and the services and features they can signal (presence, IM, 
> voice, video, web integration, etc.), uniformity of service definition 
> and offering makes no sense. In such a network, you ideally put 
> features on the endpoints when you can, since they know best what 
> their capabilities are. Furthermore, even when doing stimulus 
> signaling for network resident features, you need to have a 
> negotiation framework (see 
> draft-ietf-sipping-app-interaction-framework) to deal with variation 
> in devices.
>