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

[Miguel Garcia <[e-mail]>]

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

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