Subject: [Sipping] App-Interaction: Considering models

From: Adam Roach <[email-masked]>
Date: Wed, 13 Aug 2003 17:32:04 -0500

After considering Jonathan's contention that defining
a new method for conveying stimulus is creating something
that is similar in meaning to NOTIFY, I'm inclined to
agree to some point. There are still subtle differences
in meaning, so I'm not completely convinced that a new
method is wrong, but I understand the point he's trying
to make.

After discussing it privately with others, I've concluded
that there are three viable models worth considering. There
are, of course, some minor variations that can be made to
each.

1) Standard HTTP Handling

UAC           App Server          UAS
1|-----INVITE---->|                |   
2|                |-----INVITE---->|   
3|                |<-----200-------|   
4|<-----200-------|                |   AS adds HTTP URL to 200
5|---HTTP GET---->|                |   UAC requests KPML script
6|<-----200-------|                |   AS replies with script
7|---HTTP POST--->|                |   UAC provides digits
8|<-----200-------|                |   AS acknowledges digits

  Of the three options presented here, I see this as the best
  solution. Basically, the app server includes an HTTP URL
  in the 200 response to the INVITE that it has proxied. The
  UAC then does a GET on the KPML script. Just like with
  HTML forms, the UAC does whatever local stuff is necessary
  to "fill out the form" (in this case, collect digits), and
  then posts the result back to the App Server. This is all
  plain-Jane unextended HTTP as it was intended to work.

2) Explicit Subscriptions (with GRUU)

UAC           App Server          UAS
1|-----INVITE---->|                |   
2|                |-----INVITE---->|   AS extracts GRUU from INVITE
3|                |<-----200-------|   
4|<-----200-------|                |   
5|<---SUBSCRIBE---|                |   AS SUBSCRIBEs with KPML script
6|------200------>|                |   
7|-----NOTIFY---->|                |   
8|<-----200-------|                |   
9|-----NOTIFY---->|                |   UAC provides digits
A|<-----200-------|                |   AS acknowledges digits

  My second choice would be an explicit subscription to stimulus
  events. The only sticky part in this solution is the question
  of how the AS can route a SUBSCRIBE to the UAC. Once we have
  a GRUU solution in place, this is a no brainer: the AS can
  extract the GRUU from the INVITE, and use it as the target
  of its SUBSCRIBE. The KPML script is included in the SUBSCRIBE,
  and essentially serves as a filter.

3) Explicit Subscriptions (with REFER)

UAC           App Server          UAS
1|-----INVITE---->|                |   
2|                |-----INVITE---->|   
3|                |<-----200-------|   
4|<-----200-------|                |   AS adds SIP URL to 200
5|-----REFER----->|                |   
6|<-----200-------|                |   
7|<----NOTIFY-----|                |   
8|------481------>|                |   
9|<---SUBSCRIBE---|                |   AS SUBSCRIBEs with KPML script
A|------200------>|                |   
B|-----NOTIFY---->|                |   
C|<-----200-------|                |   
D|-----NOTIFY---->|                |   UAC provides digits
E|<-----200-------|                |   AS acknowledges digits

  Although somewhat chattier than the previous solution, this gets around
  the GRUU issue by having the AS provide a SIP URI that routes to itself
  in the 200 response. The UAC then uses this URI to send a REFER to the
  AS. This REFER tells the AS to SUBSCRIBE to the UAC. The flow from that
  point forward is the same as for solution 2.

/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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 13 Aug 2003 22:54:17 -0700

I think all of these proposals are significantly more complex than using a
MESSAGE/NEW_METHOD/NOTIFY. I will mention a few issues with the proposal
inline but first let me a few other proposals...

All of these have a call flow like

> 5|---SIP MESG---->|                |

The question for KMPL is, what method to use in msg 5.

Proposal 1) Use MESSAGE. Many people think the semantics of message are
display this IM to a user. Perhaps, but I send IM to applications and they
send me back things like stock quotes all the time. I have no problem with
semantics of MESSAGE being deliver this message to the addressed user or
automaton. That's what we are doing here. Misrouted message will cause
trivial problems, but this is a bogus issue - misrouted INVITE or MESSAGE
will cause problems to - don't misroute things.

Proposal 2) Use some new method like STIMULUS. The semantics of this are
some user input stimulus is being sent - STIMULUS is to input what MESSAGE
is to output. 

Proposal 3) Use NOTIFY. Semantics are, here is some information about some
event that you requested to be informed about. The usual complaint on this
one is that there was no Subscribe, or it was implicit, or it was explicit,
or it violated some law of the SIP world. I think there was a subscribe, it
was in the message that initiated the script. There is also a clear time it
will end - when the script is terminated or when the dialog of the message
that initiated the script ends. We all remember that implicit subscribes
where bad (whatever an implicit subscribe is) but people seem to have a hard
time remembering why this will be bad here.

All 3 of these proposals have something in common - there is no concrete
argument that any of them would not work. They send to a URI the AS provided
so there are no forking issues. There is some grief on the semantics. Option
2 has the advantage of it lets us define the semantics however we want. I
think that 2 is the best way to go but I don't care greatly. I do need
convincing on what's wrong with these to move to something more complex.

More comments inline

> 1) Standard HTTP Handling

One of the difficult parts of this is security.

This will get more complicated once you provide a way to send in message 4
the credentials that will allow 7. It may also make the App-Info header only
really work with scripts that use HTTP to post instead of other things.
Also, in the case of a financial institutions that have to log electronic
communications, you will need to provide way to insert logging HTTP proxies
and probably proxies for FW traversal too. Of course the AS or the UAC will
need to figure out the network topology to know if the AS is inside or
outside the FW. It's possible to configure all the domain and HTTP proxies
rules into the device but it still hard to secure - particularly on devices
that don't want to implement HTTPS due to not much memory.

> 2|                |-----INVITE---->|   AS extracts GRUU from INVITE

I sort of see this one, but what if the App Server wanted to run an App on
the UAS instead of the UAC. Would the 180 have the GRU? Would it be
reliable?

I seem to recall someone asking about the expire time on the subscription
:-)

I'd be keener on GRUU solutions if GRUU was a solved problem.

> 3) Explicit Subscriptions (with REFER)

I got to admit, I had never considered anything like this. I think it is
going to be hard to convince folks this is really easier and better than
sending DTMF over INFO. Keep in mind that KPML is for little device that
think 14k of memory is a lot. Real devices are just going to do VXML and
HTML and ignore KPML.

Cullen

---

From: Alan Johnston <[email-masked]>
Date: Thu, 14 Aug 2003 08:47:49 -0500

One short comment below.

>will cause problems to - don't misroute things.

Here's the problem I have with this.  Lets say I have a dumb SIP phone that 
has no display but does support KPML
I also have a separate SIP IM client.  My proxy has very simple logic - 
MESSAGE requests directed at my phone get redirected to my
IM client.  Using MESSAGE like this breaks this very simple (and 
potentially useful) logic.  My proxy now has to take apart
the MESSAGE request and determine if it is a IM MESSAGE, or an RPC MESSAGE 
(or whatever we will call this new use
for MESSAGE.

This is the type of MESSAGE routing problems I'm concerned about.

Thanks,
Alan Johnston
MCI

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 14 Aug 2003 08:57:45 -0700

Ah, this is worth discussing - I don't think it is a problem. The proposal
is to use MESSAGE not as the way to initiate the script on the UA but as the
way for the UA to tell the App Server the results of the script.

Lets say the AOR of the UAC was alice@atlanta, UAS was bob@bilboxi. The KPML
script would contain the address of the app server. So say the script had
[email-masked], the URI of message with the KPML result from
the UA to the appserver would be sip:[email-masked]. The
proxy would just route normally to server1 and would not need to know
anything special. A MESSAGE address to bob or alice would go to them.

Cullen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Aug 2003 13:07:50 -0400

Thoughts inline.

> 1) Standard HTTP Handling

This is also my favorite, and always has been. However, I had believed 
I was the only one who liked this.

Cullen raised some concerns about it:

> the credentials that will allow 7.

This is only a problem when there is no direct trust relationship 
already between the caller and the application server. If there is 
such a trust relationship, then you can use digest with the same 
credentials used to authenticate the INVITE. If there is not, it is 
more complex.

The case when there is not (which we discussed in the design team 
meetings) was when, for example, I call Cullen. This lands in a Cisco 
proxy, which runs an app that asks me to choose which "fluffy" I want, 
as there are miraculously two at Cisco (probably not true but bear 
with me). Now, the Cisco proxy doesn't know me at all. But, it wants 
to make sure that the entity which does the POST is the one that made 
the call.

I would argue that there is an easy solution to this, which is just 
sips + https. If the call is over sips, the proxy can send the UA a 
random URI in the APp-Info header. No one else can see this header but 
the caller and intervening proxies. Then, the caller does https to the 
proxy, and sends the URI it was handed. I believe this provides a 
reasonably secure correlation.

Note that sips is needed in all cases for any security for app-info 
headers.

> It may also make the App-Info header only

That would be the proposal here, since its HTTP with the other script 
types (HTML, VoiceXML).

> and probably proxies for FW traversal too.

All of these exist, no? The only real argument for HTTP is that this 
basically IS a web application of sorts, just one on a really dumb device.

> Of course the AS or the UAC will
> outside the FW. 

I don't follow that.

> It's possible to configure all the domain and HTTP proxies

Well - thats the rub - if https isnt possible, yes, its a problem. But 
then you can't argue that sips would be OK, in which case you have no 
security anyway.

> 2|                |-----INVITE---->|   AS extracts GRUU from INVITE

This was one of the solutions I outlined in my initial email, yes. 
GRUU is not the only problem. There is also the correlation problem - 
how does the UA know that the SUBSCRIBE comes from an entity along the 
call path? AUthorizing the subscribe as above would be really hard.

>   in the 200 response.

How does that solve the GRUU problem? It still needs to get a GRUU to 
hand out in the Refer-To. This just adds another layer of indirection.

Adam later wrote:
> Your phrasing above knocked loose in my mind another reason
> that implicit subscriptions[1] are ill-advised: you are using
> a single transaction to perform two operations. Conveying
> partial success (e.g. the call completed, but the subscription
> failed) is problematic. We have made efforts to avoid this
> type of situation in the past. 

What two operations are being performed by which transaction? The NOTIFY?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 15 Aug 2003 15:35:49 -0700

Let me propose a realistic scenario that is a little more difficult with
http. It is probably possible to solve, just complicated. I will admit that
much of the reason many people don't want to use HTTP is because they think
sending it in SIP will be less work - they may or may not be right but the
"less work" on low end devices is what has driven us to a fairly messy
situation in handling DTMF today. I want to come up this something that is
appealing enough to the people doing evil things today that they stop doing
evil things. That said, let me describe a scenario that does occur and is
difficult with HTTP.

A residential phone user, called A, has a UA that they can use to make PSTN
calls. This UA connects to a voice service provider, called Provider B that
claims to terminate the calls to the PSTN. This provider does not directly
terminate them but actually pass them to provider C. Provider C runs the
call through a H.323 translator and terminates then sends the call to a 323
GW. The 323 GW does not support RFC 2833. The user A UA is likely to be
behind a NAT and the final GW might be behind a NAT depending on the country
of termination. B does not wish A to learn the identify of C because A might
get a better price and cut B out of the loop. C does not wish B to learn too
much about their network topology, since C might actually be passing traffic
to provider D. Provider B and C and both run transparent B2BUA, broken
proxies, and firewalls to make this all possible. The 323 translator wants
to receive DTMF in the signaling so that it can pass it to the GW. In a
variant of the scenario, provider B is a prepaid service and wants to be
able to intercept long #.

If the phone sent DTMF over INFO, the people with this problem would be
happy. The development effort to send DTMF over INFO is very low. It would
be possible to solve this example with 2833 to the 323 translator. The IETF
suggested this was the right way to go - I am unaware of anyone who did
that. Everyone decided some weird variant of sending it over SIP looked like
a much better idea even though it was not interoperable. Perhaps they were
all insane but people buying equipment convinced vendors to build it. If we
want to standardize something that is going to be widely implemented, I
think we need to keep what is deployed today and why it happened in mind.

It is probably possible to have provider B write a HTTP proxy like thing
that takes posts from A and then relays them on to C and change it's call
control software to rewrite the KPML scripts as they pass through the
signaling proxy/b2bua. But this leads to the the NAT ALG like behavior that
we are trying to avoid.

Cullen

Another scenario similar to this happens when the PSTN GW is a SIP GW that
may support 2833 but it is doing overlap dialing and uses KPML to tell the
UA to keep sending it more digits before media is set up. I don't claim to
fully understand this one so don't ask me too many questions on it :-)

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 20 Aug 2003 10:59:45 -0700

Inline....

> will cause problems to - don't misroute things.

Adam has already given good/likely concrete examples where "bad things" 
can happen.  Unless you can prove that these won't actually happen, 
then I suggest we discard this option and move on.

> some user input stimulus is being sent - STIMULUS is to input what 

I'm fine with this option.  It will work.  Should this NEWMETHOD be 
used for responses and new markup or just responses?  as long as you 
are sending them to the app server and not the UAS in your picture, 
this should be on a new dialog.

> that initiated the script ends.

How long in seconds exactly is that again?  ;-) Ah, you don't know 
unless you are using session timer you say.  Well, unless you are 
requiring session timer, I object on the grounds that my UA can never 
recover lost state with this "implicit subscription" mechanism.

> We all remember that implicit subscribes

also, if you plan to use implicit subscriptions, this will require an 
initial NOTIFY after the initial INVITE.  this has been a remarkable 
PAI for REFER. also, since this is going to a different UA than the UAS 
(if you sent it anyway you would screw up the CSeqs) it needs to be on 
a different dialog, but then you need a way to initiate this dialog 
which gets pretty ugly, since there is no SUBSCRIBE. You would need to 
send a NOTIFY with one tag only, and then complete the dialog in the 
response to the NOTIFY.

I think implicit subs are bad in this case because:
a) the dialog identifiers for the subscription are in a (currently) 
illegal combination of SIP messages
b) the state of the associated dialog is completely decoupled from the 
state of subscription, which makes the Subscription-State header (which 
is supposed to convey BOTH) fairly useless.
c) experience has shown that implicit subs for REFER where a pain to 
implement and only now folks are starting to get it right; this use is 
even more complicated
d) you need a different GRUU for each "subscription"
e) even if you use a GRUU for each "subscription", you have a dialog 
correlation problem in the example I give below.

     UA1            App          Proxy           UA2            UA3
      |              |             |              |              |
      |INVITE------->|             |              |              |
      |              |INVITE------>|              |              |
      |              |App-Info: *  |INVITE------->|              |
      |              |             |App-Info: *   |              |
      |              |             |<---------180-|              |
      |              |<----------------NOTIFY-----|              |
      |              |-----------------200--------|              |
      |              |             |              |              |
      |              |             |INVITE---------------------->|
      |              |             |App-Info: *   |              |
      |              |             |<------------------------180-|
      |              |<---------------------NOTIFY---------------|
      |              |----------------------200------------------|
      |              |             |              |              |

if the header is App-Info: sip:unique-instance23988413@appserver, then 
the appserver still receives requests from multiple UAs.  The NOTIFYs 
are on completely separate new dialogs.  I don't think there is any way 
to correlate the first notify with the first INVITE fork, and the 
second notify with the second INVITE fork.

f) timers are not explicit
...
g) there is no technical reason given why a new method would not work.  
the only objections have been philosophical

!!!FOR GODS SAKE DONT USE IMPLICIT SUBSCRIPTIONS!!!!

> argument that any of them would not work.

I think I have provided ample bad reasons why not to do 1 and 3.

> They send to a URI the AS provided

likewise...

> One of the difficult parts of this is security.

agreed.  this also potentially has the same dialog correlation problem 
that I described above.

>> 2|                |-----INVITE---->|   AS extracts GRUU from INVITE

I don't see how Adam plans to correlate the SUBSCRIBE with the 
INVITE-initiated dialog.  You can't send the SUBSCRIBE on the existing 
dialog, because you will screw up the CSeq space.

btw: If an event package is defined for this, will we allow PUBLISH as 
well?

> I'd be keener on GRUU solutions if GRUU was a solved problem.

we need to solve this problem anyway if you want transfer to work, so 
I'm not especially concerned.

> think 14k of memory is a lot. Real devices are just going to do VXML 

I don't understand how Adam can correlate the REFER (which has to be 
using a different dialog than the original INVITE) with the dialog for 
which you are interested in collecting digits.

thanks,
-rohan

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Aug 2003 17:08:38 -0400

inline.

> evil things. That said, let me describe a scenario that does occur and is

Do these people find KPML objectionable too? No doubt the easiest 
thing is to send INFO within the same dialog. However that is frought 
with real problems. Once you've gotten to the point where its 
something out of dialog, and something that requires you to fetch 
(with http presumably) or look at an embedded script, is http for 
pushing the results worse?

> happy. The development effort to send DTMF over INFO is very low. 

Well, hang on. Its "easy" if its any method within the existing 
dialog. Once its outside of the dialog, whether its SIP or HTTP, this 
seems to be more or less equially "problematic".

It would
> signaling proxy/b2bua. But this leads to the the NAT ALG like behavior that

And how would doing this with SIP solve that? Seems like you would 
still need to modify the KPML scripts. However, instead of receiving 
POSTS and relaying thme to C, you would take SIP NEW-METHODS and relay 
them on to C. Indeed, if these NEW-METHOD requests have the dialog 
identifiers in the body, those need to be rewritten by the server at B.

So, what is the difference?

-Jonathan R.