Subject: [Sipping] SIP INFO method for DTMF

From: [email-masked]
Date: Mon, 11 Feb 2002 09:54:30 -0000

IETF SIPPING experts,

3GPP standards people have been looking at various potential solutions for
carrying DTMF in the IP Multimedia Subsystem (IMS).

One such solution is the use of the SIP INFO method.  I have read the
expired internet-draft, written by Jiri Kuthan (whom I tried to contact
first, but the e-mail address was no longer a valid one) and there is
support for such a solution in 3GPP.  I was involved in a telephone
conference last week with other 3GPP delegates, in which we questioned why
this draft expired?  Whilst we have highlighted some potential problems with
using the draft that Jiri wrote, we did at least see the INFO method as a
feasible option (as well as the RTP payload option - I've had a fair amount
of e-mail discussion with Henning on RFC 2833).

3GPP may run into problems in the Radio Access Network (RAN) area if we
choose the RTP solution for DTMF.  As such, we are considering writing an
internet-draft on the use of the SIP INFO method for DTMF.  However, before
doing this, I thought it wise to 'test the water'.

The RTP solution is well documented, and we're currently looking into those
RAN issues.  In the meantime, I'm asking for opinions on the general concept
of using the SIP INFO method for DTMF.

Best Regards,

Duncan

Duncan Mills
UMTS Standards
Technology Team
Core Network Development
Vodafone Ltd (Networks)

Tel:	+44 1635 676074
Fax:	+44 1635 234445
mailto:[email-masked]

---

From: "Garland Sharratt" <[email-masked]>
Date: Mon, 11 Feb 2002 09:41:14 -0800

Duncan:

From an architectural point of view, the clean way to carry post-dial DTMF
is in RTP using RFC 2833, because this preserves the separation of media
(audio) from signaling.  

Some reasons for keeping the separation include: 
*	the network is architected along this separation, with app servers
and softswitches handling signaling and media gateways and media servers
(Media Resource Functions) handling media; and
*	when post-dial DTMF is replaced with speech later, it will no longer
fit in the signaling.

Of course they may be very valid reasons in particular cases to do
otherwise.

Garland

>  -----Original Message-----
> From: 	[email-masked] [mailto:[email-masked]]  On
> Behalf Of [email-masked]
> Sent:	Monday, February 11, 2002 01:55
> To:	[email-masked]
> Subject:	SIP INFO method for DTMF
> 
> IETF SIPPING experts,
> 
> this draft expired?  Whilst we have highlighted some potential problems
> with using the draft that Jiri wrote, we did at least see the INFO method
> as a feasible option (as well as the RTP payload option - I've had a fair
> amount of e-mail discussion with Henning on RFC 2833).
> 
> internet-draft on the use of the SIP INFO method for DTMF.  However,
> before doing this, I thought it wise to 'test the water'.
> 
> The RTP solution is well documented, and we're currently looking into
> those RAN issues.  In the meantime, I'm asking for opinions on the general
> concept of using the SIP INFO method for DTMF.
> 
> 
> Best Regards,
> 
> Duncan
> 
> 
> 
> 
> Duncan Mills
> UMTS Standards
> Technology Team
> Core Network Development
> Vodafone Ltd (Networks)
> 
> Tel:	+44 1635 676074
> Fax:	+44 1635 234445

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Feb 2002 13:31:42 -0500

Let me put in my two cents here.

There has been fierce religion on this issue because DTMF plays so many
roles in a network. 

Its most common use is truly media. Between gateways, for example, it
needs to be placed into the media stream at the terminating gateway.
This requires synchronization with the media stream. That strongly
argues for rfc2833. The use of INFO or SUBSCRIBE for DTMF in this usage
is bad; it is a load on the network elements.

The other use is to signal IP applications. In this use, SIP mechanisms
do have a benefit. We may want applications that are not on the path of
the media stream to find out about the events. THere may be no issues
with media synchronization (if there are, vxml types of solutions with
forked media may be needed, as I have long advocated). But, for simple
DTMF-only apps, rfc2833 is expensive and provides little gain.

Thus, my proposal is: separate solutions for very different problems.

When an originator detects DTMF, it always inserts it as rfc2833 into
the media stream. This makes sure the e2e media applications work.

However, if there are applications not on the media path that need this
information, they can SUBSCRIBE to the UA, to receive input on events to
drive the application. I think this is broader than DTMF. For example,
my presence server needs an "is typing" indication, to support the
common IM feature, where you know when your peer is typing. I would
propose that this use the same SUBSCRIBE/NOTIFY mechanism. 

In the 3gpp case, this would mean rfc2833 as the baseline, with no
SUBSCRIBE/NOTIFY on a call unless an app needed it. Using rfc2833
instead of INFO is really, really, really important. The usage of INFO
for e2e transport of DTMF suffers many problems:

1. because of the separation of media and signaling paths, AND because
of the longer signaling paths, AND because of the use of retransmits on
the signaling path, the overall latency for transfer of DTMF through
INFO will be huge compared to rfc2833. Thus, by using INFO, the jitter
buffers at the receiver will need to be monstrous to properly re-insert
DTMF into the output media stream. This affects overall voice latency
and perceived user quality.

2. The load on the proxies will be huge. Given the frequency of DTMF
usage in a call, we could be talking like 20% increase on overall proxy
loading, for NOTHING. The proxies don't need to look at the INFO. 

3. Because of latency concerns, the originating UA will need to send an
INFO for each detected digit. This will be a very large load on the
network. With rfc2833, there are no iimplications on the proxy network.
Applications that need DTMF, which use SUBSCRIBE, could even provide
digit maps, so they only get NOTIFY when the proper event happens. This
reduces traffic load in the application case even.

This is a change in position for me, since I have long advocated rfc2833
alone for both usages. Now that, in my mind, I have been able to cleanly
separate them, I see little to lose from allowing SUB/NOT for
application usage (but not e2e transport), although I still think you
will need the full media stream for many apps (any voice reco). 

Thanks,
Jonathan R.

Garland Sharratt wrote:
> 
> Duncan:
> 
> >From an architectural point of view, the clean way to carry post-dial
> DTMF is in RTP using RFC 2833, because this preserves the separation of
> media (audio) from signaling.
> 
> *       the network is architected along this separation, with app
> servers and softswitches handling signaling and media gateways and media
> servers (Media Resource Functions) handling media; and
> *       when post-dial DTMF is replaced with speech later, it will no
> longer fit in the signaling.
> 
> > From:         [email-masked] [mailto:[email-masked]]
> > On Behalf Of [email-masked]
> > 3GPP standards people have been looking at various potential solutions
> > for carrying DTMF in the IP Multimedia Subsystem (IMS).
> >
> > expired internet-draft, written by Jiri Kuthan (whom I tried to
> > contact first, but the e-mail address was no longer a valid one) and
> > there is support for such a solution in 3GPP.  I was involved in a
> > telephone conference last week with other 3GPP delegates, in which we
> > questioned why this draft expired?  Whilst we have highlighted some
> > potential problems with using the draft that Jiri wrote, we did at
> > least see the INFO method as a feasible option (as well as the RTP
> > payload option - I've had a fair amount of e-mail discussion with
> > Henning on RFC 2833).
> >
> > 3GPP may run into problems in the Radio Access Network (RAN) area if
> > we choose the RTP solution for DTMF.  As such, we are considering
> > writing an internet-draft on the use of the SIP INFO method for DTMF.
> > However, before doing this, I thought it wise to 'test the water'.
> >
> > those RAN issues.  In the meantime, I'm asking for opinions on the
> > general concept of using the SIP INFO method for DTMF.
> >
> >
> > Best Regards,
> >
> > Duncan
> >
> >
> >
> >
> > Duncan Mills
> > UMTS Standards
> > Technology Team
> > Core Network Development
> > Vodafone Ltd (Networks)
> >
> > Tel:  +44 1635 676074
> > Fax:  +44 1635 234445

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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