Subject: [Sipping] dtmfad vs kpml

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Mon, 10 Nov 2003 12:50:58 -0600

Hello,

KPML is clearly the more flexible and robust solution.

If KPML was standard and available, then there would not be a need for the T1 request.

If KPML is stable after this meeting (meaning ready to implement... heading to approval), then the T1 request is moot.

Considering there is not a capability to an obvious problem, one might question whether there are those that do not want a answer???

Regards,

Martin
 
Message: 7
Date: Sun, 09 Nov 2003 21:41:35 -0800
From: Cullen Jennings <[email-masked]>
To: sipping <[email-masked]>
Subject: [Sipping] Why draft-zebarth-sipping-dtmfad?

Seems there have been several other drafts on this problem including one
that is remarkably similar.  Any particular problems this solves that KPML
does not?

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 Nov 2003 17:38:56 -0500

I agree with Cullen and others that the zebarth draft overlaps in its 
entirety with the application interaction work, and in particular the 
KPML component of it.

Why has this solution not been completed yet? Well, many reasons:

1. We are attempting to address a broader problem than just DTMF 
conveyance. DTMF is just one example of stimulus signaling that can 
exist in a sip system. We want to make sure the framework supports not 
just DTMF input, but also web, voice and multi-modal systems.

2. For most DTMF-only applications, rfc2833 provides a fairly good 
solution that is widely implemented and mature. It is costly in some 
situations, such as the long-pound case for calling cards, but it 
works. Therefore, there is a solution available that is standards 
based today. The application interaction framework attempts to clarify 
when this mechanism is appropriate, vs. KPML.

3. One of the requirements which surfaced early on in this activity is 
that we didnt want the notifications to traverse the proxies that 
happened to record-route on the original call setup path. As a result, 
we have been working hard on solutions that would allow us to do that. 
Only recently has the GRUU capability materialized, which now enables 
a network server to initiate an out-of-dialog SUBSCRIBE to the 
endpoint (indeed, without GRUUs, the zebarth draft suffers the same 
problem). This should now resolve the long-standing debate which has 
been the primary holdup of this work.

As a result, I believe we can now move forward swifly on this solution.

-Jonathan R.

Dolly, Martin C, ALABS wrote:

> If KPML is stable after this meeting (meaning ready to implement...
> heading to approval), then the T1 request is moot.
> 
> Considering there is not a capability to an obvious problem, one
> might question whether there are those that do not want a answer???
> 
> 
> Regards,
> 
> Martin
> 
> Message: 7 Date: Sun, 09 Nov 2003 21:41:35 -0800 From: Cullen
> Jennings <[email-masked]> To: sipping <[email-masked]> Subject:
> [Sipping] Why draft-zebarth-sipping-dtmfad?
> 
> 
> Seems there have been several other drafts on this problem
> including one that is remarkably similar.  Any particular problems
> this solves that KPML does not?
> 
> 
> 
> _______________________________________________ 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
> 

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