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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 3 Oct 2005 10:19:38 -0400

Miguel,

In the PSTN, it is not so much a declining of a CCBS request as it is an
indication in the Release Cause Diagnostics that CCBS is possible.  If
CCBS is not indicated as possible, then the service is never initiated.

I didn't understand the meaning of declining a recall putting it into
suspended state.  Is that a permanent suspension?  Normally a resume
would take one out of the suspended state and allow a busy free
indication to cause the recall to proceed.

Mike

> -----Original Message-----
> From: Miguel Garcia [mailto:[email-masked]] 
> Sent: Monday, October 03, 2005 7:52 AM
> To: Michael Hammer (mhammer)
> Cc: Elwell, John; [email-masked]; Alexeitsev, D
> Subject: Re: [Sipping-tispan] Requirements -02h
> 
> 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.
> 
> /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: [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
> > 
> > 
> 
> -- 
> 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

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 04 Oct 2005 15:23:29 +0300

Hi Mike:

As I clarifed in another e-mail to Paul, I think you are right in 
considering the globabality of 6xx responce codes.

/Miguel