Re: [Sipping-tispan] Requirements -02h

[Paul Kyzivat <[e-mail]>]

Miguel Garcia wrote:
> Hi Paul:
> 
> Ok, your consideration about the globality of the response codes sounds 
> reasonable. So then, a 6xx response code to a CCBS recall should be 
> treated as a a request to abandom the queue forever, right?

I think the globality of the response means that it speaks for all 
destinations, not just the one responding. So I think it is definitive 
for what action should be taken at that point in time. But whether that 
is a temporary or permanent condition is a function of which precise 
code it it. For permanent failures, the CCBS should be totally 
abandonded. For temporary ones it could still remain queued and retried 
when there is a reason to believe the situation might be different.

Some examples:

- busy

An attempt is made to alert the callee. The callee has two UAs that are 
invited in parallel. One of them is active on a call. The inactive one 
returns 180, while the active one returns 600 Busy Everywhere. (Somehow 
the active UA had to decide to return 600 rather than 486. How it does 
that is an interesting question.)

In this case, the server managing the queue cancels the leg that 
returned 180, and requeues the request to try later.

Had the UA returned 486 rather than 600, the other UA probably should 
have continuted to ring until. (Though that is an interpretation.)

- decline

An attempt is made to alert the callee. The callee has two UAs that are 
invited in parallel. They both ring and return 180. A user looks at the 
callerid, and then pushes the Decline button on one of the UAs, causing 
it to return 603 Decline.

In this case, the server managing the queue cancels the leg that 
returned 180, and then terminates the CCBS request without further 
attempts.

Had the UA returned 403 rather than 603, then ideally the other UA 
should have continued to ring. (Though that is an interpretation.)

	Paul

> /Miguel
> 
> Paul Kyzivat wrote:
> 
>>
>>
>> Miguel Garcia wrote:
>>
>>> Yeap, I agree. I posted also a question as for a decline should have 
>>> the same effect. There is currently no "decline" in PSTN, although it 
>>> exists in mobile networks, and IMHO a decline to a ccbs recall should 
>>> make the ccbs request to be placed as suspended.
>>
>>
>>
>> Hmm, what do you mean by "suspension"? Since 603 Decline is a Global 
>> Failure, it should be interpretted as speaking for all the UAs. But I 
>> am thinking this should be interpretted as a cancellation of the CCBS, 
>> rather than a suspension. OTOH, I think 600 Busy Everywhere should be 
>> treated literally - as if all the UAs had reported Busy Here - as an 
>> indication to try later.
>>
>>     Paul
>>
>>> /Miguel
>>>
>>> Michael Hammer (mhammer) wrote:
>>>
>>>> This appears to be a consequence of the multi-terminal status union,
>>>> meaning that some centralized entity (could be co-located with one
>>>> terminal) would need to keep track of the call state of all the
>>>> terminals representing that user (AoR).  If any one of those 
>>>> terminal is
>>>> busy, then the caller is busy.  Only when all terminals are unbusy, 
>>>> then
>>>> the caller is deemed free to participate in the call completion.
>>>>
>>>> That assumes that only one human uses all the terminals.  If it is
>>>> possible for more than one person to use those terminals, there 
>>>> could be
>>>> a problem.  Picture the teenage daughter (son) yacking away while the
>>>> father (mother) is trying to use CCBS to complete an important call.
>>>> How one sets up the relationship from terminals to AoRs can be tricky.
>>>> Perhaps some indication of CCBS from this terminal only would be 
>>>> useful.
>>>>
>>>> At least that is how I am interpreting the requirements.
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: [e-mail] 
>>>>> [mailto:[e-mail]] On Behalf Of Elwell, John
>>>>> Sent: Friday, September 30, 2005 8:49 AM
>>>>> To: Miguel Garcia; '[e-mail]'
>>>>> Cc: Alexeitsev, D
>>>>> Subject: RE: [Sipping-tispan] Requirements -02h
>>>>>
>>>>> Miguel,
>>>>>
>>>>> "REQ-CCBS/CCNR-15: Should the caller be busy at the time of executing
>>>>>                     CCBS/CCNR request, the request is suspended until
>>>>>                     its status changes (back to free status)."
>>>>>
>>>>> What is meant by caller busy? Is this the human user (or 
>>>>> application)? Or the UA from which CCBS/CCNR was requested? Or all 
>>>>> the caller's UAs? Or any of the caller's UAs? This is important as 
>>>>> it will determine the SIP signalling needed to determine whether 
>>>>> the caller is busy.
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Miguel Garcia [mailto:[e-mail]]
>>>>>> Sent: 30 September 2005 11:00
>>>>>> To: '[e-mail]'
>>>>>> Cc: Alexeitsev, D
>>>>>> Subject: [Sipping-tispan] Requirements -02h
>>>>>>
>>>>>> ok, so here it goes with a new iteration:
>>>>>>
>>>>>> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sippin
>>>>>> g-tispan-requirements-02h.txt
>>>>>> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sippin
>>>>>> g-tispan-requirements-02h.html
>>>>>>
>>>>>> And the diff version:
>>>>>> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sippin
>>>>>> g-tispan-requirements-02g-to-h.html
>>>>>>
>>>>>> Changes:
>>>>>> - Clarification that we don't list every single requirement that 
>>>>>> we have.
>>>>>> - Calling Party Category requirements are now in the general section
>>>>>> - New CCBS/CCNR requirements for the callee to be able to reject a 
>>>>>> request for the service and to be able to use any given terminal.
>>>>>> - Clear of ACR text related to the override feature.
>>>>>>
>>>>>> Note that I am still trying to classify my e-mail. Since 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> you all have
>>>>>
>>>>>> been very active in the last few days, I wouldn't be 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> surprise to see
>>>>>
>>>>>> that I have forgotten to add or modify something that has 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> been agree
>>>>>
>>>>>> upon. In such case, please drop me an e-mail and I will add 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> it in the
>>>>>
>>>>>> next iteration.
>>>>>>
>>>>>> /Miguel
>>>>>> -- 
>>>>>> 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