RE: [Sipping] Re: Concrete examples forto draft-vanelburg-sipping-served-user-01.txt

[<[e-mail]>]

Miguel,

But by submitting such a draft to IETF you make it a SIPPING issue. In
fact by allowing such a parameter, SIPPING in my view would jeopardize
the end-to-end principle. The parameter would possibly adapt or modify
service behavior at SIP Proxy level (S-CSCF). 

To be frank, this parameter looks to me as badly conceived as the
original 3GPP draft on the 'Communication Services Identifier'. My
problem with these sorts of activities is twofold. First is that 3GPP
thinks too much in the old circuit-switched paradigms. As representative
of a converged telco I do not see the need you refer to (as a neither do
for the original 3GPP draft on the 'communication service identifier').
Although, I admit Call Forwarding would be implemented differently if
you would do it using SIP, why not just do that instead of shoe-horning
old solutions into new architectures.

Secondly, the proposed parameter as well as the mentioned 'communication
service identifier' are attempts to correct for bad architectural
designs and implementations. As listed earlier in these thread SIP
intrinsically has the capabilities to deal with the use cases you refer
to. Just use them! 

Colin Pons
Senior Architect
WO Innovation Management
KPN

-----Oorspronkelijk bericht-----
Van: Miguel Garcia [mailto:[e-mail]] 
Verzonden: vrijdag 10 augustus 2007 11:55
Aan: Pons, C.A. (Colin) (W O IM Service Innovatie)
CC: [e-mail]; [e-mail]
Onderwerp: Re: [Sipping] Re: Concrete examples forto
draft-vanelburg-sipping-served-user-01.txt

Hi Colin:

When I wrote "bounces back" I was referring when the S-CSCF is getting a

request from the AS, after the same S-CSCF previously forwarded to the
AS.

So, if you say the S-CSCF shouldn't interrupt the FC evaluation, then 
you may get into trouble as well. For example, if there are services 
that will be invoked after, e.g., a call forwarding. Assume a service 
reads the Request-URI or does some other action on a user who already 
diverted the session.

I agree service interaction is a complex issue. Because of this, I think

the protocol needs to signal those cases where it does not make sense 
with the FC evaluation.

In any case, I would expect that this is further discussed and agreed in

3GPP and the draft reflects 3GPP's needs. The IETF shouldn't take a 
position on the need of the parameter. Perhaps we got into the 
discussion when we tried to understand all the consequences, but as I 
said, it is not the SIPPING mission.

/Miguel

[e-mail] wrote:
> Hi Miguel
> 
> I am proposing that the S-CSCF does as little as possible other than
> just sioimply routing SIP messages.
> 
> In case a SIP request bounces, i.e. the request could not be processed
> properly, the next logical thing for the S-CSCF to do is to pass this
on
> to the UAC. Hence abort any iFC evaluation.
> 
> In the use case you referred to the App Server has 'changed'
> dramatically the SIP session it makes no sense for S-CSCF to continue
> iFC evaluation. I would think such a dramatic change would need to be
> signaled (and agreed) with the UAC anyhow. So I do not see why a
> parameter should be included to terminate iFC evaluation. The only
> relevant case I can think of is the PSTN emulation service were the
UAC
> is 'dumb' (old black telephony is re-used) and would not be informed
of
> such dramatic change because an application more or less represents
such
> an UAC.
> 
> My personal opinion is that SIP (and hence IMS) are not voice and call
> control centric. And we should not recreate the old telephony services
> in IMS where they make less (if any at all) sense. In SIP the service
is
> created between user agents and anty significant change should be
> negotiated between these user agents. I strongly feel that the
parameter
> you propose very well could break that model.
>  
> Colin Pons
> Senior Architect
> WSO Innovation Management
> 
> 
> -----Oorspronkelijk bericht-----
> Van: Miguel Garcia [mailto:[e-mail]] 
> Verzonden: donderdag 9 augustus 2007 16:44
> Aan: Pons, C.A. (Colin) (W O IM Service Innovatie)
> CC: [e-mail]; [e-mail]
> Onderwerp: Re: [Sipping] Re: Concrete examples forto
> draft-vanelburg-sipping-served-user-01.txt
> 
> Hi Colin:
> 
> I didn't understand what you are proposing in the absence of the 
> parameter. Are you proposing that:
> 
> a) The S-CSCF always aborts Filter Criteria evaluation after the
request
> 
> bounces back to the S-CSCF.
> 
> b) The S-CSCF never aborts the FC evaluation after getting the request
> back.
> 
> c) The behavior of the S-CSCF is unspecified.
> 
> Thanks,
> 
>      Miguel
> 
> [e-mail] wrote:
>> Miguel, Has Erik,
>>
>>
>> I foresee large interoperability issues with the proposed parameter
> with
>> which an AS could control continuation of iFC processing. You state
it
>> is needed to deal with service interaction issues. Service
interaction
>> is a voice and call control centric issue, which is well known in
PSTN
>> (circuit switched) Intelligent Networks, and deals with the
> coordinated
>> execution of potentially conflicting call control -related services. 
>> But IMS is not a voice and call control centric architecture, instead
> we
>> require transparancy IMS in simply routing SIP messages. I believe
SIP
>> has intrinsic features which may have solved or at least mitigated
>> largely most 'classical service interaction' issues.  
>>
>> - IMS is a multimedia network which will multiply the means to
>> communicate between users. This may impact the need for call
> management
>> services.
>> - SIP forking permits the network to search for a user on various
>> devices. This will make 'traditional' call control less relevant than
>> before. Also, it would provide a better solution to the traditional
>> supplementary service use cases such as call forwarding.
>> - Presence will permit more intelligent call management services at
> UAC
>> level, and will certainly reduce the number of applications within
one
>> SIP transaction, dialogue or session and the need for supporting
> service
>> interaction management between them. 
>> - IMS applications can more easily interact with users, possibly
> asking
>> them (caller, callee) how they wish to handle a call. This is in
>> contrast with circuit-switched networks, which have poor user
> interfaces
>> and therefore need to essentially work autonomously.
>> - The iFC allows routing of SIP messages to applications (servers),
> but
>> not to services. In circuit-switched the service was created in the
>> network entities. In SIP the 'service' is created in the UAC not in
> the
>> application server. This largely reduces the need for service
>> interaction management at IMS or application level.
>>
>> The proposed parameter would make the faily simple iFC functionality
>> much more complex. Also this parameter would suggest that 'the
> network'
>> is in control and the Application chaining is done at 'network'
level.
>> This could however also be done at UAC level. Interactions could than
> be
>> handled at UAC or as suggested above by explicitly requesting the
user
>> on how to proceed. 
>>
>> Hence,I do not see a need for your proposed parameter.
>>
>>
>> Colin Pons
>> Senior Architect
>> WSO Innovation Management
>> KPN
>>
>> -----Oorspronkelijk bericht-----
>> Van: Miguel Garcia [mailto:[e-mail]] 
>> Verzonden: woensdag 8 augustus 2007 8:19
>> Aan: Jeroen van Bemmel
>> CC: sipping
>> Onderwerp: Re: [Sipping] Re: Concrete examples forto
>> draft-vanelburg-sipping-served-user-01.txt
>>
>> Jeroen, Hans Erik, inline comments:
>>
>> Jeroen van Bemmel wrote:
>>> Hans Erik,
>>>  
>>> The way current IMS implementations deal with the case you mention
is
> 
>>> (to my knowledge) as follows: they look for a Diversion header in
the
> 
>>> INVITE (coming from the AS), if it is present it overrides the 
>>> P-Asserted-Identity. This is not a standard procedure (yet) though,
>> AFAIK
>>
>> The Diversion header does not exist. At least it is not documented 
>> anywhere, so it is a sign of non-existence.
>>
>>>  
>>> Is this the only concrete service scenario, or are there more?
>>>  
>>> Note that there are more aspects to diversion that are not well
>> defined 
>>> (for example: should the ICID remain the same or be generated anew?)
>>>  
>>> Regarding adding a parameter to give an AS control over aborting iFC

>>> processing: the AS does not know what other services follow, so how
>> can 
>>> it decide whether or not continuing makes sense? I think such a 
>>> parameter would add more complexity and interop issues than it would
>> solve
>>
>> There are two aspects here. One is whether the addition of such 
>> parameter represents an interoperability problem or not. I believe it

>> doesn't.
>>
>> The other aspect is whether it makes sense and solves something. This
> is
>> a complex aspect, because it is going to the heart of the service 
>> interaction. Here we have an Application Server indicating that it
has
> 
>> executed a service, and on doing so, the result has been such a
> dramatic
>> change that it makes no sense for the S-CSCF to continue executing
the
> 
>> filter criteria. The S-CSCF receives this hint and has to take
another
> 
>> decision: does it make sense to follow the hint? It may make sense to

>> stop the filter criteria evaluation, because the remaining services
> are 
>> bogus after the execution of the first service, or there might be 
>> services that still need to be executed after all. I reckon this is a

>> complex issue, and I am willing to hear opinions.
>>
>> Without the parameter to give the hint, the S-CSCF will always have
to
> 
>> either abort the FC evaluation or continue, but it does not have any 
>> input to take a decision. With the parameter, it has input from the
> AS, 
>> which can be overruled of course.
>>
>> /Miguel
>>
>>
>>
>>>  
>>> Regards,
>>> Jeroen
>>>
>>>     ----- Original Message -----
>>>     *From:* Hans Erik van Elburg (RY/ETM)
>>>     <mailto:[e-mail]>
>>>     *To:* Jeroen van Bemmel <mailto:[e-mail]>
>>>     *Cc:* sipping <mailto:[e-mail]>
>>>     *Sent:* Friday, August 03, 2007 10:35 AM
>>>     *Subject:* RE: Concrete examples for to
>>>     draft-vanelburg-sipping-served-user-01.txt
>>>
>>>     Hi Jeroen,
>>>      
>>>     The concrete example that triggered this is the 3GPP
> supplementary
>>>     service Communication Diversion. You would expect that when a
> call
>>>     is forwarded that the forwarded leg is originated by the
>> forwarding
>>>     user and hence is treated as an originating leg also to be able
> to
>>>     provide originating services for the forwarding user. That is
>>>     scenario 3.3. It turned out not even to be possible to do that
in
>>>     IMS using the current procedures. This draft provides part of
the
>>>     solution for that. The other scenarios are added to show that
>>>     solving the overloading problem, also allows other scenarios.
>>>      
>>>     Regarding service interaction: That is always an issue that need
>> to
>>>     be looked at the specific cases. If one as an application
> deployer
>>>     chooses to allow continuation of iFC processing then all the
>>>     additional interaction cases have to be considered.
>>>      
>>>     I think the suggestion from Miguel to add a parameter whereby
>>>     the applications can control whether iFC processing continues or
>> not
>>>     is a useful addition in this persective as well.
>>>      
>>>     Best Regards,
>>>      
>>>     /Hans Erik  
>>>      
>>>
>
------------------------------------------------------------------------
>>>     *From:* Jeroen van Bemmel [mailto:[e-mail]]
>>>     *Sent:* Thursday, July 19, 2007 10:06 PM
>>>     *To:* Hans Erik van Elburg (RY/ETM)
>>>     *Cc:* sipping
>>>     *Subject:* Concrete examples for to
>>>     draft-vanelburg-sipping-served-user-01.txt
>>>
>>>     Hi Hans Erik,
>>>      
>>>     Could you provide some more concrete examples of the scenarios
>>>     described in draft-vanelburg-sipping-served-user-01.txt section
> 3?
>>>      
>>>     For example, 3.2 currently states "Imagine a service scenario
>> where
>>>     a user B has a terminating service that diverts the call to a
>>>     different destination, but it is required that subsequent
>>>     terminating services for the same user are still executed.". I'm
>>>     having trouble imagining such a scenario, in particular what
kind
>> of
>>>     subsequent terminating services you have in mind here. On the
>> other
>>>     side, I can easily imagine examples where the service
interaction
>>>     that results from continuening iFC execution would be
undesirable
>>>     (for example: diversion followed by anonymous call rejection)
>>>      
>>>     Same question for 3.3 and 3.4. There appear to be several
> implicit
>>>     reasons which the reader is expected to know, from which
>> apparently
>>>     these requirements follow.
>>>      
>>>     Regards,
>>>     Jeroen
>>>      
>>>
>>>
>>>
>
------------------------------------------------------------------------
>>> _______________________________________________
>>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>> This list is for NEW development of the application of SIP
>>> Use [e-mail] for questions on current sip
>>> Use [e-mail] for new developments of core SIP
> 

-- 
Miguel A. Garcia           tel:[phone]
Nokia Siemens Networks     Espoo, Finland



_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP