[sip-comm-dev] GSoc 09 : Dtmf without Transformer but with BufferTransferHandler
filirom1 at gmail.com
Thu Jul 23 11:07:36 CEST 2009
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
> 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
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
If you don't like this, and your implementation idea is better than
mine, I will do as you want.
> 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