Checking that Codec is Negotiated Properly by Both Parties (moved)

Moved to: ​https://docs.pjsip.org/en/latest/specific-guides/audio-troubleshooting/checks/codec_nego.html

Normally both parties should agree on the same codec to be used for the session (call), but sometimes either party gets it wrongly and the call ends up using different codec to encode/decode the packets.

Problems with Codec Negotiation

Different iLBC Mode Used by Either Party

iLBC has two framing modes: 20ms or 30ms. Each party specifies which framing mode it wants to receive by specifying the following line in the SDP:

a=fmtp:117 mode=20

PJMEDIA SHOULD allow different modes to be used for TX and RX, and it obeys the fmtp mode that the remote party wants to receive and that it indicates in the SDP that it sends. However, if the remote party is not PJSIP, it might not be able to do this.

Note: there was this ticket #40 which prevent iLBC session to work correctly when local and remote endpoint has different iLBC mode, but this has been fixed in Dec 29, 2006.

To verify whether this is or isn't the case, you can experiment with changing the iLBC mode that is used by pjsua with using --ilbc-mode=20 or --ilbc-mode=30 command line argument. This will change the mode preference that is advertised by PJSIP in the outgoing SDP.

Complete Mess-Up with Codec Negotiation

In the worst case, it is also possible that remote has completely messed up codec negotiation, and both parties end up with completely different codec for the call! If PCMA/PCMU codec negotiation mismatches, both may end up with a noisy audio.

Checking Which Codec is Being Used by pjsua

Use pjsua's dq (dump quality) command from pjsua menu to check which codec is being used for the call:

>>> dq
 19:01:38.878        pjsua.c
  [CONFIRMED ] To: sip:localhost;tag=213e15bcf98b4c0394a402881e885431
    Call time: 00h:01m:44s, 1st res in 1452 ms, conn in 1682ms
    #0 iLBC @8KHz, sendrecv, peer=192.168.0.66:4000
       RX pt=117, stat last update: 00h:00m:01.943s ago
          total 4.3Kpkt 164.0KB (302.2KB +IP hdr) @avg=12.5Kbps
          pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
                (msec)    min     avg     max     last
          loss period:   0.000   0.000   0.000   0.000
          jitter     :   0.125  15.779 1695.000   1.250
       TX pt=117, ptime=20ms, stat last update: 00h:00m:09.304s ago
          total 5.1Kpkt 197.2KB (363.4KB +IP hdr) @avg 15.0Kbps
          pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
                (msec)    min     avg     max     last
          loss period:   0.000   0.000   0.000   0.000
          jitter     :  14.750  15.570  18.875  18.875
      RTT msec       :   0.854  24.516 125.000  18.783

The important bit of above output is this line:

    #0 iLBC @8KHz, sendrecv, peer=192.168.0.66:4000

which tells that iLBC is being used for the call (although unfortunately it doesn't tell the mode).

Try to Use Other Codec

If you know what codec is likely to be used by remote party, you can force pjsua to prefer certain codec to be used, by using --add-codec NAME command. The NAME can be one of the following:

• pcma
• pcmu
• speex/8000
• speex/16000
• speex/32000
• ilbc
• gsm

For iLBC, you can change the RX mode used by pjsua with using --ilbc-mode=20 or --ilbc-mode=30 command line argument.