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

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 20 Aug 2010 11:48:08 -0400

Howdy,
I've submitted an I-D for a DTMF Info-Package, registering it following the rules of draft-ietf-sipcore-info-events-08.  The info-events draft is not in the publication queue yet - it's held up by a single DISCUSS, but I expect that to be resolved.

With regards to my I-D, I'd like to go through A-D sponsored instead of a new WG, for obvious reasons.

Any comments/flames are appreciated.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 20 Aug 2010 13:31:34 -0400

Ooops, forgot the link:

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : A Session Initiation Protocol (SIP) INFO Package for Dual-Tone Multi-Frequency (DTMF) Events
	Author(s)       : H. Kaplan
	Filename        : draft-kaplan-dispatch-info-dtmf-package-00.txt
	Pages           : 7
	Date            : 2010-08-20

The SIP INFO request method now supports explicit indication and exchange of specified application information.  Such usages are documented as an "INFO Package", following the requirements outlined in [info-packages].  This document specifies one such SIP INFO Package, for the purpose of indicating DTMF signals.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-info-dtmf-package-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hadriel Kaplan
> Sent: Friday, August 20, 2010 11:48 AM
> To: [email-masked]
> Subject: [dispatch] I-D Action: draft-kaplan-dispatch-info-dtmf-package-
> 00.txt
> 
> Howdy,
> I've submitted an I-D for a DTMF Info-Package, registering it following
> the rules of draft-ietf-sipcore-info-events-08.  The info-events draft is
> not in the publication queue yet - it's held up by a single DISCUSS, but I
> expect that to be resolved.
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 20 Aug 2010 23:28:58 +0530

Hi Hadriel,

There draft doesn't provide a method to indicate the start of a DTMF
event and requires the INFO to be generated only when the user releases
the button. So, in the following scenario where the B2BUAs support only
the INFO method of sending DTMF events, if the user presses the long
'#', which typically lasts for 2 - 4 sec, the app server at the far end
would detect the long '#' only after 6 - 12 sec. 

user--[PSTN-GW]--SIP--[B2BUA]--SIP--[B2BUA]--[PSTN-GW]--[B2BUA]--[PSTN
GW]--app

Would it be better to provide a way to indicate the start of a DTMF
event so that the far end can start playing it as soon as the user
presses the button? It could be indicated using an empty value for
duration, like this: 

Signal= #
Duration= 

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf
|Of Hadriel Kaplan
|Sent: Friday, August 20, 2010 9:18 PM
|To: [email-masked]
|Subject: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-
|00.txt
|
|Howdy,
|I've submitted an I-D for a DTMF Info-Package, registering it following
the
|rules of draft-ietf-sipcore-info-events-08.  The info-events draft is
not in
|the publication queue yet - it's held up by a single DISCUSS, but I
expect
|that to be resolved.
|
|With regards to my I-D, I'd like to go through A-D sponsored instead of
a
|new WG, for obvious reasons.
|
|Any comments/flames are appreciated.
|
|-hadriel
|_______________________________________________
|dispatch mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/dispatch

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 20 Aug 2010 14:25:39 -0400

You tell me - afaik it's Cisco's dtmf-relay that everyone's copied (and that I'm proposing be an info-package, so it can be "legal"). 
:)

-hadriel

> From: Muthu ArulMozhi Perumal (mperumal) [mailto:[email-masked]]
> Sent: Friday, August 20, 2010 1:59 PM
> To: Hadriel Kaplan; [email-masked]
> Subject: RE: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-
> package-00.txt
> 
> Hi Hadriel,
>

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Mon, 23 Aug 2010 11:28:24 +0530

Yes, this is exactly what Cisco implemented 9 years back and hasn't
undergone any change since then. But I am not sure what purpose it would
solve by just calling it an IETF standard, without addressing some of
its limitations for the Internet community.

It would be desirable for this DTMF method to address 2 kinds of
deployments:
1. PSTN interworking, where it provides the ability for the receiver to
generate the DTMF tone in-sync with the user pressing and releasing the
button. However, I don't think we need to achieve such precise timing as
H.245 signal/signalUpdate messages, by carrying RTP timestamp etc, since
the purpose would be to only avoid the detection delay at the receiver.

2. No PSTN interworking, where it provides the ability for a SIP
soft-phone to send a DTMF digit to an app server, without having to
bother about the duration to the tone. 

Muthu

|-----Original Message-----
|From: Hadriel Kaplan [mailto:[email-masked]]
|Sent: Friday, August 20, 2010 11:56 PM
|To: Muthu ArulMozhi Perumal (mperumal); [email-masked]
|Subject: RE: [dispatch] I-D
Action:draft-kaplan-dispatch-info-dtmf-package-
|00.txt
|
|
|You tell me - afaik it's Cisco's dtmf-relay that everyone's copied (and
that
|I'm proposing be an info-package, so it can be "legal").
|:)
|
|-hadriel
|
|> -----Original Message-----
|> From: Muthu ArulMozhi Perumal (mperumal) [mailto:[email-masked]]
|> Sent: Friday, August 20, 2010 1:59 PM
|> To: Hadriel Kaplan; [email-masked]
|> Subject: RE: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-
|> package-00.txt
|>
|> Hi Hadriel,
|>
|> There draft doesn't provide a method to indicate the start of a DTMF
|> event and requires the INFO to be generated only when the user
releases
|> the button. So, in the following scenario where the B2BUAs support
only
|> the INFO method of sending DTMF events, if the user presses the long
|> '#', which typically lasts for 2 - 4 sec, the app server at the far
end
|> would detect the long '#' only after 6 - 12 sec.
|>
|>
user--[PSTN-GW]--SIP--[B2BUA]--SIP--[B2BUA]--[PSTN-GW]--[B2BUA]--[PSTN
|> GW]--app
|>
|> Would it be better to provide a way to indicate the start of a DTMF
|> event so that the far end can start playing it as soon as the user
|> presses the button? It could be indicated using an empty value for
|> duration, like this:
|>
|> Signal= #
|> Duration=
|>
|> Muthu
|>
|> |-----Original Message-----
|> |From: [email-masked] [mailto:[email-masked]]
On
|> Behalf
|> |Of Hadriel Kaplan
|> |Sent: Friday, August 20, 2010 9:18 PM
|> |To: [email-masked]
|> |Subject: [dispatch] I-D
Action:draft-kaplan-dispatch-info-dtmf-package-
|> |00.txt
|> |
|> |Howdy,
|> |I've submitted an I-D for a DTMF Info-Package, registering it
following
|> the
|> |rules of draft-ietf-sipcore-info-events-08.  The info-events draft
is
|> not in
|> |the publication queue yet - it's held up by a single DISCUSS, but I
|> expect
|> |that to be resolved.
|> |
|> |With regards to my I-D, I'd like to go through A-D sponsored instead
of
|> a
|> |new WG, for obvious reasons.
|> |
|> |Any comments/flames are appreciated.
|> |
|> |-hadriel
|> |_______________________________________________
|> |dispatch mailing list
|> [email-masked]
|> |https://www.ietf.org/mailman/listinfo/dispatch

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 23 Aug 2010 12:03:13 -0400

The reason I'm proposing to generate an RFC for it, without substantively changing it, is:

1) Stop it from being a proprietary (albeit industry defacto) mechanism.
2) Register the MIME type name.
3) Provide a static, numbered, public document for implementers and users to reference, as opposed to a specific company's changing config-documentation URLs.

-hadriel

> Sent: Monday, August 23, 2010 1:58 AM
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Aug 2010 12:21:03 -0400

Hadriel,

I think this is not as benign as it seems. The problem is that even 
though it is *essentially* the same, it is not *exactly* the same as 
what is currently implemented in the field. Hence moving to this also 
requires *some* (small) effort. And there will be things that still do 
it the old way. So there are interop considerations to take into account.

For a data point, in Cisco we have *five* mechanisms (that I know of) 
for DTMF transport in sip that we support and use one way or another. 
There are complex negotiation and configuration mechanisms for deciding 
what to use, and we often have to convert between them. This proposal 
would just increase that number from 5 to 6.

So lets not do it without careful consideration.

	Thanks,
	Paul

---

From: Peter Musgrave <[email-masked]>
Date: Mon, 23 Aug 2010 12:23:25 -0400

HI Hadriel,

I concur. I would like to have it written down somewhere more or less "as-is".

Peter Musgrave

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 23 Aug 2010 14:17:44 -0400

The goal is to make it exactly the same.  Obviously having it be an info-package to begin with changes it, simply due to the "negotiation" and the info-package header.  However, my assumption is that info-packages can be used by static configuration without negotiation (as anything can by local configuration), and thus if provisioned it can work like today... yes there would be an info-package header in the INFO (unless static configuration overrides that too), but in theory it would be ignored by the legacy receiver and just processed as a dtmf-relay.  I meant to actually include a description of that in the draft, but just realized I forgot to add it.

Option-2 is to change the draft to define a "legacy INFO usage" as described in draft-ietf-sipcore-info-events-08, and just register the MIME type and describe the syntax and semantics.  Since "application/dtmf-relay" is unambiguous for the INFO request's purpose, and it appearing in the Accept header for the INVITE is also unambiguous, it avoids the issues people have with using INFO.

-hadriel

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, August 23, 2010 12:21 PM
> To: Hadriel Kaplan
>

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 24 Aug 2010 00:38:45 +0530

The motivation looks good. However, I am not sure why it should be
standardized 'as is' with known limitations/issues, when we can make
slight modifications to make it more valuable.

Muthu

|-----Original Message-----
|From: Hadriel Kaplan [mailto:[email-masked]]
|Sent: Monday, August 23, 2010 9:33 PM
|To: Muthu ArulMozhi Perumal (mperumal); [email-masked]
|Subject: RE: [dispatch] I-D
Action:draft-kaplan-dispatch-info-dtmf-package-
|00.txt
|
|The reason I'm proposing to generate an RFC for it, without
substantively
|changing it, is:
|
|1) Stop it from being a proprietary (albeit industry defacto)
mechanism.
|2) Register the MIME type name.
|3) Provide a static, numbered, public document for implementers and
users to
|reference, as opposed to a specific company's changing
config-documentation
|URLs.
|
|-hadriel
|
|> -----Original Message-----
|> From: Muthu ArulMozhi Perumal (mperumal) [mailto:[email-masked]]
|> Sent: Monday, August 23, 2010 1:58 AM
|>
|> Yes, this is exactly what Cisco implemented 9 years back and hasn't
|> undergone any change since then. But I am not sure what purpose it
would
|> solve by just calling it an IETF standard, without addressing some of
|> its limitations for the Internet community.
|>
|> It would be desirable for this DTMF method to address 2 kinds of
|> deployments:
|> 1. PSTN interworking, where it provides the ability for the receiver
to
|> generate the DTMF tone in-sync with the user pressing and releasing
the
|> button. However, I don't think we need to achieve such precise timing
as
|> H.245 signal/signalUpdate messages, by carrying RTP timestamp etc,
since
|> the purpose would be to only avoid the detection delay at the
receiver.
|>
|> 2. No PSTN interworking, where it provides the ability for a SIP
|> soft-phone to send a DTMF digit to an app server, without having to
|> bother about the duration to the tone.
|>
|> Muthu
|>
|> |-----Original Message-----
|> |From: Hadriel Kaplan [mailto:[email-masked]]
|> |Sent: Friday, August 20, 2010 11:56 PM
|> |To: Muthu ArulMozhi Perumal (mperumal); [email-masked]
|> |Subject: RE: [dispatch] I-D
|> Action:draft-kaplan-dispatch-info-dtmf-package-
|> |00.txt
|> |
|> |
|> |You tell me - afaik it's Cisco's dtmf-relay that everyone's copied
(and
|> that
|> |I'm proposing be an info-package, so it can be "legal").
|> |:)
|> |
|> |-hadriel
|> |
|> |> -----Original Message-----
|> |> From: Muthu ArulMozhi Perumal (mperumal)
[mailto:[email-masked]]
|> |> Sent: Friday, August 20, 2010 1:59 PM
|> |> To: Hadriel Kaplan; [email-masked]
|> |> Subject: RE: [dispatch] I-D
Action:draft-kaplan-dispatch-info-dtmf-
|> |> package-00.txt
|> |>
|> |> Hi Hadriel,
|> |>
|> |> There draft doesn't provide a method to indicate the start of a
DTMF
|> |> event and requires the INFO to be generated only when the user
|> releases
|> |> the button. So, in the following scenario where the B2BUAs support
|> only
|> |> the INFO method of sending DTMF events, if the user presses the
long
|> |> '#', which typically lasts for 2 - 4 sec, the app server at the
far
|> end
|> |> would detect the long '#' only after 6 - 12 sec.
|> |>
|> |>
|>
user--[PSTN-GW]--SIP--[B2BUA]--SIP--[B2BUA]--[PSTN-GW]--[B2BUA]--[PSTN
|> |> GW]--app
|> |>
|> |> Would it be better to provide a way to indicate the start of a
DTMF
|> |> event so that the far end can start playing it as soon as the user
|> |> presses the button? It could be indicated using an empty value for
|> |> duration, like this:
|> |>
|> |> Signal= #
|> |> Duration=
|> |>
|> |> Muthu
|> |>
|> |> |-----Original Message-----
|> |> |From: [email-masked]
[mailto:[email-masked]]
|> On
|> |> Behalf
|> |> |Of Hadriel Kaplan
|> |> |Sent: Friday, August 20, 2010 9:18 PM
|> |> |To: [email-masked]
|> |> |Subject: [dispatch] I-D
|> Action:draft-kaplan-dispatch-info-dtmf-package-
|> |> |00.txt
|> |> |
|> |> |Howdy,
|> |> |I've submitted an I-D for a DTMF Info-Package, registering it
|> following
|> |> the
|> |> |rules of draft-ietf-sipcore-info-events-08.  The info-events
draft
|> is
|> |> not in
|> |> |the publication queue yet - it's held up by a single DISCUSS, but
I
|> |> expect
|> |> |that to be resolved.
|> |> |
|> |> |With regards to my I-D, I'd like to go through A-D sponsored
instead
|> of
|> |> a
|> |> |new WG, for obvious reasons.
|> |> |
|> |> |Any comments/flames are appreciated.
|> |> |
|> |> |-hadriel
|> |> |_______________________________________________
|> |> |dispatch mailing list
|> |> [email-masked]
|> |> |https://www.ietf.org/mailman/listinfo/dispatch

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Aug 2010 15:19:38 -0400

> The goal is to make it exactly the same.  Obviously having it be an info-package to begin with changes it, simply due to the "negotiation" and the info-package header.  However, my assumption is th…

Yes, having it be an info-package changes it.
If this is introduced, we will have those that support it (P) and those 
that don't. (NP) We will also have those that support the legacy INFO 
way of doing DTMF (L) and those that don't. (NL) That immediately gives 
four different kinds of UAs that we then need to consider interop among:

NP-NL
NP-L
P-NL
P-L

That gives 16 cases to consider interop for:

UAC	UAS

NP-NL	*	(Not an interesting case - no DTMF will be used.)

NP-L	NP-NL	(Legacy DTMF will be sent and ignored.)

NP-L	NP-L	(Legacy DTMF will be sent and honored.)

NP-L	P-NL	(Legacy DTMF will be sent and ignored by a device
		that does DTMF.)

NP-L	P-L	(Legacy DTMF will be sent and honored.)

P-NL	NP-NL	(The info package will be offered and ignored.
		DTMF will not be used.)

P-NL	NP-L	(The info package will be offered and ignored.
		DTMF will not be used, by a device that does DTMF.)

P-NL	P-NL	(The info package will be offered and accepted.
		The DTMF package will be used.)

P-NL	P-L	(The info package will be offered and accepted.
		The DTMF package will be used.)

P-L	NP-NL	(The info package will be offered and ignored.
		Legacy DTMF will be sent and ignored.)

P-L	NP-L	(The info package will be offered and ignored.
		The UAC will fall back to sending legacy DTMF
		which will be accepted.)

P-L	P-NL	(The info package will be offered and accepted.
		The DTMF package will be used.)

P-L	P-L	(The info package will be offered and accepted.
		The DTMF package will be used.)

The bottom line is that as long as there are things that support the 
legacy way and not the new info-package way there will be interop 
issues. And those that do support the new info-package way should still 
*also* support the legacy way to maximize interop when possible.

Its less trouble to get people to support the old legacy way, if they 
really want it. But once we start talking about that, there will be 
demand to "improve" it, because it has a lot of limitations. That will 
make more of a mess.

> Option-2 is to change the draft to define a "legacy INFO usage" as described in draft-ietf-sipcore-info-events-08, and just register the MIME type and describe the syntax and semantics.  Since "app…

Perhaps we can find an old draft definition of this legacy usage.
(I don't know if it was ever published, but it seems likely.)
If so, maybe we can republish it as HISTORIC, as was recently done with 
the Diversion header draft.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Aug 2010 15:41:58 -0400

> slight modifications to make it more valuable.

If we start to make mods to "improve" it then we will probably arrive at 
something similar to KPML.

I would offer the following questions:

- do people have a problem with DTMF now,
   *other* than deciding which of the many techniques to use,
   or wishing that you peer supported the existing technique
   that you want to use???

- would yet another DTMF technique make things better than
   they are, or worse?

My suspicion is that the answers are mostly NO/NO.

	Thanks,
	Paul

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 24 Aug 2010 02:20:36 +0530

I've heard of people arguing that KPML is slightly heavy weight and
doesn't work as expected across B2BUAs/SBC, so they would use INFO
instead.

thanks,
Muthu 

|-----Original Message-----
|From: Paul Kyzivat (pkyzivat)
|Sent: Tuesday, August 24, 2010 1:12 AM
|To: Muthu ArulMozhi Perumal (mperumal)
|Cc: Hadriel Kaplan; [email-masked]
|Subject: Re: [dispatch] I-D
Action:draft-kaplan-dispatch-info-dtmf-package-
|00.txt
|
|Muthu ArulMozhi Perumal (mperumal) wrote:
|> The motivation looks good. However, I am not sure why it should be
|> standardized 'as is' with known limitations/issues, when we can make
|> slight modifications to make it more valuable.
|
|If we start to make mods to "improve" it then we will probably arrive
at
|something similar to KPML.
|
|I would offer the following questions:
|
|- do people have a problem with DTMF now,
|   *other* than deciding which of the many techniques to use,
|   or wishing that you peer supported the existing technique
|   that you want to use???
|
|- would yet another DTMF technique make things better than
|   they are, or worse?
|
|My suspicion is that the answers are mostly NO/NO.
|
|	Thanks,
|	Paul
|
|> Muthu
|>
|> |-----Original Message-----
|> |From: Hadriel Kaplan [mailto:[email-masked]]
|> |Sent: Monday, August 23, 2010 9:33 PM
|> |To: Muthu ArulMozhi Perumal (mperumal); [email-masked]
|> |Subject: RE: [dispatch] I-D
|> Action:draft-kaplan-dispatch-info-dtmf-package-
|> |00.txt
|> |
|> |The reason I'm proposing to generate an RFC for it, without
|> substantively
|> |changing it, is:
|> |
|> |1) Stop it from being a proprietary (albeit industry defacto)
|> mechanism.
|> |2) Register the MIME type name.
|> |3) Provide a static, numbered, public document for implementers and
|> users to
|> |reference, as opposed to a specific company's changing
|> config-documentation
|> |URLs.
|> |
|> |-hadriel
|> |
|> |> -----Original Message-----
|> |> From: Muthu ArulMozhi Perumal (mperumal)
[mailto:[email-masked]]
|> |> Sent: Monday, August 23, 2010 1:58 AM
|> |>
|> |> Yes, this is exactly what Cisco implemented 9 years back and
hasn't
|> |> undergone any change since then. But I am not sure what purpose it
|> would
|> |> solve by just calling it an IETF standard, without addressing some
of
|> |> its limitations for the Internet community.
|> |>
|> |> It would be desirable for this DTMF method to address 2 kinds of
|> |> deployments:
|> |> 1. PSTN interworking, where it provides the ability for the
receiver
|> to
|> |> generate the DTMF tone in-sync with the user pressing and
releasing
|> the
|> |> button. However, I don't think we need to achieve such precise
timing
|> as
|> |> H.245 signal/signalUpdate messages, by carrying RTP timestamp etc,
|> since
|> |> the purpose would be to only avoid the detection delay at the
|> receiver.
|> |>
|> |> 2. No PSTN interworking, where it provides the ability for a SIP
|> |> soft-phone to send a DTMF digit to an app server, without having
to
|> |> bother about the duration to the tone.
|> |>
|> |> Muthu
|> |>
|> |> |-----Original Message-----
|> |> |From: Hadriel Kaplan [mailto:[email-masked]]
|> |> |Sent: Friday, August 20, 2010 11:56 PM
|> |> |To: Muthu ArulMozhi Perumal (mperumal); [email-masked]
|> |> |Subject: RE: [dispatch] I-D
|> |> Action:draft-kaplan-dispatch-info-dtmf-package-
|> |> |00.txt
|> |> |
|> |> |
|> |> |You tell me - afaik it's Cisco's dtmf-relay that everyone's
copied
|> (and
|> |> that
|> |> |I'm proposing be an info-package, so it can be "legal").
|> |> |:)
|> |> |
|> |> |-hadriel
|> |> |
|> |> |> -----Original Message-----
|> |> |> From: Muthu ArulMozhi Perumal (mperumal)
|> [mailto:[email-masked]]
|> |> |> Sent: Friday, August 20, 2010 1:59 PM
|> |> |> To: Hadriel Kaplan; [email-masked]
|> |> |> Subject: RE: [dispatch] I-D
|> Action:draft-kaplan-dispatch-info-dtmf-
|> |> |> package-00.txt
|> |> |>
|> |> |> Hi Hadriel,
|> |> |>
|> |> |> There draft doesn't provide a method to indicate the start of a
|> DTMF
|> |> |> event and requires the INFO to be generated only when the user
|> |> releases
|> |> |> the button. So, in the following scenario where the B2BUAs
support
|> |> only
|> |> |> the INFO method of sending DTMF events, if the user presses the
|> long
|> |> |> '#', which typically lasts for 2 - 4 sec, the app server at the
|> far
|> |> end
|> |> |> would detect the long '#' only after 6 - 12 sec.
|> |> |>
|> |> |>
|> |>
|>
user--[PSTN-GW]--SIP--[B2BUA]--SIP--[B2BUA]--[PSTN-GW]--[B2BUA]--[PSTN
|> |> |> GW]--app
|> |> |>
|> |> |> Would it be better to provide a way to indicate the start of a
|> DTMF
|> |> |> event so that the far end can start playing it as soon as the
user
|> |> |> presses the button? It could be indicated using an empty value
for
|> |> |> duration, like this:
|> |> |>
|> |> |> Signal= #
|> |> |> Duration=
|> |> |>
|> |> |> Muthu
|> |> |>
|> |> |> |-----Original Message-----
|> |> |> |From: [email-masked]
|> [mailto:[email-masked]]
|> |> On
|> |> |> Behalf
|> |> |> |Of Hadriel Kaplan
|> |> |> |Sent: Friday, August 20, 2010 9:18 PM
|> |> |> |To: [email-masked]
|> |> |> |Subject: [dispatch] I-D
|> |> Action:draft-kaplan-dispatch-info-dtmf-package-
|> |> |> |00.txt
|> |> |> |
|> |> |> |Howdy,
|> |> |> |I've submitted an I-D for a DTMF Info-Package, registering it
|> |> following
|> |> |> the
|> |> |> |rules of draft-ietf-sipcore-info-events-08.  The info-events
|> draft
|> |> is
|> |> |> not in
|> |> |> |the publication queue yet - it's held up by a single DISCUSS,
but
|> I
|> |> |> expect
|> |> |> |that to be resolved.
|> |> |> |
|> |> |> |With regards to my I-D, I'd like to go through A-D sponsored
|> instead
|> |> of
|> |> |> a
|> |> |> |new WG, for obvious reasons.
|> |> |> |
|> |> |> |Any comments/flames are appreciated.
|> |> |> |
|> |> |> |-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
|>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Aug 2010 17:16:50 -0400

> doesn't work as expected across B2BUAs/SBC, so they would use INFO

I'm somewhat sympathetic to the problems of having it be a separate 
dialog. (Not too sympathetic - people need to get it through their heads 
that this is required functionality through SBCs or whatever.)

But IMO the rest of the heavy weightedness is really not such a big 
deal, and is there for good reasons. So I can see something similar to 
kpml using an info-package. (If it really is too heavy, we might have to 
revisit that.)

But this is all moot unless somebody can make a case for yet another 
DTMF mechanism.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 23 Aug 2010 17:24:28 -0400

> Sent: Monday, August 23, 2010 3:20 PM
> To: Hadriel Kaplan
> 

No, I think you misunderstand what I meant: I meant a device supporting this draft would also support legacy, by definition.  So there are only NP-NL, NP-L, and P-L.  And any combination with NP-NL does not matter (since by definition an NP-NL doesn't do DTMF with INFO to begin with).

So the only combinations that exist and matter are:

-hadriel

> > Option-2 is to change the draft to define a "legacy INFO usage" as
> described in draft-ietf-sipcore-info-events-08, and just register the MIME
> type and describe the syntax and semantics.  Since "application/dtmf-
> relay" is unambiguous for the INFO request's purpose, and it appearing in
> the Accept header for the INVITE is also unambiguous, it avoids the issues
> people have with using INFO.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Aug 2010 18:01:48 -0400

> 		The DTMF package will be used.)

That reduces things somewhat. But if everybody that supports the package 
also supports the legacy approach, what is the win?

I guess if both UAC and UAS support both, and the UAS doesn't want DTMF, 
then you avoid sending it. Other than that there is no win over 
supporting only legacy.

Its slightly more trouble to support both than to support only the 
legacy, though not a lot more.

The real *advantage* of info packages is that their use is negotiated. 
And that is lost if you support the legacy approach too.

As I mentioned, Cisco currently supports five different dtmf approaches, 
and this would make six. Its really difficult to figure out which one to 
use with such a mess, so making it worse is not very attractive.

I'm usually the theorist. But here I think we need to focus very much on 
the pragmatic - what will make implementor's jobs easier and/or the end 
results tangibly better.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 Aug 2010 02:53:41 +0200

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 24. elokuuta 2010 1:02
> To: Hadriel Kaplan
> Cc: [email-masked]
> Subject: Re: [dispatch] I-D 
> Action:draft-kaplan-dispatch-info-dtmf-package-00.txt
> 
> 
> 
> Hadriel Kaplan wrote:
> > 
> >> If this is introduced, we will have those that support it (P) and 
> >> those that don't. (NP) We will also have those that support the 
> >> legacy INFO way of doing DTMF (L) and those that don't. (NL) That 
> >> immediately gives four different kinds of UAs that we then 
> need to consider interop among:
> >>
> >> NP-NL
> >> NP-L
> >> P-NL
> >> P-L
> > 
> > No, I think you misunderstand what I meant: I meant a 
> device supporting this draft would also support legacy, by 
> definition.  So there are only NP-NL, NP-L, and P-L.  And any 
> combination with NP-NL does not matter (since by definition 
> an NP-NL doesn't do DTMF with INFO to begin with).
> > 
> That reduces things somewhat. But if everybody that supports 
> the package also supports the legacy approach, what is the win?
> 
> I guess if both UAC and UAS support both, and the UAS doesn't 
> want DTMF, then you avoid sending it. Other than that there 
> is no win over supporting only legacy.
> 
> Its slightly more trouble to support both than to support 
> only the legacy, though not a lot more.
> 
> As I mentioned, Cisco currently supports five different dtmf 
> approaches, and this would make six. Its really difficult to 
> figure out which one to use with such a mess, so making it 
> worse is not very attractive.
> 
> I'm usually the theorist. But here I think we need to focus 
> very much on the pragmatic - what will make implementor's 
> jobs easier and/or the end results tangibly better.
> 
> 	Thanks,
> 	Paul
> 
> 
> > -hadriel
> > 
> > 
> >> demand to "improve" it, because it has a lot of limitations. That 
> >> will make more of a mess.
> >>
> >> described in draft-ietf-sipcore-info-events-08, and just 
> register the 
> >> MIME type and describe the syntax and semantics.  Since 
> >> "application/dtmf- relay" is unambiguous for the INFO request's 
> >> purpose, and it appearing in the Accept header for the 
> INVITE is also 
> >> unambiguous, it avoids the issues people have with using INFO.
> >>
> >> (I don't know if it was ever published, but it seems 
> likely.) If so, 
> >> maybe we can republish it as HISTORIC, as was recently 
> done with the 
> >> Diversion header draft.
> >>
> >> 	Thanks,
> >> 	Paul
> >>
> >>> -hadriel
> >>>
> >>>> though it is *essentially* the same, it is not *exactly* 
> the same 
> >>>> as what is currently implemented in the field. Hence 
> moving to this 
> >>>> also requires *some* (small) effort. And there will be 
> things that 
> >>>> still do it the old way. So there are interop considerations to 
> >>>> take into
> >> account.
> >>>> For a data point, in Cisco we have *five* mechanisms 
> (that I know 
> >>>> of) for DTMF transport in sip that we support and use 
> one way or another.
> >>>> There are complex negotiation and configuration mechanisms for 
> >>>> deciding what to use, and we often have to convert between them. 
> >>>> This proposal would just increase that number from 5 to 6.
> >>>>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 24 Aug 2010 10:55:13 -0400

> Sent: Monday, August 23, 2010 6:02 PM
> To: Hadriel Kaplan
> 

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: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Aug 2010 11:51:02 -0400

Maybe we should ask our ADs if they have an opinion about this.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 Aug 2010 19:58:20 +0200

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.

Regards,

Christer

> Sent: 24. elokuuta 2010 18:51
> To: Hadriel Kaplan
> Cc: [email-masked]
> >> 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: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Aug 2010 14:47:53 -0400

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

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: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 24 Aug 2010 14:35:24 -0500

On 08/24/2010 01:47 PM, Paul Kyzivat wrote:
> 
> 
> 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.
> 

We see almost zero usage of SIP INFO now, although I know it's out there
and there are probably cases where people have had to configure our
systems to support it. To date it's been considered a bit of an
'oddball' for DTMF transport, since there was no standards document
defining it. I'm a bit concerned that producing such a standards
document will in fact encourage implementors to start implementing it,
even though it is not as capable as RFC4733/4734 are (but of course it
has some benefits over media stream based signaling).

We've not even bothered to implement KPML, for many of the same reasons;
there's just little or no demand for it.

Instead of 'blessing' this INFO package for DTMF transport, I think the
group's time would be better spent determining the use cases that cause
implementors to want to use it, and then figuring out if those use cases
can be addressed via existing mechanisms, or with modifications to
existing mechanisms.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 24 Aug 2010 16:34:49 -0400

> Behalf Of Kevin P. Fleming
> Sent: Tuesday, August 24, 2010 3:35 PM
> 

That's odd.  We've seen tons of dtmf in INFO used.  It hasn't been as popular as 2833/4733 RTP-based dtmf overall, but for the guys who need signaling-based DTMF it's been the king (way more than KPML or proprietary Notify-based ones).

> there's just little or no demand for it.

Likewise.

-hadriel

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 25 Aug 2010 08:32:10 +0530

Christer/Hadriel,

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. 

I agree with Paul that new INFO based DTMF will not solve interop issue but call for SBC functionality addition due to this new behavior. But in case it is the industry or IMS needs, let us explore it.

Thanks

Partha

________________________________

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

        Thanks,
        Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 Aug 2010 05:15:03 +0200

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

	

	
	
	        Thanks,
	        Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 25 Aug 2010 08:55:42 +0530

Christer,
 
My questions are
 
1) whether 3GPP DTMF Info package is in the state to be accepted as IETF standards.
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.
 
In case both questions are answered in favor of DTMF Info package, I'm fine with DTMF Info package proposal.
 
Thanks
Partha

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,

Regards,

Christer

       

       
       
                Thanks,
                Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 Aug 2010 05:34:35 +0200

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

	Hi,

	
	Regards,
	
	Christer

	       

	

	       

	       
	                Thanks,
	                Paul

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 25 Aug 2010 09:16:54 +0530

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 Aug 2010 05:57:08 +0200

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

> Sent: 25. elokuuta 2010 6:47
> To: Christer Holmberg; Parthasarathi R (partr); Paul Kyzivat 
> (pkyzivat)
> 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
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 25 Aug 2010 10:21:04 +0530

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

Sent: Wed 8/25/2010 9:04 AM

Hi,

Regards,

Christer

        Hi,

       
        Regards,
       
        Christer

              

       

              

              
                        Thanks,
                        Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 Aug 2010 08:05:14 +0200

Hi,

>mechanism for DTMF relay."

Personally I have no opinion on that.

In my understanding the scope of KPML is wider than DTMF transport, so someone may want to use it for something else. I have never seen any usage of, or received a requirement to support, KPML, but that of course doesn't guarantee that there aren't deployments out there.

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

KPML vs INFO has been discussed many times, before we even started the work on Info Packages. One issue people have is that it requires subscriptions, and separate subscription dialogs (based on the dialog usage recommendations), which have resource impacts at least on stateful entities.

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

Sure. Any 3GPP member can bring change proposals.

And, if we decide to specify a DTMF Info Package of our own (e.g. based on Hadriel's proposal), any 3GPP member can, once it's down, propose to adopt it for IMS.

Regards,

Christer

	Hi,

	
	Regards,
	
	Christer

	

	
	
	        Hi,

	       
	        Regards,
	       
	        Christer

	              

	       

	              

	              
	                        Thanks,
	                        Paul

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 25 Aug 2010 11:17:26 +0200

We had a lot of discussion on KPML versus INFO prior to commencing the info-events work, and I think one of the issues was that KPML is fine if the recipient of information is off the path of the SIP dialog for the session concerned, but was not optimised for use cases where an entity on the path needs to receive the information. At the time there seemed to be a consensus that DTMF would be a very likely candidate for an INFO package, should the info-events work proceed. In fact, I don't recall many other candidates, so DTMF seemed to be a prime driver for the info-events work. However, I don't think it was seen as a total replacement for KPML.

John

> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 25 August 2010 07:05
> Subject: Re: [dispatch] 
> I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt
> 
> 
> Hi,
> 
> >"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."
> 
> In my understanding the scope of KPML is wider than DTMF 
> transport, so someone may want to use it for something else. 
> I have never seen any usage of, or received a requirement to 
> support, KPML, but that of course doesn't guarantee that 
> there aren't deployments out there.
> 
> >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.
> 
> KPML vs INFO has been discussed many times, before we even 
> started the work on Info Packages. One issue people have is 
> that it requires subscriptions, and separate subscription 
> dialogs (based on the dialog usage recommendations), which 
> have resource impacts at least on stateful entities.
> 
> >Also Currently, IANA registration is yet to be done for DTMF 
> Info package and so, the modification is possible.
> 
> And, if we decide to specify a DTMF Info Package of our own 
> (e.g. based on Hadriel's proposal), any 3GPP member can, once 
> it's down, propose to adopt it for IMS.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 	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
> 	
> 	
> 	
> 	
> 	        >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
> 	                Subject: Re: [dispatch]I-D 
> 	                > 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.
> 	              
> On Behalf Of Paul Kyzivat

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Aug 2010 08:44:04 -0400

Can you share the details? Is it a clone of some other deployed 
mechanism? What Content-Type does it use?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Aug 2010 09:08:33 -0400

never mind. I found the references in later mails.

Paul Kyzivat wrote:
>>> 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. 
>>
>>     > 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.
>>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 26 Aug 2010 17:00:42 +0530

Christer/Jonn,

Thanks for the explanation. From your mails, I'm getting the feel that
KPML is good for off the path of SIP dialog and INFO DTMF-relay package
outperforms in case the same dialog is used for signaling based
DTMF-relay as well as other signaling services. 

Hadriel,

Current text in the draft mention that KPML is not adopted as KPML has
less deployment which may not be appropriate. It will be good in case
draft introduction section mention the technical advantage of using INFO
dtmf package over KPML. 

Thanks
Partha

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Wednesday, August 25, 2010 2:47 PM
To: Christer Holmberg; Parthasarathi R (partr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]; Hadriel Kaplan
Subject: RE: [dispatch]

We had a lot of discussion on KPML versus INFO prior to commencing the
info-events work, and I think one of the issues was that KPML is fine if
the recipient of information is off the path of the SIP dialog for the
session concerned, but was not optimised for use cases where an entity
on the path needs to receive the information. At the time there seemed
to be a consensus that DTMF would be a very likely candidate for an INFO
package, should the info-events work proceed. In fact, I don't recall
many other candidates, so DTMF seemed to be a prime driver for the
info-events work. However, I don't think it was seen as a total
replacement for KPML.

John

> deprecated for the proposed DTMF Info packages. Both KPML, DTMF Info 
> package are SIP signaling based
> In my understanding the scope of KPML is wider than DTMF transport, so

> someone may want to use it for something else.
> I have never seen any usage of, or received a requirement to support, 
> KPML, but that of course doesn't guarantee that there aren't 
> deployments out there.
> 
> current IETF standard (KPML) for DTMF relay. In case of the analysis 
> has done for not selecting
> KPML vs INFO has been discussed many times, before we even started the

> work on Info Packages. One issue people have is that it requires 
> subscriptions, and separate subscription dialogs (based on the dialog 
> usage recommendations), which have resource impacts at least on 
> stateful entities.
> 
> And, if we decide to specify a DTMF Info Package of our own (e.g. 
> based on Hadriel's proposal), any 3GPP member can, once it's down, 
> propose to adopt it for IMS.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 	>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
> 	
> 	
> 	
> 	
> 	        >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.
> 	                From: [email-masked] on behalf of
Paul 
> Kyzivat (pkyzivat)
> 	                > 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.
> 	              
> 	                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
> 	                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
> 	                >>>> That reduces things somewhat. But if
everybody 
> that supports the
> 	                >>>> package also supports the legacy approach,
what 
> is the win?
> 	                >> 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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 31 Aug 2010 13:27:23 +0300

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