The problem is the voice when we using the GSM-FR (full rate) codec on Nokia 71 connected on wireless network (case Rogers Canada). The "wav" file is a registration of my voice when I leave a message on my voicemail at home on a PSTN phone. We try to improve the voice quality :-). Thanks, George. _____ From: pjsip-bounces@xxxxxxxxxxxxxxx [mailto:pjsip-bounces at lists.pjsip.org] On Behalf Of Benny Prijono Sent: Tuesday, May 12, 2009 2:14 PM To: pjsip list Subject: Re: audio problem with GSM on Symbian On Tue, May 12, 2009 at 6:57 PM, George Evi <george.evi at ctcinc.ca> wrote: Hi Benny, Thanks for your response. I have already tested in LAN and more than that on Wi-Fi connection and it works fine. Also I tested on wireless network (Access Point Rogers Canada) with PCMU and we got a good voice quality. I see. Sorry if I missed that info. So regarding the problem, what is the problem again? :) I can hear several impairments in the WAV that you sent me, but not sure which particular problem you're referring to. We try to use a codec with less bandwidth (low bit rate) like GSM or iLBC. Unfortunelly our Sip service provider supports for the moments only PCMU, GSM-FR & iLBC mode 30. I tried last week iLBC but for some reason after SIP session when media session starts the application blocks (may be a bug ???). I'll continue to investigate this problem. It's probably because iLBC would take all the CPU in the handset. Talking of which, is APS-Direct out of question? With APS-Direct the codec encoding/decoding will be done in hardware and it also supports iLBC. Could you tell me, how did you test client/pjsua on E70 with different codecs? For us it's easy, we use pjsua on the other side so just needed to disable/enable codecs there. When I do such tests I set the priority at a higher level then the other codecs (e.g. for GSM) in "pjsua_media_subsys_init" (pjsua_media.c) and I comment the section of code in function "process_m_answer" (sdp_neg.c): /* Arrange format in the offer so the order match the priority * in the answer */ //!ge5may09 for (i=0; i<answer->desc.fmt_count; ++i) { // unsigned j; // pj_str_t *fmt = &answer->desc.fmt[i]; // // for (j=i; j<offer->desc.fmt_count; ++j) { // if (pj_strcmp(fmt, &offer->desc.fmt[j])==0) { // str_swap(&offer->desc.fmt[i], &offer->desc.fmt[j]); // break; // } // } // } , because my Voip provider sends always in this order (priority) CSeq: 7436 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:5145294251 at 64.34.49.82 <mailto:sip%3A5145294251 at 64.34.49.82> > Content-Type: application/sdp Content-Length: 307 v=0 o=root 2719 2719 IN IP4 64.34.49.82 s=session c=IN IP4 64.34.49.82 t=0 0 m=audio 18934 RTP/AVP 0 3 113 101 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:113 iLBC/8000 a=fmtp:113 mode=30 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv --end msg--Incoming Response msg 183/INVITE/cseq=7436 (rdata0x71e46c) in state ProceedingState changed from Proceeding to Proceeding, event=RX_MSGReceived , always the PCMU in 1st position. Without comments the codec manager has all the time this order of codecs. Yeah, we don't support multiple/simultaneous codecs (as Asterisk indicated in the 200/OK), so we'll just take the first one. Is there another way to have the same result? What if you enable only one codec at a time in the application? According to the spec, callee/answerer should only answer with codec(s) which are available in the offer, so it should choose one codec in the answer too. cheers Benny -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090512/9e15818d/attachment-0001.html>
