Hi, I think that you'll get the answer here : https://trac.pjsip.org/repos/ticket/476 In fact pjsip does not support multiple codec at a time. That's the reason why it tries to fix codec. That's totally RFC valid (an app can decide to change codec during the communication), and should normally not be a functional problem if the remote side behaves correctly. However, in real life it's very annoying. I don't know if the point is still in roadmap of enhancement of pjsip stack, but I have to say that this point (at least for CSipSimple users) is one of those that is often raised for several real world cases. For example when remote side that does not support UPDATE correctly - for example some grandstream devices (I had to create a patch to add a "force no update" option) (I agree that in this case we can't blame pjsip at all ;) ). Or when the user first reach a server that supports all codecs before sending it to the real remote side : example, first reach some server that is media proxy when in communication but can be also add something in media stream using one of the codec. Then pjsip will force the first codec, and when the negociation will be done on other side you'll not get a real negotiation because only one codec will be proposed to remote side. So in these cases I've to tell users to force the codec they want to use in settings. It's often due to a bug on remote side, but sometimes it's also simply a use case that can't be done due to this limitation of pjsip. And in this case I would say that it would be more legitimate to say that the fix of ticket 476 is a workaround in pjsua rather than a real fix that would allow pjsua/pmedia to support multiple codecs at a time. Or at least an option to do so, because I also agree to say that in other cases, mounting in memory all codecs instances uses more memory and could be something not wanted. Regards, R?gis On 04/03/2012 10:32, Ken Resander wrote: > I have only just started using pjsua from the command line and have > difficulties understanding the the last bit of the log output for > sip:music at iptel.org that plays music. > > Log extracts: > > Make call: sip:music at iptel.org > 17:35:23.976 pjsua_call.c Making call with acc #1 to > sip:music at iptel.org > > OFFER: > >>>INVITE sip:music at iptel.org SIP/2.0 > ... > m=audio 40000 RTP/AVP 98 97 99 104 3 0 8 9 96 > c=IN IP4 192.168.0.2 > a=rtcp:40001 IN IP4 192.168.0.2 > a=sendrecv > a=rtpmap:98 speex/16000 > a=rtpmap:97 speex/8000 > a=rtpmap:99 speex/32000 > a=rtpmap:104 iLBC/8000 > a=fmtp:104 mode=30 > a=rtpmap:3 GSM/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > a=rtpmap:9 G722/8000 > a=rtpmap:96 telephone-event/8000 > a=fmtp:96 0-15 > <<< INVITE 100 Trying... > ANSWER: > <<< INVITE 200 response > ... > m=audio 28108 RTP/AVP 97 104 3 0 8 96 > a=rtpmap:97 speex/8000 > a=rtpmap:104 iLBC/8000 > a=fmtp:104 mode=30 > a=rtpmap:3 GSM/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > a=rtpmap:96 telephone-event/8000 > a=fmtp:96 0-15 > > >>>ACK sip:music at 217.9.36.144:5080 SIP/2.0 > > > Respondent wants speex/8000 the second item in the choice list of the > offer. I don't understand why the offerer continues with the > negotiation?: > > OFFER: > >>>INVITE sip:music at 217.9.36.144:5080 SIP/2.0 > m=audio 40000 RTP/AVP 97 96 > c=IN IP4 192.168.0.2 > a=rtcp:40001 IN IP4 192.168.0.2 > a=sendrecv > a=rtpmap:97 speex/8000 > a=rtpmap:96 telephone-event/8000 > a=fmtp:96 0-15 > <<<INVITE 100 trying > ANSWER: > <<<INVITE 200 response > ... > m=audio 28108 RTP/AVP 97 96 > a=rtpmap:97 speex/8000 > a=rtpmap:96 telephone-event/8000 > a=fmtp:96 0-15 > > > I read RFC3264 - An Offer/Answer Model with the Session Description > Protocol (SDP), but could not see an explanation for this continued > negotiation. Maybe I misunderstood the RFC. > > I would like to understand this a bit better... Guidance most welcome. > > Ken > > > > _______________________________________________ > 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/20120304/9d3b3418/attachment.html>
