Subject: [dispatch] 3GPP DTMF Package

From: Cullen Jennings <[email-masked]>
Date: Sat, 23 Oct 2010 07:55:46 -0600

Christer, can you send me a bit more info about this - perhaps a pointer to the 3GPP spec. Do you know if anyone is following up with the registration of this?

Thanks, Cullen

On Aug 23, 2010, at 6:53 PM, Christer Holmberg wrote:

> 
> Hi,
> 
> A while ago, 3GPP also defined a DTMF package. For some reason it hasn't been registered with IANA yet, but I have requested to ensure that it happens.
> 
> Regards,
> 
> Christer

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 23 Oct 2010 08:10:35 -0600

Uh, same as Paul, sorry, ignore my previous email. Don't know how I missed this on first search. Thank you for sending the pointer to this. 

What is the sate of this 3GPP doc and what is going on with the registration?

Thanks, Cullen

On Aug 24, 2010, at 9:57 PM, Christer Holmberg wrote:

> 
> Hi,
> 
> The package definition can be found in Annex P of 3GPP TS 24.229:
> 
> http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-a00.zip
> 
> The MIME body used by the package to transport the digits is defined in Annex G of 3GPP TS 29.163 (it re-uses a body used for overlap dialling, in case the wording confuses): 
> 
> http://www.3gpp.org/ftp/Specs/archive/29_series/29.163/29163-920.zip
> 
> Regards,
> 
> Christer
> 
> 
> 
>> -----Original Message-----
>> From: Muthu ArulMozhi Perumal (mperumal) [mailto:[email-masked]] 
>> Sent: 25. elokuuta 2010 6:47
>> To: Christer Holmberg; Parthasarathi R (partr); Paul Kyzivat 
>> (pkyzivat)
>> Cc: [email-masked]; Hadriel Kaplan
>> Subject: RE: 
>> [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt
>> 
>> Can you please provide the pointer to the 3GPP spec 
>> describing this DTMF INFO package?
>> 
>> thanks,
>> Muthu
>> 
>> |-----Original Message-----
>> |From: Christer Holmberg [mailto:[email-masked]]
>> |Sent: Wednesday, August 25, 2010 9:05 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
>> |
>> |	        > Regards,
>> |	        >
>> |	        > Christer
>> |	        >
>> |	        >
>> |	        >
>> |	        >> -----Original Message-----
>> |	        >> 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
>> |	        >>
>> |	        >> 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
>> |	        >>
>> |	        _______________________________________________
>> |	        dispatch mailing list
>> |	        [email-masked]
>> |	        https://www.ietf.org/mailman/listinfo/dispatch
>> |
>> |
>> |
>> 
>> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Oct 2010 07:40:50 +0200

Hi,

>What is the sate of this 3GPP doc and what is going on with the registration?

The document is stable. A reason the package hasn't been registered yet might be that people assume the info-event draft has to become RFC first.

But, if that is not the case, I can inform people that the package can be registered.

Regards,

Christer

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 27 Oct 2010 16:38:09 -0600

> But, if that is not the case, I can inform people that the package can be registered.

My understanding of the process is that the IANA registration for this could be done as soon as IESG had approved info-events. And that has already happened so I think this  could start any time. 

You can see that IANA has already created the registry at 
http://www.iana.org/assignments/sip-parameters

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Oct 2010 07:29:53 +0200

Hi, 

>>>Uh, same as Paul, sorry, ignore my previous email. Don't 
>>>know how I missed this on first search. Thank you for sending 
>>>the pointer to this.
>>> 
>>The document is stable. A reason the package hasn't been 
>>registered yet might be that people assume the info-event 
>>draft has to become RFC first.
>> 
>My understanding of the process is that the IANA registration 
>for this could be done as soon as IESG had approved 
>info-events. And that has already happened so I think this  
>could start any time. 
> 

Yes. I expect the registration to take place after the next 3GPP CT1 meeting (which is held the week after IETF).

Regards,

Christer