Subject: RE: [Sipping-tispan] Requirements -02h

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 30 Sep 2005 09:48:40 -0400

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Elwell, John
> Sent: Friday, September 30, 2005 8:49 AM
> To: Miguel Garcia; [email-masked]'
> 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:[email-masked]]
> > Sent: 30 September 2005 11:00
> > To: [email-masked]'
> > 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:+358-50-4804586
> > sip:[email-masked]
> > Nokia Research Center      Helsinki, Finland
> > 
> > 
> > _______________________________________________
> > Sipping-tispan mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sipping-tispan
> > 
> 
> _______________________________________________
> Sipping-tispan mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Sep 2005 11:18:49 -0400

I think there can be no reasonable way to know if there is another 
person available to take another call. So I think the attempt must be 
made, and if there is no answer, then the request requeued to be tried 
later.

Note that even when there is but a single user, some UAs might be "busy" 
(in a session) yet the user may be able to take the call:
- the "busy" UA is doing IM. The user can still pick up a phone.
- the user considers the CCBS more important. he will preempt
   the call he is on to take the CCBS recall.

The latter case can happen with a single UA. (Its a call waiting case.) 
So, contrary to the CCBS spec, I think the recall should be offered in 
this case.

	Paul