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

[Paul Kyzivat <[e-mail]>]

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.

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

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