Subject: RE: [Sipping] App-Interaction: Considering models

From: Adam Roach <[email-masked]>
Date: Thu, 14 Aug 2003 12:30:57 -0500

Cullen Jennings [mailto:[email-masked]] writes:

> > 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
> > 
>
> 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.

Red herring. The exact same issue applies to any of the cases you
describe. In other words, for the following call flow, you need
to get the UAC credentials for step 5:

> UAC           App Server          UAS
> 1|-----INVITE---->|                |
> 2|                |-----INVITE---->|
> 3|                |<-----200-------|
> 4|<-----200-------|                |
> 5|---SIP MESG---->|                |
> 6|<-----200-------|                |

/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: Adam Roach <[email-masked]>
Date: Thu, 14 Aug 2003 15:08:50 -0500

Cullen Jennings writes:

> What does the implicit subscribe in refer do?

To prevent expiration, it sends explicit SUBSCRIBE
messages to refresh the subscription.

/a

---

From: [email-masked]
Date: Fri, 15 Aug 2003 11:46:45 +0300

I tend to strongly agree with Adam; unless we plan to write an RFC that contains the top 10 tests for implicit subscriptions, we need to forbid it.

I personally don't see any problem with sending a SUBSCRIBE explicitly. An extra round trip delay, so what?

My other favourite is a new method similar to NOTIFY, like REPORT. We have done this in the past were a method semantics are not quite right for one thing and we create a new method. Take for example REGISTER and PUBLISH.

Regards,
Hisham

> -----Original Message-----
> From: ext Adam Roach [mailto:[email-masked]]
> Sent: Friday, August 15, 2003 2:12 AM
> To: 'Cullen Jennings'; Adam Roach; sipping; Jonathan Rosenberg
> Subject: RE: [Sipping] App-Interaction: Considering models
> 
> 
> > 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.
> 
> It's not simple dogma; there are real problems here. I've
> cited a few of them (and, as I point out in another message,
> Jonathan's rebuttal is somewhat lacking in the area of
> duration; also, I still plan to respond on the correlation
> issue, because I think his rebuttal glosses over the
> details).
> 
> Can these problems be fixed? Probably. REFER provides an
> existence proof that implicit subscriptions[1] can be made
> to work with enough crafting. After it's said and done,
> do we regret choosing that path? I do. Robert does. Do we
> want to learn from our mistakes?
> 
> 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.
> 
> /a
> 
> [1] To be clear, I mean "subscriptions put in place via some
>     other mechanism than that described in RFC 3265."
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 15 Aug 2003 17:34:52 -0700

Cullen Jennings wrote:
> 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.

The RFC2833 to H.323 translator idea is hightly dubious to me
and I really don't see where that translater would sit to be able
to perform this task. It would seem to have to sit at the media 
termination, which would imply that the endpoint supports RFC2833
in the first place.

Certainly, support for RFC2833 is included in H.323 starting with 
version 4. So it would probably be much easier to support that than
the translator idea.

> 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 :-)

This is kind of a weird scenario. Wouldn't you just do the digit collection
at the UA, then make the call (en-bloc) to the PSTN gateway? And then it's
up
to the PSTN GW to do overlap sending if it pleases.

If the UA can't do the digit collection and insists on doing overlap
(because
it is itself a PSTN gateway for example), then the normal overlap sending 
procedures should apply (with the sequential INVITEs).

I don't think we should use KPLM for dialling.

---

From: Adam Roach <[email-masked]>
Date: Wed, 20 Aug 2003 17:39:12 -0500

Rohan Mahy [mailto:[email-masked]] writes:

> using a new method does not actually suffer from the dialog 
> correlation problem.  You are sending a feedback or stimulus
> body in the new method, which just needs to contain a session-id
> or dialog-information to describe the dialog for which the
> feedback/stimulus is associated.  

You are correct. Ignore my previous objection.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Aug 2003 16:28:44 -0500

Jonathan Rosenberg [mailto:[email-masked]] wrote:

> I would argue that the App-Info header is what is actually creating 
> the state, and the state of this thing exists for the duration of the 
> dialog. The results of the user input are the state, but they aren't 
> normally sent anywhere. Rather, they are monitored through an 
> explicit subscription from the application server.

I thought I had mentioned it earlier (it was always in the back
of my mind), but the intention, in using explicit subscriptions,
was to not have an "App-Info" header. The SUBSCRIBE itself carries
the KPML script (which, upon close examination, is really more of
a filter than a script, so this usage seems appropriate).

So, I would argue that the INVITE exchange is what actually creates
this state. In other words, it makes just as much sense to subscribe
to this state as it does to subscribe to the state of a dialog.

> In this model, I suppose an explicit subscription makes 
> sense, but the whole thing seems convoluted. Why bother to
> explicitly subscribe to something when you created the state
> in the first place, and you are the only one who is interested
> in finding out about it?

Ah, but what if you *aren't* the only one interested in
finding out about it?

What if I go through some proxy that is doing some sort of
prepaid service [1] with two-stage dialing. If I want to end
my current call and start a new one, I send a long pound.
On the other hand, the thing that I've ended up calling has
a proxy that wants my keypresses also, because it's some
sort of call center that needs me to type in my account number.

It sure seems that it would be much, much simpler to consider
them as subscribing to the same state (keypad events) with
different filters, than to consider the two different "App-Info"
headers in the INVITE 200 response as creating two separate pieces
of state associated with (n.b. *not* "sent in") the dialog.

What is *really* nice about this is that one can envision future
systems where parties not on the call path (but still rendered to
the user through some other means) can tap this state without
additional specification; all they need is some mechanism to get
the dialog identifiers.

/a

[1] Don't get hung up on the fact that I said something that
    has billing implications. The point is that there might
    be two proxies wanting to know about keypresses, and this
    is an easily grasped system with which many people are
    already familiar.

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Aug 2003 16:13:12 -0500

Okay, this thread appears to have stalled.

I think everyone has pretty much laid all the cards they
have on the table. To summarize:

1) Implicit [1] subscription:
   - Has correlation problems in the forking case
   - Has technical problems inherent in implicit [1] subscriptions
   - Is fewer messages than an explicit [2] subscription
   - Requires additional mechanism (e.g. HTTP) to
     retrieve KPML scripts.
   - Changes normal protocol machinery by setting up a virgin
     dialog using NOTIFY message
   
2) MESSAGE:
   - Has correlation problems in the forking case
   - Arguably has significantly different semantics
     than is needed for app-interaction
   - Can have detrimental, user-visible effects
   - Requires additional mechanism (e.g. HTTP) to
     retrieve KPML scripts.

3) HTTP GET/POST:
   - Has correlation problems in the forking case
   - May interact poorly with firewalls and NATs

4) NEW_METHOD:
   - No technical objections raised
   - Semantically, has some overlap with NOTIFY
   - Requires additional mechanism (e.g. HTTP) to
     retrieve KPML scripts.

5) Explicit [2] subscription:
   - No technical objections raised
   - Is more complicated than NEW_METHOD
   - Relies on GRUU solution (which should finish
     before app-interaction)

Have I left anything off?

/a

[1] By "implicit", I mean "subscriptions put in place
    via some other mechanism than those described in
    RFC 3265."

[2] By "explicit", I mean "subscriptions put in
    place via the mechanisms described in RFC 3265."

---

From: Adam Roach <[email-masked]>
Date: Wed, 27 Aug 2003 13:53:16 -0500

> Okay, this thread appears to have stalled.

n.b.: I sent this on Monday, when the thread had, indeed,
appeared to have stalled. I guess this particular message
got caught in a mailspool somewhere...

/a