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 <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/0a4f4c16/attachment.html>
