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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 9 Mar 2005 13:29:21 -0500

Volker,

I don't see much difference between 2 and 3, but agree with the needs.

BTW, if a user sees an "isfocus" it should then invoke the "No Music on
Hold (NMOH)" feature.  
Similarly, if a MoH feature sees in incoming call with an "isfocus" it
should reject the call.
Also, if an entity identified is self as "MoH" then a conference could
refuse refers/joins to it and otherwise reject or release such a
session.

Given that the conference has identified itself correctly, the other
side should behave.

Mike

>-----Original Message-----
>From: Volker Hilt [mailto:[email-masked]] 
>Sent: Wednesday, March 09, 2005 12:55 PM
>To: Michael Hammer (mhammer)
>Cc: Vijay K. Gurbani; SIPPING LIST; Henning Schulzrinne
>Subject: Re: feature interaction, was: Re: [Sipping] draft on 
>SIP architecturalprinciples
>
>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
>
>
>
>Michael Hammer (mhammer) wrote:
> > 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
> >
>

_______________________________________________
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: Volker Hilt <[email-masked]>
Date: Wed, 09 Mar 2005 13:41:46 -0600

> I don't see much difference between 2 and 3, but agree with the needs.
What I had in mind with 2) are features that require support for a 
protocol extension from a remote entity. But this is probably a little 
off topic for feature interaction.

> refuse refers/joins to it and otherwise reject or release such a
Absolutely.

> Given that the conference has identified itself correctly, the other
In many cases, feature interaction conflicts can probably be resolved 
locally in applications just by using the information contained in the 
signaling messages in a reasonable way. This of course requires 
application designers to think about possible interactions with other 
applications and to go through a number of use cases. Also, I'm still 
curious if all conflicts can be resolved that way or if there are 
examples where additional information or coordination is needed.

Volker

---

From: Andre Beck <[email-masked]>
Date: Wed, 09 Mar 2005 17:27:36 -0500

I think there are other feature interaction scenarios whose resolution 
requires manual intervention, i.e. someone needs to sit down, look at 
the behavior of the involved applications, and determine the best 
resolution strategy for a particular conflict. In the past, this job was 
performed by the entity that was in control of the features--the service 
provider.
However, the fact that in SIP features can be provided both by the 
network and the endpoint complicates this job, particularly because the 
resolution of a conflict often involves the suppression of a feature.
If we assume that the service provider continues to perform the conflict 
resolution function, then the network must somehow be able to discover 
and coordinate endpoint-provided services. If we let the endpoint handle 
the conflict resolution, then the endpoint must somehow be able to 
discover and coordinate network-provided services.

Andre

Volker Hilt wrote:

>> Hold (NMOH)" feature.  Similarly, if a MoH feature sees in incoming 
>> call with an "isfocus" it
>> should reject the call.
>>> From: Volker Hilt [mailto:[email-masked]] Sent: Wednesday, 
>>> March 09, 2005 12:55 PM
>>> Subject: Re: feature interaction, was: Re: [Sipping] draft on SIP 
>>> architecturalprinciples
>>>
>>> Michael,
>>>
>>> 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.
>>> 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
>>>
>>>
>>>

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 09 Mar 2005 20:01:40 -0500

> Given that the conference has identified itself correctly, the other

How does this work in cases where the conference bridge is located in 
the PSTN and the call forwarded to the participant with MoH via a SIP 
gateway?

-Markus