Subject: RE: [SIP] Out-of-Band DTMF in SIP

From: "Culpepper, Bert" <[email-masked]>
Date: Wed, 14 Jun 2000 14:29:50 -0500

I understand agreement on MIME-type may be difficult to get, however ISUP
and QSIG did ;-) or maybe I'm wrong about that.  My ID did discuss Megaco
(it actually provides better support than MGCP for DTMF and other terminal
events).

Anyway, I'd like to have a way to ask the MGC to "turn on" digit collection
at the gateway during a call and report the collected digits.  I'd also like
to ask the MGC/gateway to report any/all detected terminal events.  And I'm
looking at PSTN-based terminals (telephones) and  SIP-based application
servers independent of the MGC (or softswitch).  Granted, this is a
"specialized" network architecture but one that is drawing a great deal of
interest by many.  Without the above functionality it is nearly impossible
to deploy many of today's enhanced services in a VoIP network without having
direct control of the gateways.

Regards,
Bert

> -----Original Message-----
> From: Dave Walker [mailto:[email-masked]]
> Sent: Wednesday, June 14, 2000 9:55 AM
> To: Culpepper, Bert
> Cc: SIP List
> Subject: Re: [SIP] Out-of-Band DTMF in SIP
> 
> 
> What would you like to see?  I don't think that agreement on the 
> MIME-type is going to be easy to get.  Your draft suggested MGCP
> events, others might prefer megaco.  A SIP phone may not speak
> either, but if it uses RFC2833 it would be easy to send audio/tone 
> MIME-type inside of INFO.  We already have the Accept headers for
> this kind of thing.  Would you like to see an option-tag defined
> for it?
> 
> Regards,
> 
> Dave Walker
> SS8 Networks
> Ottawa, Canada.
> 
> "Culpepper, Bert" wrote:
> > 
> > Hello all,
> > 
> > There have been a couple IDs written a short while back on DTMF
transport,
> > collection, etc. each using the SIP INFO method.  I see out-of-band DTMF
> > reporting as a "problem" to be solved to support carrying
telecommunications
> > traffic over SIP networks.  IMO, Out-of-band "event" reporting is needed
to
> > minimize latency and provide services to PSTN-based users within SIP
> > proxy/application servers that do not also "own" the gateways.  MGCP and
> > Megaco compliant gateways support DTMF collection and out-of-band
reporting
> > but there is no "agreed upon" method or interworking proposal in
SIP/SIP-T
> > that I have found.
> > 
> > Is there a solution to this "problem" that I have missed or are others
> > interested in addressing this area?  As of this week, I've asked for a
> > "slot" at the upcoming IETF meeting to present one ID on the subject but
> > don't want to take others' time if there's no need.
> > 
> > Thanks,
> > Bert
> >
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Culpepper, Bert" <[email-masked]>
Date: Wed, 14 Jun 2000 15:25:59 -0500

What I'd like to avoid is "processing" RTP during a session for scenarios
similar to those in draft-rosenberg-sip-3pcc-00.txt.  Although having the
SIP network edge device multicast RTP is a possibility (but is this possible
when a media gateway doesn't speak SIP?).

Thanks,
Bert

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Wednesday, June 14, 2000 4:01 PM
To: Bratakos, Maroula
Cc: Dave Walker; Culpepper, Bert; SIP List
Subject: Re: [SIP] Out-of-Band DTMF in SIP

"Bratakos, Maroula" wrote:
> 
> Even devices that don't speak mgcp or megaco could implement the
out-of-band
> DTMF using the method described in the culpepper draft because it only
uses
> a very small subset of mgcp/megaco commands.  I think it is a cleaner
method
> than carrying RTP in the INFO message because you don't have to worry
about
> absolute time or the payload type, which for avt-tones is dynamic. And the

Since the PT doesn't matter, you can ignore it. The timestamp is a wash:
with MGCP-lite, you don't get any better timing information than the
arrival of the MGCP packet, which is what RTP also provides by simply
ignoring the timestamp. RTP gives you better relative timing between
tones, based on timestamps.

> mgcp/megaco commands provide a way to request DTMF via INFO to be turned
> on/off, which is a major plus.  I'm not sure how you would turn INFO
on/off
> with RTP.

Easy: don't put the MIME type in Accept. It would be more difficult to
change your mind mid-call.

> Maroula Bratakos
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 14 Jun 2000 23:14:31 -0700

Scott,

Here we use in-band and out-of-band to indicate whether the DTMF packets are
sent along the media path (with the RTP voice packets) or whether they are
sent along the call processing path. You may quite often want to send DTMF
notification along _both_ paths. A classic example is with pre-paid calling
card systems. When the user makes a call through the system, the RTP media
is connected to the remote SIP gateway. For obvious reasons you also need to
pass avt-tones RTP packets through to the remote gateway; however, if the
user presses and holds the '#' key then they should be taken back to the IVR
system. The IVR application server is not in the media path and so the DTMF
notification needs to be sent along the SIP call processing path for this to
work.

The requirements for each DTMF transport path are different. In most cases
the INFO DTMF events do not need to be matched to the media timestamp (as
they are independent to the media path). Additionally, a low number of INFO
DTMF event packets is desirable and so an event driven event package (such
as the suggestions in the Culpepper draft) seems a good fit.

As other people have said, using RTP avt-tones packets in INFO requests has
no way of enabling/disabling INFO event transmission mid-call (so far).

Regards,

Robert.
-----Original Message-----
From:	Scott Petrack [mailto:[email-masked]]
Sent:	Thursday, June 15, 2000 12:33 PM
To:	Culpepper, Bert
Cc:	SIP List
Subject:	Re: [SIP] Out-of-Band DTMF in SIP

This subject has come up periodically over the past 5 years or so. At the
risk of beating dead horses:

1. In the Internet we don't really have "bands" to be "out of" or "in to."
We have hosts, and the requirement to transport information between (or
among) those hosts. You have stated a very common and important
requirement -- the need to transport DTMF information from some hosts on
the net to "SIP proxy/application servers that do not also 'own' the
gateways" -- aka "other hosts". You have stated the requirement that the
transport method minimizes latency. There are other requirements you might
have mentioned, which have to do with keeping the time synchrony of the
DTMF tones aligned to the voice media. (Think of systems where you can
"press 1 or say 'yes'", and what might happen if the dtmf tone path gets
out of time synch with the voice path.) 

2. There is actually an RFC 2833 which describes how to use RTP to
transport DTMF tones in such a way that these requirements are met. 

Please don't think that somehow it is illegal or even strange to use RTP
to transport information to a SIP server. If you need the realtime
information, you need the realtime information. It is not a difficult
payload format to parse, and you might just find that if you do something
else, you will miss some point that when into the godzillion too many
hours that went into getting agreement on that payload format.

I once suggested to someone as a joke that if they really really needed to
use SIP, they should just take the RTP packet and put it into a SIP INFO
message with a body of type application/rtp. Just like the ISUP-within-SIP 
people do. I have since heard that this got implemented. Well, at least
they used the RTP payload format....

Scott

On Tue, 13 Jun 2000, Culpepper, Bert wrote:

> Hello all,
> 
> There have been a couple IDs written a short while back on DTMF transport,
telecommunications
to
reporting
> but there is no "agreed upon" method or interworking proposal in SIP/SIP-T
> that I have found.
>