Subject: RE: feature interaction, was: Re: [Sipping] draft on SIP architecturalprinciples

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 9 Mar 2005 11:32:14 -0500

Volker,

When talking about feature interactions, it is best to distinguish
between two major orthogonal concerns:
1) multiple applications all supporting a single user,
2) features supporting the caller versus features supporting the called
party.

The first is what is usually meant by feature interaction, where one or
another feature is incompatible and leads to unexpected behavior for the
user, thus a bad thing.  (Note: the classic 3-way v. call waiting
resulted from hook-flash limitations.) 

The second is really a conflict in the desires of the two users,
resulting in behavior meeting user expectations, thus a good thing.
(e.g. calling line identity restriction versus caller ID)  As you note,
this is really a matter of negotiation of the terms of communication,
which requires the means to identify/express the nature of the feature
and allow each party to accept or reject each communication attempt as
desired.

Mike

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Volker Hilt
>Sent: Tuesday, March 08, 2005 7:11 PM
>To: Vijay K. Gurbani
>Cc: SIPPING LIST; Henning Schulzrinne
>Subject: Re: feature interaction, was: Re: [Sipping] draft on 
>SIP architecturalprinciples
>
>Vijay K. Gurbani wrote:
>> Jonathan Rosenberg wrote:
>>> SIP has the interesting effect of moving some of the features into 
>>> the endpoints, and some into the network. This means that 
>you can not 
>>> easily coordinate a resolution between features that run in the two 
>>> places.
>> 
>Features could potentially live on the caller endpoint, the 
>callee endpoint, and possibly multiple application servers the 
>network. Thus, some kind of feature interaction would actually 
>need to coordinate features between a number entities.
>
>In that sense, feature interaction it is probably more a 
>problem of enabling the negotiation of features between the 
>entities in a call than defining a table that says "features X 
>doesn't work with feature Y". 
>Needless to say, that such a mechanism that covers all 
>entities in a call seems to be a very complex thing...
>
>>> Its also interesting to note that a pure endpoint model, where all 
>>> features live in the endpoints, allows the endpoint to 
>fully resolve 
>>> the feature interactions in whatever way it chooses.
>> 
>> Unless of course, a feature in the endpoint wants to co-ordinate 
>> itself with its counterpart in the network or in the far endpoint.
>> 
>Absolutely.
>
>Btw. we have done some work on coordinating features between 
>an endpoint and a network server and have submitted a paper 
>about this to Globecom. 
>Anyone who is interested, please contact me if you would like 
>to get a copy of the paper.
>
>Thanks,
>
>Volker
>-- 
>Volker Hilt                      Bell Labs / Lucent Technologies
>phone: +1 732 332 6432           101 Crawfords Corner Rd
>email: [email-masked]     Holmdel, NJ 07733
>
>_______________________________________________
>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: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 09 Mar 2005 11:16:24 -0600

> resulted from hook-flash limitations.) 

Mike:

I don't think existing literature on feature interaction makes
this distinction.  That is, features interact regardless of
whether they are executing on behalf of the same user or on
behalf of two users (caller and callee-specific features).

> (e.g. calling line identity restriction versus caller ID)  

Sometimes the behaviour meets user expectations, sometimes it
does not.  For instance, if I call 911 anonymously to report
my neighbor's house is being burglarized, my anonimity is
not preserved for calls going to 911.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: Volker Hilt <[email-masked]>
Date: Wed, 09 Mar 2005 11:54:52 -0600

Michael,

it seems that this problem can be viewed from many different angles. 
 From a technical perspective, there are a number of problem domains 
that fall into the broad category of feature interaction:
1. directing stimulus to the correct application. The example you gave 
(initiate 3-way call vs. call waiting) falls into this category.
2. negotiating support for protocol extensions needed for a feature. 
Although this might not be feature interaction in a strict sense, it 
enables the use of certain features and provides for a coordination of 
features between endpoints (and possibly proxies).
3. signaling user intention. This is to make sure that multiple features 
work together as intended by the user. For example, a user with 
music-on-hold may want to disable this feature while being in a 
conference call.

The problems that fall into the third category are probably hardest to 
solve. They seem to require some coordination between applications, 
regardless of the user they service (i.e. belong to caller or callee). 
In the example above, the music-on-hold service could reside on the 
endpoint of a conference participant and the conference itself could be 
hosted on a conference server owned by someone else. In this case, the 
endpoint still needs to detect that it is in a conference and disable 
the music-on-hold.

It would be interesting to see if the conflicts that fall into this 
category can be resolved based on information that is already available 
(e.g. check if the peer is a conference focus in the above example) or 
if there are scenarios that requires additional coordination.

Thanks,

Volker