Hi Benny,
Sorry for the late reply.
My patch sends 3 end of event packets for each dtmf digit irrespective of the next digit in the queue. Perhaps, I am missing something but thats what I see sjphone and other voip clients doing. 3 end of event packets are sent irrespective of the next dtmf digit in the queue. The remote end client to which we are connecting using pjsip recommends using 3 end of event packets.
Madhuri
----- Original Message ----
From: Benny Prijono <bennylp@xxxxxxxxx>
To: pjsip embedded/DSP SIP discussion <pjsip at lists.pjsip.org>
Sent: Sunday, October 21, 2007 5:27:27 AM
Subject: Re: New features: audio latency, NAT, PRACK/UPDATE, AKA, etc.
Madhuri Patwardhan wrote:
> Hi,
>
> I tried the new version and some of the new features
> from the trunk. It is working fine.
>
> Few things I noticed are as follows:
>
> 1] Ticket #363: Incorrect RTP marker and timestamp in
> DTMF event/RFC 2833 packet
> Note:
> One issue that hasn't been fixed:
> RFC 2833 Section 3.6:
> If there has been no new event in the last
> interval, the event SHOULD be retransmitted three
> times or until the next event is recognized. This
> ensures that the duration of the event can be
> recognized correctly even if the last packet for an
> event is lost
>
> I had modified code to fix the above issue mentioned
> in the Note. I had sent the modified file. Would you
> like me to send it again or send the diff of the
> files; in case it is useful for you.
IIRC, your patch didn't check if there is additional events in the
DTMF buffer, so any digits will be retransmitted three times
regardless of whether there is a pending digit in the transmission
list or not. So for example if we have "123" digits in the queue, it
will retransmit all digits ("1", "2", and "3") three times, while it
should only retransmit the last digit ("3") three times.
> 2] Even after ticket #363 fix, the RTP packets of DTMF
> do not have 20 ms gap in between. They are sent all
> bundled together with no nice timing between them. I
> had added delay with Pa_sleep() to generate the 20 ms
> gap between the packets.
Please see http://www.pjsip.org/trac/wiki/FAQ#tx-timing
But the timing should be better now in the latest SVN trunk (r1513),
at least on Windows, since I've changed few stuffs related to audio
(mostly to reduce latency, but perhaps it will make the TX timing
works better too).
>
> Thanks for the good software. It is working great.
Well thanks for the constant feedbacks, that's what making this
software better!
regards,
-benny
> Madhuri
_______________________________________________
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
____________________________________________________________________________________
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/
