Re: [Sipping-tispan] Requirements -02h

[Miguel Garcia <[e-mail]>]

Paul:

Everything agreed.

As for your question of how could the UA return decide to return a 600 
or a 486, I would expect the UI to present a question to the user, as 
one  more choice.

/Miguel

Paul Kyzivat wrote:

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

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