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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 1 Sep 2005 14:18:42 -0400

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Schmidt, Christian
> Sent: Thursday, September 01, 2005 7:46 AM
> To: Miguel Garcia; [email-masked]
> 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: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Miguel Garcia
> Gesendet: Donnerstag, 1. September 2005 11:19
> An: [email-masked]
> 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:+358-50-4804586
> sip:[email-masked]
> Nokia Research Center      Helsinki, Finland
> 
> 
> _______________________________________________
> Sipping-tispan mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 
> _______________________________________________
> Sipping-tispan mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 

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

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 02 Sep 2005 14:59:16 +0300

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.

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.

/Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Sep 2005 09:35:06 -0400

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

> 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

>> 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). 
>> 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
>>
>>
>>
>>> [mailto:[email-masked]] On Behalf Of Schmidt, Christian
>>> - 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
>>> - 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
>>>
>>>
>>>
>>> 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.
>>> 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.
>>>

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 05 Sep 2005 09:33:52 +0300

Inline discussion.

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

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

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

>>> the network (a variety of 4xx, 5xx, 6xx). Will this feature focus on 
>>> 4xx responses?
>>> 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
>>>
>>>
>>>
>>>> - A more precise definition of state change is needed (e.g. using 
>>>> BYE or INVITE for a call, avoiding busy/idle expression)
>>>> meaning caller and callee instead of UAC and UAS. Or UAC and UAS 
>>>> have to be explained in this context.
>>>> Regards,
>>>> Christian
>>>>
>>>>
>>>>
>>>> - 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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Sep 2005 17:00:45 -0400

> services. Rather, we should be discussing the technical aspecs of their 

OK.

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

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.

> something similar), which is not applicable to the PSTN, but to mobile 

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

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 06 Sep 2005 14:30:52 +0300

Paul Kyzivat wrote:

>>>> 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's true... I am also interested in hearing other opinions. But as I 
said before, in GSM and DECT (european cordless) there is a similar 
service call Call Forwarding on User Not-Logged In. So clearly the 
service separates the not-logged in feature from the no reply.

> had power restored to it.)

Agree.

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

True, it is a calee oriented service. My whole point is that there is a 
service that differentiates the states "no reply" from "not-logged in". 
Once you have differentiated the states, then you can apply services to 
the caller (Call complibation on...) or the callee (Call forwarding on...)

/Miguel