RE: [Sipping] Re: Concreteexamplesforto draft-vanelburg-sipping-served-user-01.txt

["DRAGE, Keith \(Keith\)" <[e-mail]>]

Just to point out that while there have been discussion documents in
3GPP identifying that there are some problems to fix, this document has
not yet been discussed by 3GPP, nor has the solution contained within it
been endorsed.

There are actually a number of interrelated issues here, and this
solution would appear to make some of them worse.

Regards

Keith 

> -----Original Message-----
> From: Hans Erik van Elburg (RY/ETM) 
> [mailto:[e-mail]] 
> Sent: Friday, August 10, 2007 3:37 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: [Sipping] Re: Concreteexamplesforto 
> draft-vanelburg-sipping-served-user-01.txt
> 
> Colin,
> 
> This is extension is strictly ment as an extension on the ISC 
> interface.
> A well designed /implemented AS should not break end-to-end 
> qualities of SIP. This extension does not break that 
> end-to-end principle in any way, more then the linking in of 
> an AS over ISC does. What the draft does is fix a flaw in the 
> 3GPP architecture that is correct.
> 
> Now the addition of the discussed parameter would not break 
> the end-to-end principle either. 
> 
> Since it is the need for such parameter is not identified by 
> 3GPP I will not add it to the draft. I think that this allows 
> us to close that discussion for the moment.
> 
> Best Regards,
> /Hans Erik
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, August 10, 2007 3:50 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: [Sipping] Re: Concrete examplesforto 
> draft-vanelburg-sipping-served-user-01.txt
> 
> 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
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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