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

From: Miguel Garcia <[email-masked]>
Date: Mon, 03 Oct 2005 14:47:46 +0300

Hi John:

Good point, I don't even know myself. This could be:

a) there is already at least one more SIP session going on from that UA 
or from any other UA that the caller is using.

b) similar to a), but with a number of predetermined simultaneous sessions.

c) the caller does not answer an invitation for a CCBS/CCNR callback.

d) the caller declines the previous invitation.

Something like that?

/Miguel

Elwell, John wrote:

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

-- 
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: "Elwell, John" <[email-masked]>
Date: Mon, 03 Oct 2005 20:52:06 +0100

Miguel,

In my opinion the recall should be presented to the UA(s) concerned, which
should each have the possibility to accept the recall. The decision to
accept could be based on policy (e.g., automatically accept if there is no
call in progress) or based on the outcome of interaction with the user
(e.g., the user might choose to interrupt an ongoing call in order to accept
the recall if he considers the CCBS/CCNR call more important. But I am only
guessing at what TISPAN might have in mind.

John

> Sent: 03 October 2005 12:48
> To: Elwell, John
> Cc: [email-masked]'; Alexeitsev, D
> Subject: Re: [Sipping-tispan] Requirements -02h
> 
> Hi John:
>

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 11 Oct 2005 22:09:09 +0100

In the ISDN service there is no "try again" to the callee, once the CCBS completion has been presented to the end terminal, and therefore performed alerting to the absent user.. 

As you identify, it is almost impossible to identify an algorithm that works for the user, apart from the knowledge that the user is there and involved in another call. In the latter case, the callee is not alerted on the assumption that the user can only deal with one call at once.

So, just as on every PBX that I know of, if the recall to the callee fails, then the CCBS is cancelled. The callee can come back to the phone, interrogate the service to see if the CCBS request is still there, and if it is not, then reactivate it.

regards

Keith

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Paul Kyzivat
> Sent: 30 September 2005 18:43
> To: Michael Hammer (mhammer)
> Cc: [email-masked]; Alexeitsev, D
> Michael Hammer (mhammer) wrote:
> > 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
> 
> 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
> > 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.
> 
> One that can detect "someone is now in the area" would be good.
> 
> 	Paul
>

---

From: "Poetzl, Joachim" <[email-masked]>
Date: Wed, 12 Oct 2005 12:01:17 +0200

Hi all,

If I understood correctly we are mixing two things up here.

We have to differentiate two approaches in PSTN world:

Functianal protocoll - The service executing entity knows if the callee (A) is free/not busy and can (if he wishes) accept and incoming CCBS recall indication which will lead to an call setup procedure to User B. This is done by an facility element checking user As Status

Keypad approach - hence the Callees terminal does not support protocol elememnts / procedures the service executing entity will set up a call to the callee which may be busy which will not happen in the functional case. If the user is free he can accept the call.

Even that ITU I253.3 talks abot an CCBS recall we should be clear that we are talking about an indication to the user (functional case) or a call to the USER A (CCBS recall).

Taken from I.253.3:
2.2.4	CCBS recall: A network-to-user indication, informing user A that the network is ready to initiate a CCBS call to destination B and that the network is awaiting a response to this indication from user A.
2.2.5	CCBS call: Call set-up by the network from user A to destination B resulting from user A's acceptance of a CCBS recall.

Regards

Joachim Pötzl
Deutsche Telekom AG
T-Com Zentrale
TE332-4; Dienste- und Netzkonvergenz, Protokolle von NGN
64307 DARMSTADT, GERMANY 
Phone:  +49 6151 83-2134
Fax:      +49 6151 83-4577
PCFax:  +49 521 52244 983
>mailto:[email-masked] 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Drage, Keith (Keith)
Gesendet: Dienstag, 11. Oktober 2005 23:09
An: 'Paul Kyzivat'; 'Michael Hammer (mhammer)'
Cc: [email-masked]'
Betreff: RE: [Sipping-tispan] Requirements -02h

regards

Keith