Subject: RE: AW: [Sipping] Call Completion: In Defense of Explicit Operati ons

From: "Elwell, John" <[email-masked]>
Date: Fri, 13 Apr 2007 08:13:51 +0100

I think this is heading in the right direction. I noted some subsequent
postings discussing matters to do with tying up resources in the PSTN when
interworking, and I think this still needs some attention. For the present,
let's confine ourselves to the case where the callee is in the PSTN and is
busy.

Case 1: The caller never subscribes. I see two solutions. With the first,
the gateway automatically issues a TCAP request for queueing at the same
time as sending the 486 response to the caller. If the gateway does not
receive a SUBSCRIBE request within a certain period it then sends a TCAP
request to cancel queueing. With the second, the gateway starts its own
"queue" but takes no TCAP action. When it detects that there is a watcher
(i.e., the caller has subscribed) it issues a TCAP request for queueing. My
concern with the first one is that the PSTN might issue a charge as soon as
the TCAP request for queueing is received. Perhaps Martin can shed light on
that. This may force us into the second approach.

Case 2. The caller cancels the subscription. This is likely to be relatively
rare, as already noted, because why would the caller bother? But if he does,
then the gateway can either determine that there are no watchers and send a
TCAP request to cancel queueing or can simply take no action. However, see
also case 3.

Case 3. Pause and resume. If the caller just cancels the subscription, the
gateway will have to take account of the fact that this could be due to
either pause or cancel. Therefore on detection of the fact that there is no
longer a watcher it probably has to assume pause and send a TCAP pause
request. On detection of the fact that there is a watcher again later, it
has to send a TCAP resume request.

John

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 12 April 2007 22:04
> To: [email-masked]
> Cc: Adam Roach; Dean Willis
> Subject: Re: AW: [Sipping] Call Completion: In Defense of 
> Explicit Operations
> 
> My comments below were off the cuff in response to what had 
> been said. 
> But what I ended up at seems like an almost complete and workable 
> approach. So let me try to explain it again directly:
> 
> 1) A calls B.
> 2) B decides to reject the call (say busy)
> 3) B adds the caller A to the call completion queue
> 4) B returns a 486 response with some indication that
>     the caller has been queued (how is TBD)
> 5) if A wants to use the call completion feature,
>     it subscribes to the event package.
> 6) B sends an initial notify, with queue status.
>     Policy most likely limits the information to
>     entries naming the subscriber. (Presumably there
>     is only one.) With the entry is a status, which
>     can be either "waiting" or "selected". Assume it
>     is "waiting" because others are in the queue.
> 7) When B becomes available for a call, it selects the
>     oldest entry in the queue for which there is a watcher.
>     It changes the state of that entry to "selected".
>     As a result of the change, a notification is sent
>     to any watchers that can see the change. That includes
>     at least A.
> 8) Perhaps while that is happening B may receive a call
>     from C. B knows what is going on, notes that the caller
>     is not the selected caller B, and so rejects the call.
>     (Same actions as above.)
> 9) When A receives the notify, it alerts its user. When
>     the user is ready, it places the call to B again.
> 10) When B receives the call from A, it notes it is the
>     selected caller and answers. It also then removes the
>     entry for A from the queue. This results in a notify
>     to A that there is no entry for it in the queue.
> 11) When A receives that notify, it cancels its subscription.
> 
> If, following (4), A had not bothered to subscribe, its entry would 
> remain in the queue for awhile. Entries will age out of the queue 
> eventually.
> 
> If, following (6), enters a state where it won't be able to 
> complete the 
> call to B (e.g. A gets a call from C), then A simply 
> unsubscribes. When 
> A is again ready to try, it again subscribes. (Being 
> subscribed or not 
> is the means of doing suspend and resume.)
> 
> For CCNA (no answer) I think B will have to put the caller into the 
> queue any time a call is abandoned by the caller. I think that is ok.
> 
> 	Paul
> 
> 
> Paul Kyzivat wrote:
> > 
> > 
> > Dean Willis wrote:
> >> Adam Roach wrote:
> >>
> >>>
> >>> _That's_ interesting. I hadn't thought of that. So, 
> instead of using 
> >>> BFCP (as my current proposal suggests), we could use an 
> event package 
> >>> to unobtrusively subscribe to a queue, and XCAP to place 
> ourselves 
> >>> in, pause, resume, and remove ourselves from the queue.
> >>>
> >>> That seems quite reasonable. I'd be interested to see what other 
> >>> people have to say about it.
> >>
> >> I didn't mean to suggest that the caller enqueue 
> themselves with XCAP, 
> >> but that if the queue manager and the event server were on 
> different 
> >> nodes that the queue manager could manipulate the queue 
> state document 
> >> using XCAP.
> >>
> >> I still think that being enqueued as a result of an INVITE is a 
> >> reasonable thing.
> > 
> > Dean,
> > 
> > The ultimate goal seems to be to give the potential caller 
> at the top of 
> > the queue a window of opportunity to attempt a call. During 
> that time, 
> > you don't want to allow the other pending callers, or new 
> callers, to 
> > establish a call to the callee.
> > 
> > But if you enroll everybody that attempts a call, without 
> knowing that 
> > they will use the queue to retry, then you have a problem. 
> You don't 
> > want to give a window of opportunity to someone who isn't waiting.
> > 
> > I guess you could go ahead and enroll the caller of every 
> failed call, 
> > but only give a window of opportunity to a candidate that has been 
> > notified that it is at the head of the queue.
> > 
> > That also suggests a way to handle suspend/resume: to 
> suspend you simply 
> > cancel your subscription. And to resume you make a new subscription.
> > 
> > That seems somewhat interesting. But it presents a new problem - a 
> > subscriber needs to know if they even have an entry in the 
> queue. If you 
> > only get notified when you get to the top, then you could 
> wait forever 
> > if you aren't in the queue.
> > 
> > I guess that could be handled by having an initial 
> notification report 
> > your queue entry even if you are not first - perhaps giving 
> position in 
> > queue. Then a subsequent notifications could be filtered unless the 
> > entry is first in queue, if it is considered undesirable to 
> notify of 
> > every change in position. That would take some peculiar 
> language around 
> > the design of a filter, but seems like it should be possible.
> > 
> >     Paul
> > 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Fri, 13 Apr 2007 13:24:23 +0200

Hi all,

thanks for this very productive discussion. Just as a reminder of what are the basic requirements for at least TISPAN in this issue: as this all shall end up in a feature for user A who encounters a busy user B, 

- it shall be possible to inform A that he has the possibility to receive a notification when he can start a recall (as there could be several users which encounter the busy condition at B, of course that means that he would be added to a queue, the first user who orders this notification should be the first who receives it), 

- A shall be able to decide if he wants to receive this notification ,

- A shall be informed when it is possible to start a recall (surely one but not the only condition for this is that he has reached the top of the queue), and

- A shall be able to pause this notifications without loosing his position in the queue (he just wouldn't receive a recall notification although he might be at the top of the queue, in this case the second queue entry would receive a recall notification).

So, this would be what we need.

Regards, Martin

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Apr 2007 09:36:46 -0400

> - it shall be possible to inform A that he has the possibility to receive a notification when he can start a recall (as there could be several users which encounter the busy condition at B, of cour…

This still needs some work. The current draft proposes using 
"Allow-Events" for this. That makes sense if the UAS returning this will 
always be the one that services the subscribe. I suspect a reasonable 
case will be where a phone returns the error response but a separate 
server will handle the queue and the subscription. In that case I think 
the use of Allow-Events is debatable.

> - A shall be able to pause this notifications without loosing his position in the queue (he just wouldn't receive a recall notification although he might be at the top of the queue, in this case th…

I think what Adam and I have been converging on addresses the rest.

	Paul