Subject: RE: [Sipping] Notes from TISPAN meeting

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 11 Nov 2005 15:35:34 -0500

Adam,

How do you suspend and resume the camp-on?

Mike

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: Friday, November 11, 2005 1:29 PM
> To: Cullen Jennings (fluffy)
> Cc: sipping; Dean Willis
> Subject: Re: [Sipping] Notes from TISPAN meeting
> 
> Cullen Jennings wrote:
> 
> >Call Completion of Busy Subscriber
> >
> >Clearly related to presence. Jonathan thought that Dialog 
> Package could 
> >do it but is lacking queuing. This is probably hard.
> >
> >We need to ask about if this needs to work when we have multiple 
> >devices for each user on each side. Also multimedia makes it harder. 
> >What sort of queing is needed
> >
> >We have rated this a five question marks on the spicy scale
> >  
> >
> 
> To throw out some half-baked ideas around this service...
> 
> It seems to me that what is really needed, from a protocol 
> perspective, is a mechanism by which I can say, "take this 
> action only after a specified predicate is satisfied." Then, 
> you can use such a mechanism to effect this service with queuing.
> 
> Consider the following use case: Rohan calls Cullen and they 
> begin a conversation. Robert calls and gets a busy 
> indication. He activates the CCBS service. I call Cullen, get 
> a busy indication, and activate CCBS. 
> Cullen ends the call with Rohan; Cullen and Robert are 
> alerted (in some
> order) and are placed in a call. That call ends. Cullen and I 
> are alerted (in some order) and are placed in a call. One 
> potential call flow (leaving out any intervening proxies) would be:
> 
>       Me           Robert          Rohan         Cullen
>        |              |              |              |
>        |              |              |              |
>        |              |              |              |
>        |              |              |(1) INVITE    |
>        |              |              |------------->|
>        |              |              |(2) 180       |
>        |              |              |<-------------|
>        |              |              |(3) 200       |
>        |              |              |<-------------|
>        |              |              |(4) ACK       |
>        |              |              |------------->|
>        |              |              |(5) Session   |
>        |              |              |..............|
>        |              |(6) INVITE    |              |
>        |              |---------------------------->|
>        |              |(7) 486       |              |
>        |              |<----------------------------|
>        |              |(8) REFER     |              |
>        |              |---------------------------->|
>        |              |(9) 200       |              |
>        |              |<----------------------------|
>        |(10) INVITE   |              |              |
>        |------------------------------------------->|
>        |(11) 486      |              |              |
>        |<-------------------------------------------|
>        |(12) REFER    |              |              |
>        |------------------------------------------->|
>        |(13) 200      |              |              |
>        |<-------------------------------------------|
>        |              |              |(14) BYE      |
>        |              |              |------------->|
>        |              |              |(15) 200      |
>        |              |              |<-------------|
>        |              |(16) INVITE   |              |
>        |              |<----------------------------|
>        |              |(17) 180      |              |
>        |              |---------------------------->|
>        |              |(18) 200      |              |
>        |              |---------------------------->|
>        |              |(19) ACK      |              |
>        |              |<----------------------------|
>        |              |(20) Session  |              |
>        |              |.............................|
>        |              |(21) BYE      |              |
>        |              |<----------------------------|
>        |              |(22) 200      |              |
>        |              |---------------------------->|
>        |(23) INVITE   |              |              |
>        |<-------------------------------------------|
>        |(24) 180      |              |              |
>        |------------------------------------------->|
>        |(25) 200      |              |              |
>        |------------------------------------------->|
>        |(26) ACK      |              |              |
>        |<-------------------------------------------|
>        |(27) Session  |              |              |
>        |............................................|
>        |(28) BYE      |              |              |
>        |------------------------------------------->|
>        |(29) 200      |              |              |
>        |<-------------------------------------------|
>        |              |              |              |
>        |              |              |              |
> 
> 
> Note that I'm assuming REFER/nosub here, although it would 
> work well (and potentially even better, from a user interface 
> perspective) if the REFER subscription actually happens. The 
> choice of whether to do this would be up to the caller.
> 
> Now, to examine the magic juice that makes this work, let's 
> look at message 12 (with several headers omitted for 
> clarity); it contains a predicate that specifies when the 
> operation is to be effected:
> 
>   REFER sip:[email-masked] SIP/2.0
>   From: <sip:[email-masked]>;tag=se083lcmn0kk30ao
>   To: <sip:[email-masked]>
>   Refer-To: <sip:[email-masked]>
>   Predicate: (terminalState=free)
> 
> Depending on how we define this predicate stuff, you can 
> actually implement a number of interesting features in this space.
> 
> Any comments on this *kind* of approach (aside from those 
> related to syntax)?
> 
> /a
> 
> _______________________________________________
> 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: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Nov 2005 09:04:50 -0500

Mike - yeah, suspend/resume could be an issue, unless we just don't 
bother and let the referee deal with it when it tries to call back. 
Perhaps something could be done with the Priority header, and a 
reSUBSCRIBE (to the refer event package) to update it.

Adam - Assume that Cullen has multiple UAs registered. Then the campon 
is attempted when none of them answer, and the reestablishment should be 
attempted when any of them enter a suitable state. That requires more 
complexity at Cullen's end - something like a server that queues the 
requests, monitors the state of all the registered UAs, and makes 
decisions about when to retry.

And the hardest case to handle is CCNR. If there was no response, then 
there is no good indicator of when a good time to reply will be. The 
Telcordia version of this waits until the target phone has become busy 
and then stops being busy. That is far from ideal, but is about the only 
obvious event-driven trigger for a state change. (This could be driven 
by presence for those callees that have presence, but you would like it 
to work for others too. Presence isn't a very promising service for 
those who only have audio phones as a UI.)

	Paul