RE: AW: [Sipping-tispan] TISPAN requirements, first requiements

["Michael Hammer \(mhammer\)" <[e-mail]>]

Christian,

Concerning the "priority" of CCBS users.  Given that in SIP it could be possible that multiple calls can be presented to the user at the same time, I do not think that the caller's service should over-ride the called party's prerogative to choose which call to answer.  I believe that should be an acceptable variation.  Otherwise, the user will answer/put on hold/hangup, not the best experience for the caller.

It might also be possible to give any other calls in the same time frame busy call treatment, but I think that would be a step backwards (constraining to the limitations of the PSTN) for SIP users.

Mike


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> Schmidt, Christian
> Sent: Wednesday, August 24, 2005 6:54 AM
> To: Miguel Garcia
> Cc: [e-mail]; Alexeitsev, D
> Subject: AW: AW: [Sipping-tispan] TISPAN requirements, first 
> requiements
> 
> Hi Miguel,
> 
> some more comments inline.
> 
> Best Regards,
> Christian Schmidt
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Miguel Garcia [mailto:[e-mail]]
> Gesendet: Mittwoch, 24. August 2005 12:02
> An: Schmidt, Christian
> Cc: [e-mail]; Alexeitsev, D; [e-mail]
> Betreff: Re: AW: [Sipping-tispan] TISPAN requirements, first 
> requiements
> 
> 
> Hi Christian:
> 
> Thansk for reading this document. Inline comments.
> 
> Schmidt, Christian wrote:
> 
> > Some comments:
> > 
> > 2. Overview
> > "small variations are expected when compared with the 
> equivalent ISTD/PSTN supplementary services"
> > Can you provide an example for such a variation?
> 
> I'll give you one example that came to my mind. Many of the 
> supplementary services in PSTN/ISDN assume that there is only one 
> line/terminal per user, so if the user is already busy from that 
> terminal/line, he won't be able to take a new call, thus, 
> services such 
> as Call Forwarding on Busy will apply.
> 
> This is not exactly the same in SIP, where a user can be 
> using several 
> terminal simultaneously, and there isn't a concept of a "line" or 
> "channel". Therefore, the fact that a user is busy from one terminal 
> does not necessarily imply anything with respect his busy condition. 
> This is a change with respect the PSTN/ISDN services.
> 
> Christian: This information should be added somehow, perhaps:
> "small variations are expected in some services (for example 
> CCBS, because of different busy definitions) are expected.....".
> 
> > 
> > 3.1 General Requirements
> > "the user should receive the service without any degradation"
> > This seems to be somehow in contradiction with the 
> "variation" passage in the overview section. Or do you mean 
> variation as addon only?
> 
> The requirement means that, if one user is in the NGN and the 
> other in 
> the PSTN, the NGN user should not receive a degradation with 
> respect the 
> NGN simulation service (read the "native network" in the text). 
> Similarly, the PSTN user should not receive a degradation 
> with respect 
> the PSTN/ISDN supplementary service provided in the PSTN.
> 
> I think this isn't in contradiction with the "variation" passage.
> 
> Christian: OK, now I understand. But I am still a little 
> concerned about the requirement. For example in case of CCBS. 
> When the called PSTN subscriber get free, the CCBS call will 
> be presented to the called subscriber with priority, to avoid 
> other terminating calls to come first. How do you want to 
> achieve this with SIP? Without this feature, this is a kind 
> of service degradation for CCBS. Perhaps, you should modify 
> to "without significant degradation".
> 
> 
> > There should also be a general requirement included:
> > GEN-3: "SIP UA not providing this simulation service should 
> not be influenced, they are simple not able to provide the 
> related service."
> 
> I agree with the idea, but I don't think it is a requirement, but a 
> property or expectation of the system. But I can add some 
> clarification 
> text indicating that we don't expect SIP UAs that do not 
> implement the 
> services to provide the service to the user.
> 
> Christian: It is a requirement for the selection of a proper 
> solution. Do not select a solution which is not backwards 
> compatible. And the statement
> should avoid discussions, that with introduction of this 
> services, all SIP UAs would have to be changed.
> 
> Best Regards
> Christian Schmidt
> 
> 
> _______________________________________________
> Sipping-tispan mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 

_______________________________________________
Sipping-tispan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-tispan