RE: [Sipping-tispan] [CCBS/CCNR]

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

Can we separate out the CCBS case where a "busy" indication is more straigt-forward, from the CCNR?

What does "No Reply" mean?

In the PSTN case, the local loop was trusted to be there, and no reply meant not going off-hook.

In mobile systems, no replay could mean terminal is registered but refuses to answer or maybe out of radio coverage at the time.

In SIP systems, you could get a variety of non-responsive replies (anything other than a 18x?) from either the client, or perhaps from the network (a variety of 4xx, 5xx, 6xx).  

Will this feature focus on 4xx responses?
Does it matter whether it is a network problem or a UAS problem?
Will it be for normal or abnormal failures?
Where multiple networks are involved, is this more of an originating network or terminating network problem?

I suspect that because of the dynamic nature of networks and mobile nature of terminals, this queueing ought to be as close as possible to the call originator for CCNR, whereas the CCBS is as close as possible to the terminating party.  Thus, you might not want to combine the two.

Mike


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> Schmidt, Christian
> Sent: Thursday, September 01, 2005 7:46 AM
> To: Miguel Garcia; [e-mail]
> Subject: AW: [Sipping-tispan] [CCBS/CCNR]
> 
> Some additional questions / comments:
> - Are CCBS / CCNR related to a terminal or an AOR of caller/callee?
> - A more precise definition of state change is needed (e.g. 
> using BYE or INVITE for a call, avoiding busy/idle expression)
> - What is the meaning of "the callee showed activity"? Could 
> this be WWW search as well?
> - A message toward the caller about state change of the 
> callee is missing
> - Are multiple request possible for CCNR as with CCBS?
> - Is it possible for a caller to have simultaneous CCBS and 
> CCNR requests?
> - If a CCBS / CCNR request is cancelled from the network, 
> should the caller be informed?
> - The same expression as in the other requirements should be 
> used, meaning caller and callee instead of UAC and UAS. Or 
> UAC and UAS have to be explained in this context.
> Regards,
> Christian
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: [e-mail] 
> [mailto:[e-mail]] Im Auftrag von Miguel Garcia
> Gesendet: Donnerstag, 1. September 2005 11:19
> An: [e-mail]
> Betreff: [Sipping-tispan] [CCBS/CCNR]
> 
> 
> Hi:
> 
> with respect the added CCBS/CCNR requirements, I think 
> something is still missing.
> 
> - A bit more elaboration on the queue management, precisely, 
> what are the implications for the service (I think there is 
> the concept of a "timeslot" in which a user can return a 
> call, and if it doesn't happen, the user misses his turn in 
> the queue ... or somethign like that.
> - A definition of a "CCBS/CCNR request", which at the moment, 
> misleads me in the interpretation of the service. It can mean 
> two different
> things: "Please add me to the CCBS/CCNR queue of the callee", 
> or "this is a session returned as a result of an indication 
> from CCBS/CCNR".
> - Perhaps and explanation that the queue manager must be able 
> to distinguish between "call in return to CCBS/CCNR free 
> indication" from regular calls. This is related to the 
> "timeslot" concept as well.
> 
> Anyone with further information of the requirements, please comment.
> 
> /Miguel
> 
> -- 
> Miguel A. Garcia           tel:[phone]
> sip:[e-mail]
> Nokia Research Center      Helsinki, Finland
> 
> 
> _______________________________________________
> 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
> 

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