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

[Paul Kyzivat <[e-mail]>]

Miguel Garcia wrote:
> An earlier version of the draft contained 4 requirements for CCBS and 
> the same 4 for CCNR, but there was only a subtle difference in both, 
> regarding what is the event at the callee that triggers the callback 
> indication. I think there is no point in separating the requirements 
> because both are, essentially the same.

Is CCNR really a useful service? It seems that the conditions under 
which it can be known to retry are all wrong for it to be useful.

Consider:
- you call me, but I am out, so you get no response.
- you invoke the CCNR feature
- I come back, and start working on my next IETF draft.
   I spend a few hours on this. But the status of my phone
   never changes, so the CCNR feature doesn't try to call me.
- its time for a conference call, so I pick up the phone
   and make a call.
- CCNR notes that my status changed, so it tries to put your
   call through to me. But I'm busy, so it fails.
- I stay on the call for a couple of hours.
- Finally I hang up and my status changes again.
- CCNR notes the status change and tries me again. This
   time it succeeds.
- You ask me where I have been, and I say I have been sitting
   by my phone for hours, waiting for your call.

A few experiences like that and you will never use CCNR again.

> With respect your question, then probably we need to define what "no 
> reply" means, in which case, I would say that "no reply" is the event 
> when the session is properly delivered to the callee never answers. Note 
> that this has nothing to do with "no logged in", or any 4xx, 5xx, or 6xx 
> responses. It just that, e.g., an INVITE is properly answered with a 1xx 
> response, but no other response is received within a period of time.

It could also be that there is no phone registered, which would result 
in a 480 response. I think that probably should also be considered a 
No-Response case.

That also suggests that a new registration is also a change in state.

	Paul

> /Miguel
> 
> Michael Hammer (mhammer) wrote:
> 
>> 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