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/20131121/658e2f7c/attachment-0001.html>
