Subject: [Sipping] Notes from TISPAN meeting

From: Cullen Jennings <[email-masked]>
Date: Wed, 09 Nov 2005 22:39:13 -0800

Agenda:

Martin presentation
Miguel Presentation
Next Steps

----------

Call Rejection
TISPAN does not need the override call rejection

Jonathan wrote draft with new status code to reject anonymous calls. Seemed
to have good support that it would be acceptable in sipping and that it
would mean TISPAN needs.

-----------

Terminating Party Identification

Need to document more on what is needed here.

Should read draft-rosenberg-sip-identity-privacy-00 it may solve the problem
of call in 800 number, get an operator, and be able to call back that
operator and still protect privacy of operator.

------------

Call Waiting

We don't get the requirement. We think we might be able to do some of them
but not sure. Please help us understand.

------------

Call Diversion

Going with the draft-jennings-sip-voicemail-uri-04 draft

---------------

CPC/OLI

Rocky will write draft for sipping to address trying to solve this with SAML
assertions. 

---------------

Malicious Communication Identifier

Once again, read draft-rosenberg-sip-identity-privacy-00.

The logging system can make the tunneled query

-----------------

Advice of Charge 

Have a look at the app interaction framework.
draft-ietf-sipping-app-interaction-framework-05.txt

-------------------

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

---------------------

How do we respond to this to TISPAN.
1) Jon proposed a tracker
This is a 3 column html table that has some entries in it

2) Eric & Martin will write a communicate in the from of an internet draft

-------------------------

Moving on to Miguel slide sets. This is not in requirements draft but came
up recently. It had to do with opening and closing media gates based on what
is happening in signaling. Related to one way media. Clearly we need to more
requirements for this.

_______________________________________________
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: Adam Roach <[email-masked]>
Date: Fri, 11 Nov 2005 10:28:50 -0800

>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

---

From: David R Oran <[email-masked]>
Date: Mon, 14 Nov 2005 08:48:32 -0500

On Nov 11, 2005, at 1:28 PM, Adam Roach wrote:

> 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.
>
Uh, this is precisely what the purpose of preconditions is. that  
doesn't mean it's the right general abstraction for a service like  
CCBS though. More interesting is who keeps state for what purpose.  
How you represent the predicate in the protocol is only one piece.

> 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    |              |
> 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.
>
> message 12 (with several headers omitted for clarity); it contains  
> a predicate that specifies when the operation is to be effected:
>
> Any comments on this *kind* of approach (aside from those related  
> to syntax)?
>
> /a
>