Hi Benny, I am certain previous use of my APP and PJSUA to the test site was connecting with a compressed codec, but now they both connect with PCMU. So the packet test results are void. Maybe I was discombobulated :) So this explains the clicking: >But looking at the gsm and g711 source codes again, it looks like by >default the plc is disabled too, since pjsip 0.7! How do we enable the PLC for gsm, g711? And would it not better if they were enabled by default? Regarding the type of silence frames. I did not actually analyse the packets, but assumed they were silence frame as they were consistently at the end of the IVR menu of the test site. Further in the SDP reply the remote site indicates preferences as PCMU then GSM on our side we prefer GSM then PCMU, the remote site's first preference is taken, but in trying to save band with is there a means to choose the lower bandwidth option from the remote preferences? v=0 o=root 5621 5621 IN IP4 81.187.42.200 s=session c=IN IP4 81.187.42.200 t=0 0 m=audio 19922 RTP/AVP 0 3 101 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - --end msg-- 19:39:54.437 pjsua.c Call 0 state changed to CONNECTING 19:39:54.437 strm020BC35C VAD temporarily disabled 19:39:54.437 strm020BC35C Encoder stream started 19:39:54.437 strm020BC35C Decoder stream started 19:39:54.437 pjsua_media.c Media updates, stream #0: PCMU (sendrecv) 19:39:54.437 conference.c Port 1 (sip:904 at mouselike.org) transmitting to por 0 (Microsoft Sound Mapper - Input) ----- Original Message ----- From: "Benny Prijono" <bennylp@xxxxxxxxx> To: "pjsip embedded/DSP SIP discussion" <pjsip at lists.pjsip.org> Sent: Tuesday, October 02, 2007 5:02 PM Subject: Re: [pjsip] How to handle silence / NONE frames?/-clock-rate=8000? > Lafras Henning wrote: > > Hi Benny, > > It is working better now, but I am getting clicks in speech due to packet > > loss. > > This would pretty much depend on the PLC of the codec. What codec > did you use? > > > Tests from my app and PJSUA gave the following results only > > when -clock-rate=8000 > > > > (sip:904 at mouselike.org) > > > > pkt loss=39 (2.5%), > > pkt loss=79 (4.6%), > > pkt loss=51 (3.2%) > > Did you mean you didn't get packet lost with non-8Khz sampling rate? > > I asked you some mails ago about the type of silence frames that you > received. I just found out yesterday that some endpoints send RTP > packet with no payload (see http://www.pjsip.org/trac/ticket/388), > and I'm still not sure what would happen in the jitter buffer when > stream.c receives these packets. Maybe it will treat these as > missing packets thus causing it to trigger the PLC. > > > > CPU use remains low (<2%) but it seems as though re-sample may be affecting > > the thread receiving the packet. > > No, it won't. Incoming (rtp) packets are handled by separate thread > (the worker threads in pjmedia_endpt), and not by the media flow > thread (which belongs to sound device, normally). > > > Do you think the performance would be better if the conference bridge > > remained at 16khz and the port does the re-sampling? > > I'm not sure about it. The best configuration would be if you run > the bridge at the same clock rate as the codec. > > > B.T.W. > >> Frankly this could be a bug (see below). But even if frame.type is > >> NONE, the frame.size would (normally!) be zero too, so it's not a > >> major bug. > > > > In my port I found frame.size to be 320 even when frame.type is NONE. > > Yeah, it's the bridge who's done this. If you connect your port to > some other port (like, stream, for example) directly, frame.size > would normally be set to zero. > > regards, > -benny > > > > > > _______________________________________________ > 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 >
