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

Miguel Garcia wrote:

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

OK.

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

This is a case where the environments are so dissimilar that we need to 
be careful to figure out what the proper analogy is.

In the case of analog phone service, if you unplug your phone and 
someone calls I think it would be treated as a no-answer case. Now if 
you switch to sip phones, and you unplug the phone, it will be a 
not-registered case. From the caller's perspective the situation is the 
same, and this is a primarily a caller facing feature. So I think this 
should probably be part of the same service. I'd be interested to hear 
other opinions.

Watching the reg event package would then be required to know when to 
try again. It would be an excellent indicator that someone is present to 
respond. (Though not a perfect indicator. It could just be a device that 
had power restored to it.)

This isn't the only case that is going to require use of the reg event. 
Use of the dialog package will also need the reg package to discover the 
UAs at which a subscription to dialog is needed.

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

I don't believe that is a similar service. It is more of a callee 
oriented service - providing the callee with a backup service when their 
primary device(s) aren't available.

	Paul

_______________________________________________
Sipping-tispan mailing list
Sipping-tispan@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-tispan