Hi, My name is Bill, and I?ve been enjoying using PJSIP for a while now. I?m having an issue where incoming calls? SDP rtpmap dynamic (96+) codec identifier is not respected after being locally held and resumed. == Initial SDP from server == v=0 o=FreeSWITCH 1425683823 1425683824 IN IP4 x.x.x.x s=FreeSWITCH c=IN IP4 x.x.x.x t=0 0 m=audio 14662 RTP/AVP 18 0 98 101 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:0 PCMU/8000 a=rtpmap:98 iLBC/8000 a=fmtp:98 mode=20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 == PJSIP response SDP == SIP/2.0 200 OK ? v=0 o=- 3634687285 3634687286 IN IP4 x.x.x.x s=pjmedia b=AS:32 t=0 0 a=X-nat:0 m=audio 4002 RTP/AVP 98 101 c=IN IP4 x.x.x.x b=TIAS:15200 a=rtcp:4003 IN IP4 x.x.x.x a=sendrecv a=rtpmap:98 iLBC/8000 a=fmtp:98 mode=20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 == Hold activation SDP from PJSIP (pjsua_call_set_hold()) == v=0 o=- 3634687285 3634687287 IN IP4 x.x.x.x s=pjmedia b=AS:32 t=0 0 a=X-nat:0 m=audio 4002 RTP/AVP 104 96 c=IN IP4 x.x.x.x b=TIAS:15200 a=rtcp:4003 IN IP4 x.x.x.x a=rtpmap:104 iLBC/8000 a=fmtp:104 mode=20 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-16 a=sendonly == Server Response 200 OK SDP == v=0 o=FreeSWITCH 1425683823 1425683825 IN IP4 x.x.x.x s=FreeSWITCH c=IN IP4 x.x.x.x t=0 0 m=audio 14662 RTP/AVP 104 96 a=rtpmap:104 iLBC/8000 a=fmtp:104 mode=20 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-16 a=recvonly a=silenceSupp:off - - - - a=ptime:20 Notice that iLBC has changed from 98 to 104. Now, when the call is resumed, it resends that same SDP as above in the INVITE. Audio from PJSIP works fine, but there?s no incoming audio. In the log (level 4+), I get one of these every 20ms: [PJSIP:4] 16:20:38.115 strm0x12815262 !Bad RTP pt 98 (expecting 104) [PJSIP:4] 16:20:38.133 strm0x12815262 Bad RTP pt 98 (expecting 104) [PJSIP:4] 16:20:38.153 strm0x12815262 Bad RTP pt 98 (expecting 104) [PJSIP:4] 16:20:38.173 strm0x12815262 Bad RTP pt 98 (expecting 104) I believe what happened is that the server recognizes it will be getting iLBC packets as payload type 104, but it will not send the RTP iLBC packets as PT 104. It?s still using the originally-negotiated PT 98 for send. Now, PJSIP documentation notes that this may happen: #define PJMEDIA_STREAM_CHECK_RTP_PT 1 Perform RTP payload type checking in the stream. Normally the peer MUST send RTP with payload type as we specified in our SDP. Certain agents may not be able to follow this hence the only way to have communication is to disable this check. - http://www.pjsip.org/pjmedia/docs/html/group__PJMEDIA__CONFIG.htm#gab5d0ea77ee75392db6b9a6d0d6fa0d57 <http://www.pjsip.org/pjmedia/docs/html/group__PJMEDIA__CONFIG.htm#gab5d0ea77ee75392db6b9a6d0d6fa0d57> This flag has no effect, and a search of the source files reveals that it?s only ever set in config.h:572; it?s never used. I altered pjmedia/src/pjmedia/rtp.c:228 as follows: #if PJMEDIA_STREAM_CHECK_RTP_PT if (check_pt && hdr->pt != ses->out_pt) { if (p_seq_st) { p_seq_st->status.value = seq_st.status.value; p_seq_st->status.flag.bad = 1; p_seq_st->status.flag.badpt = 1; } return; } #endif I compiled this change, and I ran several test calls. This appears to fix the issue with no side-effects. Of course, I don?t know PJSIP all that well, so other changes may be needed. Thank you for your time. Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20150306/a5fc2dc9/attachment.html>
