Hi Chris, I believe this is what the RFC says: However, in the case of RTP, the mapping from a particular dynamic payload type number to a particular codec within that media stream MUST NOT change for the duration of a session. For example, if A generates an offer with G.711 assigned to dynamic payload type number 46, payload type number 46 MUST refer to G.711 from that point forward in any offers or answers for that media stream within the session. However, it is acceptable for multiple payload type numbers to be mapped to the same codec, so that an updated offer could also use payload type number 72 for G.711. So PJSIP's offer is valid. Regards, Ming On Thu, Nov 14, 2013 at 2:13 AM, Chris Gibson <chris.gibson at voxygen.co.uk>wrote: > Hi, > Our client using PJSIP (v2.0.1) is experiencing lost audio on resuming a > held incoming call and at first glance it seems to be due to SDP records > sent with in-dialog SIP INVITEs. > The client initially receives an SDP offer in the incoming SIP INVITE from > a third party SIP client: > <snip> > m=audio 35198 RTP/AVP 98 99 3 8 0 101 13 > a=rtpmap:98 SPEEX/16000 > a=rtpmap:99 SPEEX/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > <snip> > > The PJSIP client responds with the negotiated SDP in the 200OK > <snip> > m=audio 40000 RTP/AVP 98 101 > a=sendrecv > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=rtpmap:98 speex/16000 > <snip> > > Placing the call on hold some time later with pjsua_call_set_hold however > generates and sends an in-dialog INVITE including an SDP record: > <snip> > m=audio 40000 RTP/AVP 103 102 3 8 0 101 > a=rtpmap:103 speex/16000 > a=rtpmap:102 speex/8000 > a=rtpmap:3 GSM/8000 > a=rtpmap:8 PCMA/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=sendonly > <snip> > > Changing the mapping of dynamic payload types for speex/16000 and > speex/8000 from the initial SDP offer seems contrary to section 8.3.2 of > RFC3264 - An Offer/Answer Model with the Session Description Protocol (SDP) > (https://tools.ietf.org/html/rfc3264#section-8.3.2) > > Subsequently resuming this call with pjsua_call_reinvite also issues an > INVITE with an SDP record similar to that generated by pjsua_call_set_hold. > The result is log messages from PJSIP "strm0x871ff844 Bad RTP pt 98 > (expecting 103)" and audio is heard in only one direction. > > Am I missing something or should I suspect PJSIP? > Thanks for any help. > > Regards, > Chris Gibson. > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20131114/53552e72/attachment-0001.html>
