Hi Ming, Any thoughts on the amended scenario below? We're still encountering lost audio with SDP remapping. Could this be a build configuration issue on our side? If this is reproducible for you and deemed worth addressing, what steps should I take to raise a ticket? If any solution allowed reuse of the original SDP payload values from an incoming INVITE, our audio issue might disappear. Many thanks, Chris Begin forwarded message: > From: Chris Gibson <chris.gibson@xxxxxxxxxxxxx> > Subject: Re: Lost audio on resuming held call on pjsip 2.0.1 > Date: 21 November 2013 13:54:31 GMT > To: pjsip list <pjsip at lists.pjsip.org> > > Hi Ming, > I've amended the scenario which I believe doesn't match the G.711 example. Dynamic payload 103 seems to change from G7221 to SPEEX. > > The client initially receives an SDP offer in the incoming SIP INVITE from a third party SIP client: > <snip> > m=audio 63264 RTP/AVP 98 99 100 102 103 104 9 105 0 8 3 101 13 > a=rtpmap:98 SPEEX/16000 > a=rtpmap:99 iLBC/8000 > a=fmtp:99 mode=30 > a=rtpmap:100 iLBC/8000 > a=fmtp:100 mode=20 > a=rtpmap:102 SPEEX/32000 > a=rtpmap:103 G7221/32000 > a=fmtp:103 bitrate=48000 > a=rtpmap:104 G7221/16000 > a=fmtp:104 bitrate=32000 > a=rtpmap:105 SPEEX/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > <snip> > > The PJSIP client responds in the 200OK > <snip> > m=audio 40004 RTP/AVP 98 101 > a=sendrecv > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=rtpmap:98 speex/16000 > <snip> > > A call to pjsua_call_set_hold sends an in-dialog INVITE from the PJSIP client with: > <snip> > m=audio 40004 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> > > Thanks for any help. > > Regards, > Chris > > On 14 Nov 2013, at 01:59, Ming <ming at teluu.com> wrote: > >> 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 >> >> >> _______________________________________________ >> 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/20140120/a15b110a/attachment-0001.html>
