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

[Paul Kyzivat <[e-mail]>]

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