Subject: RE: [Sipping] Notes from TISPAN meeting

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 14 Nov 2005 14:05:48 -0500

Paul,

I like your Priority idea, as opposed to the current approach which is
akin to the person who gets into the grocery checkout line, then a
minute later decides to continue shopping for more items, but doesn't
want to give up their place in queue.

Mike

> -----Original Message-----
> From: Paul Kyzivat (pkyzivat) 
> Sent: Monday, November 14, 2005 9:05 AM
> To: Michael Hammer (mhammer)
> Cc: Adam Roach; Cullen Jennings (fluffy); sipping; Dean Willis
> Subject: Re: [Sipping] Notes from TISPAN meeting
> 
> 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
> 
> Michael Hammer (mhammer) wrote:
> > 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
> > 
> 

_______________________________________________
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