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

From: "Steve Fisher" <[email-masked]>
Date: Thu, 21 Aug 2003 14:04:07 -0400

I would personally prefer "new method", and not explicit use of
SUBSCRIBE, since it appears to me that with SUBSCRIBE there is a
potential delay between the INVITE that establishes the dialog and the
SUBSCRIBE that applies the KPML, and also additional complexity. I do
agree that GRUU/SUB/NOT is the next best alternative.

Steve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adam Roach
Sent: Wednesday, August 20, 2003 7:13 PM
To: 'Cullen Jennings'; Adam Roach; 'Rohan Mahy'
Cc: sipping; Jonathan Rosenberg
Subject: RE: [Sipping] App-Interaction: Considering models

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

> So are we coming to the conclusion that the
> GRUU/SUB/NOT is the right way to go? I can try
> and flesh out some details on this if we are.

Personally, I now favor this method, since I consider
the http correlation issue that we've discussed to
be a non-starter. I don't think it's unsolvable; I
just am wary of solutions that obviously need hacks,
even when viewed at the mile-high level.

However, my arguments for preferring explicit
use of SUBSCRIBE over a new method are, at this point,
largely philosophical, not technical. I'm not
certain that discussion has played out completely
yet.

/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: "Eric Burger" <[email-masked]>
Date: Fri, 29 Aug 2003 16:33:21 -0400

My predisposition to not using SUBSCRIBE came from a desire to keep SUBSCRIBE related to things that, as you say, exist.

My comments arose in the context of using SUBSCRIBE to do work, like play a prompt.

I, too, see the digit detection operation as reporting on events.  It is a bit different in that we're not really changing the state of the device.  The device either can do digit detection or it can't.  If it can, then it intrinsically can report events.

I will rev the new ietf-00 KPML document to get it deposited in time so we can have some extra time on -01.  Please don't shoot me on the document -- it's not quite ready yet.  However, it should give an indication of direction.

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Mon, August 25, 2003 5:09 PM
> To: Cullen Jennings
> Cc: Adam Roach; sipping
> Subject: Re: [Sipping] App-Interaction: Considering models
> 
> 
> inline.
> 
> Cullen Jennings wrote:
> 
> > 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.
> 
> 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?
> 
> > 
> > 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. 
> 
> 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
> > 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.
> 
> 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.
> 
> 
> -- 
> 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
> 
>