| 1 | = Checking that Codec is Negotiated Properly by Both Parties = |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | == Problems with Codec Negotiation == |
| 6 | |
| 7 | === Different iLBC Mode Used by Either Party === |
| 8 | |
| 9 | 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: |
| 10 | {{{ |
| 11 | a=fmtp:117 mode=20 |
| 12 | }}} |
| 13 | |
| 14 | '''PJMEDIA allows different modes to be used for TX and RX''', and it obeys the '''fmtp mode''' that the remote party wants in the SDP that it sends. However it is possible that remote endpoint doesn't support different mode for TX and RX and only wants to transmit or receive a mode that is specified in its settings. |
| 15 | |
| 16 | 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. |
| 17 | |
| 18 | |
| 19 | === Complete Mess-Up with Codec Negotiation === |
| 20 | |
| 21 | 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. |
| 22 | |
| 23 | |
| 24 | == Checking Which Codec is Being Used by pjsua == |
| 25 | |
| 26 | Use pjsua's '''{{{dq}}}''' (dump quality) command from pjsua menu to check which codec is being used for the call: |
| 27 | |
| 28 | {{{ |
| 29 | >>> dq |
| 30 | 19:01:38.878 pjsua.c |
| 31 | [CONFIRMED ] To: sip:localhost;tag=213e15bcf98b4c0394a402881e885431 |
| 32 | Call time: 00h:01m:44s, 1st res in 1452 ms, conn in 1682ms |
| 33 | #0 iLBC @8KHz, sendrecv, peer=192.168.0.66:4000 |
| 34 | RX pt=117, stat last update: 00h:00m:01.943s ago |
| 35 | total 4.3Kpkt 164.0KB (302.2KB +IP hdr) @avg=12.5Kbps |
| 36 | pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%) |
| 37 | (msec) min avg max last |
| 38 | loss period: 0.000 0.000 0.000 0.000 |
| 39 | jitter : 0.125 15.779 1695.000 1.250 |
| 40 | TX pt=117, ptime=20ms, stat last update: 00h:00m:09.304s ago |
| 41 | total 5.1Kpkt 197.2KB (363.4KB +IP hdr) @avg 15.0Kbps |
| 42 | pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%) |
| 43 | (msec) min avg max last |
| 44 | loss period: 0.000 0.000 0.000 0.000 |
| 45 | jitter : 14.750 15.570 18.875 18.875 |
| 46 | RTT msec : 0.854 24.516 125.000 18.783 |
| 47 | }}} |
| 48 | |
| 49 | The important bit of above output is this line: |
| 50 | |
| 51 | {{{ |
| 52 | #0 iLBC @8KHz, sendrecv, peer=192.168.0.66:4000 |
| 53 | }}} |
| 54 | |
| 55 | which tells that iLBC is being used for the call (although unfortunately it doesn't tell the mode). |
| 56 | |
| 57 | |
| 58 | == Try to Use Other Codec == |
| 59 | |
| 60 | 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: |
| 61 | * pcma |
| 62 | * pcmu |
| 63 | * speex/8000 |
| 64 | * speex/16000 |
| 65 | * speex/32000 |
| 66 | * ilbc |
| 67 | * gsm |
| 68 | |
| 69 | For iLBC, you can change the RX mode used by pjsua with using '''{{{--ilbc-mode=20}}}''' or '''{{{--ilbc-mode=30}}}''' command line argument. |