Summary:ASTERISK-22070: Investigate PJMEDIA's implicit codec negotiation behavior
Reporter:Mark Michelson (mmichelson)Labels:
Date Opened:2013-07-12 12:27:43Date Closed:2013-09-20 13:27:10
Versions:12 Frequency of
Description:While attempting to make an equivalent option to chan_sip's preferred_codec_only, I ran across interesting behavior in chan_gulp. I configured two peers, carol and bob. carol is configured to allow=g722,ulaw,alaw. bob is configured to allow=ulaw. Direct media is not enabled.

Carol places a call to Bob through Asterisk. Carol's INVITE contains an SDP offer with ulaw, alaw, g.722, and other codecs. Asterisk sends an INVITE to bob that contains only a ulaw offer. Bob's phone replies with a 200 OK with a ulaw answer. Asterisk then sends a 200 OK with an SDP answer for Carol that contains only g.722. If I change the order of the allow statement for Carol to be allow=ulaw,g722,alaw, then in the same situation, the SDP in the 200 OK from Asterisk to carol contains only ulaw.

From my debugging, it appeared that when the initial INVITE from Carol arrived, Asterisk properly determined the intersection of the offered codecs in the INVITE and the configured codecs for Carol. Asterisk then called the create_outgoing_sdp_stream() callback and added the codecs to the local SDP.  After Bob answered the call, PJSIP called into Carol's inv_session's on_media_update() callback. When we call pjmedia_sdp_neg_get_active_local(), the returned SDP's audio stream contains only the first configured codec for the endpoint.

We should be answering with all configured codecs for Carol since she supports them all. An investigation needs to be conducted to see if

1) The SDP negotiator in PJMEDIA needs to be told to place multiple codecs in its negotiated SDPs.
2) We are misusing the SDP that PJMEDIA gives us in the on_media_update() callback
3) If there is some other erroneous code that is causing this behavior.