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 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
-----Inline Attachment Follows-----
_______________________________________________
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/f415a218/attachment-0001.html>
