Subject: RE: AW: [Sipping-tispan] Re: CCBS/CCNR in Version -02f

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 27 Sep 2005 15:59:46 -0400

Miguel,

Continuing on my earlier comment:  By network are you taking routers?  

If you mean voice host applications such as proxies, are you suggesting
that a proxy in the middle of a network somewhere will do this
prioritization?

If you mean some service of the callee, what is the chance that 2 calls
will arrive simultaneously?

Or do you mean the callee (or his server) will know that there is a
caller camped on and will intentionally delay incoming calls while a
"subscriber free" indication is sent toward the caller and completed
with some notification or timer before moving on to the regular call?

I certainly hope you are not suggesting that we elevate CCBS calls to
the status of emergency calling.  There are only so many useful levels
of priority, and this could muddy the water.

Mike

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Miguel Garcia
> Sent: Tuesday, September 27, 2005 7:47 AM
> To: Schmidt, Christian
> Cc: Tessa Silvia; [email-masked]
> Subject: Re: AW: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> 
> 
> 
> Schmidt, Christian wrote:
> 
> > 
> > 
> > We have already have REQ 12 stating that
> > 	 Any communication performed as a result of the execution of a 
> > CCBS/CCNR request should be distinguishable from regular 
> communications.
> > 
> > So,  all terminating call are "distinguishable" and any policy a 
> > network might have could be easily based on this, without 
> further requirements.
> > Other views ?
> > 
> > Christian: I see, perhaps you can add a short explanation 
> for this purpose:
> > 	 Any communication performed as a result of the execution of a 
> > CCBS/CCNR request should be distinguishable from regular 
> communications.
> > This can be used to priorize CCBS/CCNR calls towards the callee.
> > What do you think?
> > 
> 
> I have a proposal for this requirement:
> 
> 
>     REQ-CCBS/CCNR-12:
>     It must be possible for the network to priotirize 
> CCBS/CCNR recalls
>     towards the callee, above regular calls. This implies that any
>     communication performed as a result of the execution of a 
> CCBS/CCNR
>     request should be distinguishable from regular communications.
> 
> 
> /Miguel
> 
> 
> > Regards
> > Silvia
> > 
> 
> 
> -- 
> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Sep 2005 17:41:44 -0400

While this falls into the realm of solution rather than requirements, I 
think there is an implication that there needs to be one server 
operating for the caller and another operating for the callee.

The caller server has to remember the requests outstanding for a 
particular calling AOR, and must alert the UAs of that AOR when there is 
an opportunity to complete one of those requests.

The callee server has to remember all the incoming requests, and 
prioritize them. It needs to monitor the availability of the callee's 
UAs and decide when to attempt one of the requests. It may also need to 
screen incoming calls in order to manage prioritization of those versus 
queued CCxx requests. It also needs to inform the caller's server that 
it should now attempt a call.

The callee's server probably needs to use the dialog event package, and 
the callee's UAs thus need to support it. But they probably only need to 
allow their own server to subscribe - not everybody.

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 28 Sep 2005 14:02:23 +0300

Hi Mike:

Inline discussion.

> Continuing on my earlier comment:  By network are you taking routers?  

No. I am referring to SIP entities in general, including proxies, 
registrars, application servers, etc., as required.

> that a proxy in the middle of a network somewhere will do this

Yes, exactly. I don't know yet if this will be a proxy or an application 
server, or what. But according to the requirement there should be a SIP 
entity that is able to do such prioritization.

> will arrive simultaneously?

Very little, if not to say, impossible. But withing a period of time, it 
is possible (see below).

> with some notification or timer before moving on to the regular call?

Something like that. By reading the spec, once the callee becomes free, 
it gives him a few seconds (max. 15 seconds) in case he wants to make 
another call (this is the so-called idle timer). If a call arrives 
during this time, it will have the same treatment as "busy".

I think the above also applies to the period of time when the caller is 
indicated that the callee is free, so that the caller can accept a CCBS 
recall.

> of priority, and this could muddy the water.

No, no, I am not suggesting that.

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 28 Sep 2005 14:06:14 +0300

Paul:

I think you did a very good summary of the service. I will also add that 
  I believe the caller's server also needs to use the dialog event 
package towards the caller, to find out if the caller is busy or not at 
the time some "timeslot" is granted. In case the caller is busy, the 
CCBS request gets the status of "pending", and it only resumes after the 
caller is free again. This seems to be a justification for the dialog 
event package in the caller's side.

/Miguel

Paul Kyzivat wrote:

>>>    It must be possible for the network to priotirize CCBS/CCNR recalls
>>>    communication performed as a result of the execution of a CCBS/CCNR

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Sep 2005 09:23:54 -0400

> event package in the caller's side.

I think it is a fatal flaw to assume that you can determine "busy" by 
examining the results of the dialog event package.

Suppose that a UA is engaged in a dialog that is an MSRP IM session? 
This may not have anything to do with being busy for a voice call.

At best, I think you might monitor the dialog event package for *any* 
change of state, and assume that is a transition that justifies another 
attempt.

In the sip world, I think the only viable measure of "busy" is to send a 
request and receive a 486 response. Even then, the same UA, under the 
same circumstances, may be "busy" for certain kinds of requests but not 
for others. (e.g. I'm busy for voice, but not for IM.)

	Paul

> /Miguel
> 
> Paul Kyzivat wrote:
> 
>> While this falls into the realm of solution rather than requirements, 
>> I think there is an implication that there needs to be one server 
>> particular calling AOR, and must alert the UAs of that AOR when there 
>> is an opportunity to complete one of those requests.
>>
>> UAs and decide when to attempt one of the requests. It may also need 
>> to screen incoming calls in order to manage prioritization of those 
>> versus queued CCxx requests. It also needs to inform the caller's 
>> server that it should now attempt a call.
>>
>> The callee's server probably needs to use the dialog event package, 
>> and the callee's UAs thus need to support it. But they probably only 
>> need to allow their own server to subscribe - not everybody.
>>
>>     Paul
>>

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 28 Sep 2005 16:48:42 +0300

Paul:

I think you made very good points. I guess this deserves some more thoughts.

/Miguel

Paul Kyzivat wrote:

> 
> 
> Miguel Garcia wrote:
> 
>> Paul:
>>
>> I think you did a very good summary of the service. I will also add 
>> that  I believe the caller's server also needs to use the dialog event 
>> package towards the caller, to find out if the caller is busy or not 
>> at the time some "timeslot" is granted. In case the caller is busy, 
>> the CCBS request gets the status of "pending", and it only resumes 
>> after the caller is free again. This seems to be a justification for 
>> the dialog event package in the caller's side.
> 
> 
>>>> Continuing on my earlier comment:  By network are you taking 
>>>> routers? If you mean voice host applications such as proxies, are 
>>>> you suggesting