Hi Benny, Your suggestion is reasonable. I agree. I would like to make a note that RFC 2833 allows simultaneous audio and DTMF packets in the same stream. So it makes sense jitter buffer to handle such cases by maintaining DTMF packets to take precedence over audio. This means that if DTMF frame is added after audio frame with the same frame number, audio frame is replaced by DTMF but not vice versa. Do you agree with this? In the project where I use jitter buffer it is helpful to know whether the frame has been added to jitter buffer or no. Is it possible to return pj_bool_t by pjmedia_jbuf_put_frame and pjmedia_jbuf_put_frame2 functions in order to report this? Thanks, Vitaly > -----Original Message----- > From: pjsip-bounces@xxxxxxxxxxxxxxx [mailto:pjsip-bounces at lists.pjsip.org] > On Behalf Of Benny Prijono > Sent: Thursday, November 22, 2007 7:49 AM > To: pjsip embedded/DSP SIP discussion > Subject: Re: Handling DTMF packets with jitter buffer > > Hi Vitaly, > > Vitaly Lokhmatov wrote: > > Hi Benny, > > > > I'm working on the project that uses RTP stack from pjmedia library. > There > > is a need to handle incoming DTMF events differently than it is > currently > > done by pjmedia. Actually, what we need is jitter buffer that is able to > > handle DTMF packets. In stream.c, DTMF packets are handled straight away > > they are received from the transport layer, omitting jitter buffer. This > is > > enough for reporting the sequence of incoming DTMF events (as supported > by > > pjmedia stream API), but not enough to maintain synchronization with > audio > > data. PJMEDIA doesn't bind DTMF events to any time frame. However, RTP > and > > RFC2833 do. In order to support this, DTMF packets should pass through > > jitter buffer and be in sync with audio data. Could you advice, how it > is > > possible to achieve? I suggest the following: > > > > 1. Adding PJ_DECL(void) pjmedia_jbuf_put_dtmf_event( pjmedia_jbuf *jb, > const > > pjmedia_rtp_dtmf_event* event, int frame_seq). > > 2. Adding PJMEDIA_JB_DTMF_FRAME item to pjmedia_jb_frame_type enum. > > pjmedia_jbuf_get_frame function would return this constant as > *p_frm_type > > value. In such case, frame parameter value should be interpreted as > > pjmedia_rtp_dtmf_event*. > > > > Do you think such changes to jitter buffer source code are reasonable? > Do > > you have any other suggestions? > > > I think that's a very good idea, I support that! > > One thing that's probably worth discussing, what if instead of > adding pjmedia_jbuf_put_dtmf_event(), we add this instead: > > PJ_DECL(void) pjmedia_jbuf_put_frame2(pjmedia_jbuf *jb, > int frame_type, > const void *frame, > pj_size_t frame_size, > int frame_seq); > > The difference between pjmedia_jbuf_put_frame2() and the usual > pjmedia_jbuf_put_frame() is it allows application to specify the > frame type of the frame. The existing pjmedia_jbuf_put_frame() then > can be modified to just call pjmedia_jbuf_put_frame2(). > > I prefer this over pjmedia_jbuf_put_dtmf_event(), first because it > works more genericly just in case we need to add different frame > type in the future (not that I can think of any, but just in case), > and second is to avoid making the jitter buffer dependent to rtp.h. > Currently the jitter buffer does not depend on anything else in > pjmedia, and probably this is a good thing to maintain. > > What do you think? > > cheers, > -benny > > > Thank you, > > Vitaly Lokhmatov > > > -- > Benny Prijono > http://www.pjsip.org > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
