Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt

From: Eric Burger <[email-masked]>
Date: Wed, 8 Sep 2010 10:34:54 -0400

Part of me says, "this makes sense - let's pick one and only one."

Another part of me says, "INFO is always ad hoc. Infinitely better to get the documentation out there. Those against *allowing* Hadriel to write an Informational document clearly have too much time on their hands."

On Aug 31, 2010, at 6:27 AM, Gonzalo Camarillo wrote:

> Hi,
> 
> what we need to discuss here is what is our final goal. Adding three new
> documents (the existing Cisco way, the existing 3GPP way, and the
> improved INFO-based way) describing how to carry DTMF may not be the
> best way forward. Let's focus on discussing the current situation, what
> problems or issues need to be resolved, and the requirements we need to
> meet. Let's be pragmatic and produce something that will actually
> improve the current situation out there.
> 
> Thanks,
> 
> Gonzalo
> 
> On 24/08/2010 6:51 PM, Paul Kyzivat wrote:
>> Maybe we should ask our ADs if they have an opinion about this.
>> 
>> 	Thanks,
>> 	Paul
>> 
>> Hadriel Kaplan wrote:
>>> 
>>>> -----Original Message-----
>>>> From: Paul Kyzivat [mailto:[email-masked]]
>>>> Sent: Monday, August 23, 2010 6:02 PM
>>>> To: Hadriel Kaplan
>>>> 
>>>> That reduces things somewhat. But if everybody that supports the package
>>>> also supports the legacy approach, what is the win?
>>> 
>>> The legacy mode has no published standards document defining it.  I thought when the info-packages work was started, DTMF-in-info was one of the main drivers.  But I take your point - if people would prefer to just document it as it is today (sans info-packages), I can change the draft to just be that.  I'm cool with either way (defining the current dtmf-relay as a legacy mode was Option-2).
>>> 
>>> -hadriel 
>>> 
>> 
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 8 Sep 2010 22:12:29 +0200

Hi,

I see no reason why we should describe existing legacy INFO mechanisms for DTMF - or for anything else. The reason why we produced the Info Package mechanism was to solve the problems associated with legacy INFO, so I see no reason why we should "encourage" legacy INFO usages by describing how they work...

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Eric Burger [[email-masked]]
Sent: Wednesday, September 08, 2010 5:34 PM
To: Gonzalo Camarillo; Kaplan Hadriel
Cc: dispatch list mailing
Subject: Re: [dispatch] I-D     Action:draft-kaplan-dispatch-info-dtmf-package-00.txt

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 23 Sep 2010 00:22:16 +0200

I don't think we are going to end up with a new IETF consensus based specification to do this. To do this would be going against the ethos of trying to get usages of INFO registered, and essentially there are too many different ways of doing this out there.

So if you have a DTMF usage that you want to register as a INFO package, then register it. It will either be registered or not based on the IANA rules provided in info-events. If you need a published specification using the IETF route to do that, then the route is surely RFC individual submission, rather than pushing it through and trying to get consensus on it.

regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
Sent: Wednesday, August 25, 2010 5:51 AM
To: Christer Holmberg; Paul Kyzivat (pkyzivat)
Cc: [email-masked]; Hadriel Kaplan
Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt

Christer,

I haven't seen reply to my second question:

"2) Whether current IETF standard (KPML) has to be deprecated for the proposed DTMF Info packages. Both KPML, DTMF Info package are SIP signaling based mechanism for DTMF relay."

It is not clear to me why IMS take different stance than current IETF standard (KPML) for DTMF relay. In case of the analysis has done for not selecting KPML in IMS, please let us know as it will help us to proceed in the INFO based DTMF package direction in IETF.

Also Currently, IANA registration is yet to be done for DTMF Info package and so, the modification is possible.

Thanks
Partha
________________________________
From: Christer Holmberg [mailto:[email-masked]]
Sent: Wed 8/25/2010 9:04 AM
To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]; Hadriel Kaplan; Muthu ArulMozhi Perumal (mperumal)
Subject: RE: [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt

Hi,

>1) whether 3GPP DTMF Info package is in the state to be accepted as IETF standards.

The Info Package registration procedure requires an expert review, which purpose is to ensure that the Info Package does not break the SIP protocol etc. I assume such review will take place when the package is registered with IANA.

Regards,

Christer

________________________________

        From: Christer Holmberg [mailto:[email-masked]]
        Sent: Wed 8/25/2010 8:45 AM
        To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat)
        Cc: [email-masked]; Hadriel Kaplan; Muthu ArulMozhi Perumal (mperumal)
        Subject: RE: [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt

        Hi,

        >In case IMS needs new INFO based DTMF relay mechanism, I agree that it is the valid requirement and we need to evaluate it. Before concluding about new
        >INFO based mechanism in IMS, Please throw the light for not selecting KPML in IMS. I'm comparing KPML vs INFO based mechanism as both are based on SIP
        >signaling based mechanism. KPML has limited deployment as mentioned in Hadriel Info draft but new INFO package is yet to be defined. It is better to have
        >the single active IETF SIP signaling based dtmf-relay mechanism rather than producing more standards wherein implementers will completely confused which
        >one to select.
        >
        >As Muthu mentioned, I also heard about KPML deployment issues but the legacy INFO based dtmf-relay has lot more caveats. I guess that Info package is
        >designed as generic as KPML, and then both KPML and INFO may look heavyweight.

        The 3GPP DTMF Info Package is very simple.

        Regards,

        Christer

        ________________________________

                From: [email-masked] on behalf of Paul Kyzivat (pkyzivat)
                Sent: Wed 8/25/2010 12:17 AM
                To: Christer Holmberg
                Cc: [email-masked]; Hadriel Kaplan
                Subject: Re: [dispatch]I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt

                Christer Holmberg wrote:
                > Hi,
                >
                > I think it is strange to reject something based on a claim there already exists a number of legacy ways of there. Not everyone has implemented the same (if any) of them, and the whole purpose of the Info Package framework is to come up with a mechanism for which the usage can be negotiated.
                >
                > And, as I said earlier, at least in IMS an Info Package is being used for DTMF transport. It is currently defined in 3GPP specifications, but there shouldn't be anything IMS specific about the package itself.

                I wasn't asserting a general principle.
                I was talking about this particular mechanism.

                If there is yet another dtmf package, then I guess we can consider the
                pros/cons of it. Those are probably best assessed by those who use the
                existing one and/or might use whatever info package you might propose to
                replace it.

                We clearly suffer from a surplus of ways to convey dtmf.
                While its not impossible to argue than another one would improve the
                situation, it is going to be a hard sell.

                OTOH, the more there are the more case it makes for having an SBC in the
                path to "fix" the interoperability. We sell them, so maybe I should be
                cheering on every new one as a way to boost sales.

                        Thanks,
                        Paul

                >> From: [email-masked]
                >> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
                >> Sent: 24. elokuuta 2010 18:51
                >> To: Hadriel Kaplan
                >> Cc: [email-masked]
                >> Subject: Re: [dispatch] I-D
                >> Action:draft-kaplan-dispatch-info-dtmf-package-00.txt
                >>
                >>>> That reduces things somewhat. But if everybody that supports the
                >>>> package also supports the legacy approach, what is the win?
                >>> The legacy mode has no published standards document
                >> defining it.  I thought when the info-packages work was
                >> started, DTMF-in-info was one of the main drivers.  But I
                >> take your point - if people would prefer to just document it
                >> as it is today (sans info-packages), I can change the draft
                >> to just be that.  I'm cool with either way (defining the
                >> current dtmf-relay as a legacy mode was Option-2).
                >>> -hadriel
                >>>

---

From: Adam Roach <[email-masked]>
Date: Wed, 22 Sep 2010 17:46:55 -0500

On 9/22/10 5:22 PM, DRAGE, Keith (Keith) wrote:
> So if you have a DTMF usage that you want to register as a INFO 
> package, then register it. It will either be registered or not based 
> on the IANA rules provided in info-events. If you need a published 
> specification using the IETF route to do that, then the route is 
> surely RFC individual submission, rather than pushing it through and 
> trying to get consensus on it.
>

+1

/a