Hi, The point is about media part of pjsip in fact. It is not designed to support the treatment of multiple codecs in the incoming stream. Benny can probably confirm that, but that's my understand of the problem. What does pjsip is completely RFC valid. It does not break any of the point you mentioned ! And it actually use the last point about modifying to fix only one codec. The SIP RFC allows that! The app *MAY* issue a modify... so pjsua does... It's the "normal" behavior of pjsip to do that after the negociation reach to a multiple codec session. Since it's not forbidden by the RFC, the stack can do that ! Any SIP client can do that. So it's a valid behavior to send a re-invite/update. Actually pjsip behaves correctly with the multiple codecs and SDP negociation goes well. The point is that the media layer can't support multiple codec at a time (as far as I understood). The codec manager will initialize only one codec and there is nothing to dispatch RTP packets from their RTP type to one of the codec backend. There is only one check that may warn in logs about the fact the media layer received some unexpected rtp type packet. It's actually about a limitation of the implementation.*BUT* the way this limitation is solved is absolutely valid. Nothing in RFC prevents a client from sending a re-INVITE/UPDATE. If the other doesn't manage correctly the re-INVITE/UPDATE, the bug and the side that does not respect the RFC is the other side not pjsip ! As I said before, I don't tell that's a good way to solve this limitation. And I would vote to have that fixed inside pjmedia. Maybe I will have a look on that one day and contribute something. On your side Ken you can also try to contribute something if this limitation also annoy you. But again, if you actually get a problem because of another side that does not support re-INVITE/UPDATE properly, the first culprit is on the side that does not accept the re-INVITE/UPDATE. Le 5 mars 2012 11:43, Ken Resander <kresander at yahoo.com> a ?crit : > Many thanks Regis, > > I don't understand what 'pjsua cannot handle multiple codecs' or 'can only > handle one codec' means in the context of sending and receiving SDP > negotiation information via SIP INVITEs. > > RFC 3264: > > OFFER page 6: > .... > For sendrecv RTP streams, the payload type numbers indicate the value of > the payload type field the offerer expects to receive, and would prefer to > send. > .... > In all cases, the formats in the "m=" line MUST be listed in order of > preference, with the first format listed being preferred. In this case, > preferred means that the recipient of the offer SHOULD use the format with > the highest preference that is acceptable to it. > > ANSWER page 9: > > For streams marked as sendrecv in the answer, the "m=" line MUST contain > at least one codec the answerer is willing to both send and receive, from > amongst those listed in the offer. The stream MAY indicate additional media > formats, not listed in the corresponding stream in the offer, that the > answerer is willing to send or receive. > > OFFERER PROCESSING ANSWER page 11: > ... > It (offerer) MUST send using a media format listed in the answer, > and it SHOULD use the first media format listed in the answer when it > does send. > > MODIFYING ,,, page12: > > At any point during the session, either participant MAY issue a new > offer to modify characteristics of the session... using > the exact same offer/answer procedure defined above... > > > If I have understood the RFC, the negotiation could/should be over after > the initial offer and initial answer, since both parties have what they > want and can process (format speex/8000). Then I don't understand why the > negotiation continues with a second offer&answer pair since that adds one > more round-trip to the connect processing with no new wishes provided and > exchanged. It is probably blatantly obvious, but I am new to this and > cannot see it. > > Still struggling..... > > Ken > > > --- On *Sun, 4/3/12, R?gis Montoya <r3gis.3r at gmail.com>* wrote: > > > From: R?gis Montoya <r3gis.3r@xxxxxxxxx> > Subject: Re: Difficulties understanding SDP Offer/Answer when > running pjsua > To: "pjsip list" <pjsip at lists.pjsip.org> > Date: Sunday, 4 March, 2012, 7:43 PM > > > 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 <http://mc/compose?to=sip:music at iptel.org> that plays > music. > > Log extracts: > > Make call: sip:music at iptel.org <http://mc/compose?to=sip:music at iptel.org> > 17:35:23.976 pjsua_call.c Making call with acc #1 to > sip:music at iptel.org <http://mc/compose?to=sip:music at iptel.org> > > OFFER: > >>>INVITE sip:music at iptel.org <http://mc/compose?to=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<http://mc/compose?to=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<http://mc/compose?to=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 listpjsip at lists.pjsip.org <http://mc/compose?to=pjsip at lists.pjsip.org>http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > -----Inline Attachment Follows----- > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org <http://mc/compose?to=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/20120305/ce753fdd/attachment.html>
