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

From: "Culpepper, Bert" <[email-masked]>
Date: Tue, 13 Jun 2000 15:08:04 -0500

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: Dave Walker <[email-masked]>
Date: Wed, 14 Jun 2000 09:54:44 -0400

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.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 14 Jun 2000 10:19:51 -0400

> this kind of thing.  Would you like to see an option-tag defined

While this not be a bad idea (I might be biased, here...), it does need
a bit more work, since carrying RTP packets in INFO would require some
way of mapping RTP timestamps to absolute time [RTCP does this] and,
less importantly, decide what significance the payload type (PT) field
has in this context. Obviously, if you only need a duration, not
absolute timing, sticking RTP packets into INFO is sufficient. However,
you'd probably not want to use every such RTP packet, only when a new
digit has been detected.

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

---

From: Scott Petrack <[email-masked]>
Date: Thu, 15 Jun 2000 00:33:09 -0400 (EDT)

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