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

[Miguel Garcia <[e-mail]>]

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:

> 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
> 
> Michael Hammer (mhammer) wrote:
> 
>> 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: [e-mail] 
>>> [mailto:[e-mail]] On Behalf Of Miguel Garcia
>>> Sent: Tuesday, September 27, 2005 7:47 AM
>>> To: Schmidt, Christian
>>> Cc: Tessa Silvia; [e-mail]
>>> 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:[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