Summary:	ASTERISK-23082: Including g722 in pjsip codec configuration results in unexpected SDP offers
Reporter:	xrobau (xrobau)	Labels:
Date Opened:	2013-12-31 18:37:56.000-0600	Date Closed:	2014-01-25 20:12:25.000-0600
Priority:	Major	Regression?	Yes
Status:	Closed/Complete	Components:	Channels/chan_pjsip Resources/res_pjsip
Versions:	12.0.0	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) codec_tests.pcap ( 1) full.txt ( 2) pjsip.txt ( 3) With_g722.txt ( 4) Without_g722.txt
Description:	When an endpoint is created that includes g722 as a codec, when an invite is sent to that device, no other codecs are included in the INVITE.
Comments:	By: Rusty Newton (rnewton) 2014-01-02 19:12:23.889-0600 Using a single phone, and a CLI originate to send a call out to it, I couldn't reproduce this issue. That is, using g722 as the first codec still resulted in an SDP that presented all of the allowed codecs. However when calling from Phone A to Phone B, I did either the same or a similar issue, where codecs presented in SDP are somewhat erratic depending on the order of the codecs set in allow for each endpoint. In general I could never get more than a single codec sent out in SDP to an endpoint, unless I specifically added g722 as non-first codec to the calling endpoints configuration. Yeah it doesn't make any sense. Otherwise I always saw the first codec only, of the calling endpoint used in the initial INVITE out to the called party. I'll upload some traces and configuration tomorrow. By: Rusty Newton (rnewton) 2014-01-03 15:18:55.661-0600 I've attached a full.txt,codec_tests.pcap and pjsip.txt The configuration in pjsip.txt was used to make the calls in full.txt and codec_tests.pcap. Two Digium phones were involved, the phones themselves were both configured to have ulaw,alaw,g722 codec preference order. You'll see the pjsip.conf configuration in the pjsip.txt file, I have the following codec order for 6001 and 6002: * 6001:  allow=ulaw,g722,alaw,gsm,ilbc * 6002:  allow=ulaw,alaw,gsm,ilbc Here is what I saw on my three test calls (included in the debug) # Calling from 6001 to 6002 results in SDP going out to 6002 showing ulaw,alaw,gsm,ilbc # Calling from 6002 to 6001 results in SDP going out to 6001 showing ulaw # Originating a call to 6001 via CLI results in SDP going out to 6001 showing ulaw,g722,alaw,gsm,ilbc Number 2 seems odd.. Not sure why we don't present the available codecs there. If I change around the codec order, for example putting g722 as the preferred codec, then we only send g722. Which may be what is happening in your case. Another odd thing. If I remove g722 from the configuration for 6001 and then repeat these tests.. then we see only ulaw go out in SDP for both calls 1 and 2. By: Joshua C. Colp (jcolp) 2014-01-03 15:30:56.645-0600 So, the reason this occurs: When setting up an outgoing leg the code internally can request formats. There is some code which, under some circumstances, determines that a single audio codec is "preferred" and passes this on to the outgoing channel driver. In the case of chan_sip this is effectively a suggestion that it be put into the list. In the case of chan_pjsip it seems that the code *only* uses the requested audio format, therefore dropping all the rest. This is a valid issue and spending any time further isolating the behavior of chan_pjsip is unwarranted. We should confirm the behavior of chan_sip and duplicate it in chan_pjsip. IMO. By: Joshua C. Colp (jcolp) 2014-01-18 11:18:34.532-0600 A code review is now up at https://reviewboard.asterisk.org/r/3140/ which fixes the underlying issue here.