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

[Miguel Garcia <[e-mail]>]

Inline discussion.

Paul Kyzivat wrote:

> 
> 
> 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.
> 

I agree on your use case, but as I indicated during the IETF meeting we 
shouldn't discuss the strength of the business model behind these 
services. Rather, we should be discussing the technical aspecs of their 
implementation.

>> 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.

I think the service is clearly focusing on the "no reply", so you are 
registered, but don't answer. If the phone is not registered, I think 
there can't be any completion of call, unless you subscribed to the 
presence information of the callee and monitor when he becomes registered.

There is a similar service, called Call Forwarding on not-logged in (or 
something similar), which is not applicable to the PSTN, but to mobile 
and cordless networks.

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

I think is another different service.

/Miguel

> 
>     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
>>>
>>>
>>>
>>>
>>

-- 
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