Subject: RE: [Sipping] Requirements for the identification of IMScommunication services.

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Thu, 13 Jul 2006 10:09:01 +0200

Hi David, All,

Its always trickly to get a common terminology - I don't think that
having something like character recognition is a communication service;
but more a capability that we could use within a communication service.

BTW - what is flawed about the hirearchical concept - I have trouble to
see what is new with it actually.  

BR,

..//Steve 

-----Original Message-----
From: David R Oran [mailto:[email-masked]] 
Sent: Wednesday, July 12, 2006 4:34 PM
To: Sipping WG
Subject: Re: [Sipping] Requirements for the identification of
IMScommunication services.

On Jul 12, 2006, at 9:40 AM, Salvatore Loreto (JO/LMF) wrote:

> Hi Dean,
>
> just to clarify
>
> the draft at present doesn't claim that it is never possible to deploy

> more than one application in a session, it only says all the different

> applications should be based on the same Communication Service (that 
> mean on the same service logic and media handling). All the different 
> applications are deployed in a session must use the same service 
> logic.
>
Really? the MRCPv2 server doing hotword recognition on a media stream
that is also being sent to the voicemail server has to use the same
service logic as the voicemail server?

The idea that applications are a hirearchical containment of a
"communciation service" is what I (and others) find to be a flawed idea.

Dave Oran.

>
> /sal
>
>
>
>
> On Wed, 2006-07-12 at 01:50 -0500, Dean Willis wrote:
>> On Jun 29, 2006, at 9:17 PM, [email-masked] wrote:
>>
>>>
>>>     "Any dialog with the UA passes through, and is mediated by, an
>>>     application which runs on a server.  Different dialogs may be 
>>> mediated
>>>     by different applications, but each dialog is handled by one
>>>     application.  Hence, all incoming dialogs must be first routed 
>>> to the
>>>     proper application, which will then establish communication with

>>> the
>>>     specified UA.  Each application can provide additional services 
>>> beyond
>>>     what is implemented in the UA.  Hence, incoming dialogs must be
>>>     accurately classified as to the services they will need, so that
>>>     they can be routed to a suitable application."
>>
>> Ah, you've hit (and continued to flog) my worry exactly.
>>
>> You say "each dialog is handled by one application". That's the part 
>> that I think is fundamentally wrong. Even in an IMS "service model"
>> as you have described, each dialog would be handled by zero or more 
>> applications, as determined by a combination of:
>>
>> 1) If we have them, service identifiers.
>> 2) "Triggers"  defined in the subscriber record (from HSS) driving S-

>> CSCF routing decisions
>> 3) Caller preferences
>> 4) Callee capabilities
>> 5) Route headers
>> 5) Request URI parameters
>>
>> and all not necessarily in that order.
>>
>> The key point here is "zero or more applications".  The fundamental 
>> promise of the IMS service architecture is that applications are 
>> additive. That is, it is possible to deploy more than one on a call.
>> But the current identification draft seems to think of them as 
>> exclusive, such that it is never possible to deploy more than one.
>>
>> --
>> Dean
>>
>>
>> _______________________________________________
>> 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

_______________________________________________
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