[Jingle] XEP-0181: Jingle DTMF

Peter Saint-Andre stpeter at stpeter.im
Tue Sep 9 20:55:21 CDT 2008


Robert McQueen wrote:
> Peter Saint-Andre wrote:
>>> [1]: If it involves not using RTP, I don't think we care. Something
>>> which puts a non-RTP call over Jingle and wants to do DTMF can define
>>> its own session info events. Any meaningful interoperability with Jingle
>>> RTP clients is obviously completely dead in that case, so the inevitable
>>> gateway could just convert RFC 4733 stuff into whatever the non-RTP
>>> thing used, but whoever deviates from the norm gets to do the extra work.
>> As Diana points out, RFCs 2833/4733 are RTP-specific. If in Jingle we
>> use transports other than RTP, we might want to define a method for
>> sending DTMF in the signalling channel. I agree that we could do that as
>> session-info messages, but that's what XEP-0181 defines. (!) So perhaps
>> it makes sense to let this gently lapse into deferred until someone
>> needs it?
> 
> I still think it's best to make it very lapsed, because having two ways
> to do it when RTP /is/ in use is pretty harmful I think. I think we
> should put XEP-0181 on ice and instead just make it a MUST in the RTP
> XEP that if you're doing DTMF, you use the RFC 4733 stuff. If we do fins
> a stunningly important non-RTP content description that still needs us
> to do gatewaying to PSTN and send DTMFs, we can cross that bridge when
> we get to it. :)

I think Diana is saying that she has already arrived at that bridge and 
that she needs in-band DTMF for her application. Yes, we can say that if 
you're using RTP then do your DTMF signalling there. But if you're not 
using RTP then do your DTMF signalling via XEP-0181.

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/jingle/attachments/20080909/881558ac/attachment.bin 


More information about the Jingle mailing list