[pjsip] New features: audio latency, NAT, PRACK/UPDATE, AKA, etc.

Madhuri Patwardhan madhuri_patwardhan at yahoo.com
Wed Nov 21 04:46:02 EST 2007

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.


----- Original Message ----
From: Benny Prijono <bennylp at pjsip.org>
To: pjsip embedded/DSP SIP discussion <pjsip at lists.pjsip.org>
Sent: Sunday, October 21, 2007 5:27:27 AM
Subject: Re: [pjsip] 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!


> Madhuri 

Visit our blog: http://blog.pjsip.org

pjsip mailing list
pjsip at lists.pjsip.org

Be a better pen pal. 
Text or chat with friends inside Yahoo! Mail. See how.  http://overview.mail.yahoo.com/

More information about the pjsip mailing list