[sip-comm-dev] GSOC 09 : Dtmf progress report

Romain filirom1 at gmail.com
Tue Jul 21 14:11:09 CEST 2009


Hello Lubomir

You are totally right about the fact that DTMF should be seen as a
DataSource with DataStream and Format. And this is what I did.

I send it now on a new thread because the conception is totally different.

I hope that the previous conception with RTPConnector could be use in
an other project.

2009/7/18 Lubomir Marinov <lubomir.marinov at gmail.com>:
> Hello again Romain,
>
>> Transformer Patch
>
> Now on the subject of the implementation approach for transmitting
> DTMF over RTP, I feel compelled to ask why you've chosen the injection
> of RTP packets in the fashion of ZRTP.
>
> As Emil is more often available online than you, I turned to him and
> got the answer that it was him who made the decision. His idea is (and
> I'm paraphrasing here so take my statements with a large grain of
> salt) to eventually have a generic way of injecting RTP packets. If
> this idea can be implemented and it works (in a sane non-hacky) for
> DTMF over RTP, I welcome it.
>
> In the light of your difficulty to get the timestamp and, most
> importantly, the sequence number of the injected packet to the right
> values though, I think it may be worth it to look at the task at hand
> from a different angle.
>
> ZRTP does inject packets (thank you, Emil, for pointing it to me!). So
> I can see how injecting DTMF packets in the same way does make a great
> deal of sense.
>
> However, ZRTP has its own sequence numbers which do not depend on the
> audio packet sequence numbers while for DTMF over RTP we have in the
> RFC that:
>
>   Named telephone events are carried as part of the audio stream and
>   MUST use the same sequence number and timestamp base as the regular
>   audio channel to simplify the generation of audio waveforms at a
>   gateway.  The named telephone-event payload type can be considered to
>   be a very highly-compressed audio codec and is treated the same as
>   other codecs.
>
> Even if you manage to get the sequence numbers right at the layer
> which transmits (and receives, for that matter) RTP packets, you're
> implementation will be in a way diverging from the expectations of the
> RFC reader because of the sentence "The named telephone-event payload
> type can be considered to be a very highly-compressed audio codec and
> is treated the same as other codecs." At least when I read it, I
> thought your implementation would deal with the javax.media/JMF
> classes such as Format, Codec, DataSource because these are on the
> level of abstraction of codecs, RTP packet generation, they are not in
> the layer which transmits RTP packets.
>
> Anyway, Emil and I thought that if you were able to get the sequence
> numbers right using your approach, we'd go with it because it is in
> effect more generic with respect to RTP packet injection (and on my
> side at least because you've already started working on it).
>
> But if it turns out to be a no go, we may need to explore the other
> approach of having DTMF at the codec level.
>
> Regards,
> Lubomir
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help at sip-communicator.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
For additional commands, e-mail: dev-help at sip-communicator.dev.java.net





More information about the dev mailing list