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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 30 Sep 2005 11:37:41 -0400

Paul,

This would suggest that so long as one terminal belonging to the AoR has
the capability to accept another call *and* that terminal was recently
used by the user (hopefully the correct human), an attempt should be
made to complete using that terminal (plus any terminal that can accept
a call independent of activity - could be broadcast to all).

Boy, hope that presence system is smart.

Mike

> -----Original Message-----
> From: Paul Kyzivat (pkyzivat) 
> Sent: Friday, September 30, 2005 11:19 AM
> To: Michael Hammer (mhammer)
> Cc: Elwell, John; Miguel Garcia; [email-masked]; 
> Alexeitsev, D
> Subject: Re: [Sipping-tispan] Requirements -02h
> 
> 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
> 
> 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: [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
> > 
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Sep 2005 13:43:09 -0400

Michael Hammer (mhammer) wrote:
> used by the user

This is the weak spot in the whole service.

If the callee has been alerted without success once, there is need for 
some algorithm to decide when to try again. *Any* change in state of any 
registered UA may be considered justification for trying again. But even 
that isn't a great huristic. I may have been gone all afternoon, and 
have recently returned. I am now available though I have not recently 
used any terminal. I would think that even in the absence of any state 
change, another attempt should be made periodically.

> (hopefully the correct human),

I think by definition any human that can cause the terminal to answer is 
a correct human. Certainly that is the assumption when regular calls 
arrive, and I see no reason why it should be different here.

> an attempt should be

One that can detect "someone is now in the area" would be good.

	Paul