Hi, I have a question about the codec selection during an "INVITE" request. I want to use the iLBC codec and to do that I set a higher priority. I activate the log in the library and below there are traces of an INVITE request: - client: INVITE/cseq=31666 (tdta0x73a678) to UDP 64.34.49.82:5060: INVITE sip:5145294251 at sip6.van.netvoice.ca SIP/2.0 Via: SIP/2.0/UDP 192.168.2.102:5060;rport;branch=z9hG4bKPjj5ATg0Ya9xVW0d2vTtMyPdYlvpmDk7P6 Max-Forwards: 70 From: sip:nv2.ctci01.a at sip6.van.netvoice.ca;tag=Ah5zdhyiX0myLzxhYAH776mnSQZlZDOZ To: sip:5145294251 at sip6.van.netvoice.ca Contact: <sip:nv2.ctci01.a at 69.159.242.205:1292;transport=UDP> Call-ID: JLjItY2mS8Mwkw1bAzF12M6iic4G40vO CSeq: 31666 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, norefersub Proxy-Authorization: Digest username="nv2.ctci01.a", realm="sip6.van.netvoice.ca", nonce="764e2ef9", uri="sip:5145294251 at sip6.van.netvoice.ca", response="51a4f7de3b8993973a30d1e0e4f387ee", algorithm=MD5 Content-Type: application/sdp Content-Length: 349 v=0 o=- 3448991582 3448991582 IN IP4 192.168.2.102 s=pjmedia c=IN IP4 192.168.2.102 t=0 0 a=X-nat:0 m=audio 4000 RTP/AVP 117 3 0 8 101 a=rtcp:4001 IN IP4 192.168.2.102 a=rtpmap:117 iLBC/8000 a=fmtp:117 mode=30 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=sendrecv a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 --end msg--State changed from Null to Calling, event=TX_MSGTransaction - server response: SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.2.102:5060;branch=z9hG4bKPjj5ATg0Ya9xVW0d2vTtMyPdYlvpmDk7P6;received =69.159.242.205;rport=1292 From: sip:nv2.ctci01.a at sip6.van.netvoice.ca;tag=Ah5zdhyiX0myLzxhYAH776mnSQZlZDOZ To: sip:5145294251 at sip6.van.netvoice.ca;tag=as367c40fa Call-ID: JLjItY2mS8Mwkw1bAzF12M6iic4G40vO CSeq: 31666 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:5145294251 at 64.34.49.82> Content-Type: application/sdp Content-Length: 307 v=0 o=root 2719 2720 IN IP4 64.34.49.82 s=session c=IN IP4 64.34.49.82 t=0 0 m=audio 17636 RTP/AVP 0 3 117 101 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:117 iLBC/8000 a=fmtp:117 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 200/INVITE/cseq=31666 (rdata0x71d734) in state As we can see the client propose in media session iLBC codec in the 1st position as expected. The proxy server responds with its list of codecs with PCMU 1st position. My question is why the application takes all the time the proxy server 1st position codec (in our case PCMU)? - there is a trace where we can find the selected codec: --end msg--Incoming Response msg 183/INVITE/cseq=31666 (rdata0x71d734) in state ProceedingState changed from Proceeding to Proceeding, event=RX_MSGReceived Response msg 183/INVITE/cseq=31666 (rdata0x71d734)Route-set updatedTransaction tsx0x74170c state changed to ProceedingCall 0 state=EARLYGot SDP answer in Response msg 183/INVITE/cseq=31666 (rdata0x71d734)SDP negotiation done, status=0Call 0: remote NAT type is 0 (Unknown)VAD temporarily disabledpjmedia_rtp_session_init: ses=0x744714, default_pt=0, ssrc=0x675eed34pjmedia_rtp_session_init: ses=0x744d38, default_pt=0, ssrc=0x675eed34Stream strm0x742f14 createdEncoder stream startedDecoder stream startedMedia updates, stream #0: PCMU (sendrecv)Port 1 (sip:5145294251 at sip6.van.netvoice.ca) transmitting to port 0 (Symbian Audio)Port 0 (Symbian Audio) transmitting to port 1 (sip:5145294251 at sip6.van.netvoice.ca)- clock -Underflow, buf_cnt=0, will generate 1 frameread_port sip:5145294251 at sip6.van.netvoice.ca: count=320 get_frame, count=160Jitter buffer empty (prefetch=0) rx buffer size is now 160 get_frame, count=160 rx buffer size is now 320write_port sip:5145294251 at sip6.van.netvoice.ca: count=160put_frame sip:5145294251 at sip6.van.netvoice.ca, count=160Start talksprut.. tx_buf count now is 160write_port sip:5145294251 at sip6.van.netvoice.ca: count=160put_frame . Thank you, George. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090421/342bf04d/attachment-0001.html>
