[sip-comm-dev] GSoc 09 : Dtmf without Transformer but with BufferTransferHandler

Romain filirom1 at gmail.com
Thu Jul 23 11:07:36 CEST 2009

Hi Lubomir

2009/7/22 Lubomir Marinov <lubomir.marinov at gmail.com>:
> Hi Romain,
> Impressive skills, lack of communication.
> A great "thank you" to Emil for pointing it out to me that you deserve
> genuine congratulations for coming up with the idea on your own given
> that you're a student and it's your first project on JMF.
> Congratulations! For the guys on this development list who have
> followed our previous threads on the subject, I'd like to give the
> details that though I hinted at moving the center of the
> implementation idea in the area of codecs more than a week ago, Romain
> read my message just yesterday when he came online to submit his own
> idea and implementation.
> I fail to be amused though.
> I find it embarrassing to submit to waiting for an answer from my
> student for more than a week only to discover that my mentor message
> hasn't been read and has thus been rendered useless.

Sorry, but you sent your message on Saturday, and I saw it on Tuesday
morning. It is a short week.

> Especially when
> it comes after half a program of 15 hours per week (explicitly stated
> in the application form) just when the student states he's finally
> going to honor us with 40 hours per week.

As you said, it was explicit in my application form that during my
scholar period I can only give you 15 hours per week.

If this not bother you, could we please continue those arguments in
private mails.

> As to the new implementation we are being presented with, I find the
> idea correct and the design unfinished, thus the implementation is
> premature. Then, of course, the explicit stress on
> BufferTransferHandler as a packet injection means is inaccurate.

In 3 days, I presented you another way to inject packets.
This way has more advantages than the Transformer way.

Using this way, we can implement 99% of the RFC.

The last percent is : we can not freeze the timestamp  for the 2 last packets.

In my previous mail I pointed every problems I found of my
implementation, that mean it is not finished.

But of course you have more experience with JMF, I follow your advices.

> The major missing piece is that there are two sources of pushes, not
> one: the very capture device for the audio AND the user for DTMF.
> Currently, the implementation only pushes through the capture device
> so it's understandable that "If the user press and releas too fast,
> some DTMF packets are missing."

I try to figure out our idea of two data sources : one for dtmf and
one for the user.
I think we have a problem keeping the SSRC of the DTMF stream = SSRC
of the audio stream.
This is a temporary problem, that could be resolve quickly with my

> Another weak point I find is the desire to explicitly put the
> injection in the transfer handler. For what it's worth, the
> implementation already takes over the DataSource and its streams (and,
> of course, it takes over the transfer handler which is necessary
> anyway in order to hide the wrapped stream) so I'd rather think the
> injection happens when reading from the stream, rather than when
> notifying that there's data to be read. If the very reading was taken
> over, I believe it would've been much easier to track the sequence
> number.

Now the sequence number is tracked.
But if you want to share your vision of your user DataSource, I will
have an internet access tomorow during the whole day.

>> Each time a DTMF packet is sent, the SeqNum of the next an audio
>> packet icrements very fast :
>> I don't think I could correct this because this behaviour is hard
>> coded in J MF :
>>    public long getSequenceNumber(Buffer b)
> I honestly don't see why this method is the problem. Please provide
> more details.

In the next mail.
I am sending it now.

> The next missing piece in the implementation is the fact that the
> injection should happen only in the stream signaled in the SDP, not
> all and certainly not the video streams.

DTMF need to be inject in an AudioStream.

   The RTP payload format for named telephone events is designated as
   "telephone-event", the media type as "audio/telephone-event".

> And just to mention it though I'm aware that the implementation is
> unfinished, we have to be careful in the wrapper DataSource when
> calling the wrapped DataSource's getStreams() in the constructor. Not
> only it seems technically incorrect to do it before calling connect()
> but also there's no technical guarantee that calling it later one
> would return the same number of streams.

Ok, I am quite new at JMF and I want to learn. My implementation is
not finished and I am aware of it.

Tomorrow I think I could give you my implementation with 99% of the
RFC implemented.

If you don't like this, and your implementation idea is better than
mine, I will do as you want.

> 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