I’ve got an issue with codecs in asterisk 1.8.4.4. The remote peer only supports alaw, which asterisk identifies, but for some reason read/write format is set to g726 anyway. This results in audio working from peer to asterisk but not the otherway.
debug log (call from asterisk to peer):
Capabilities: us - 0x80c (ulaw|alaw|g726), peer - audio=0x8 (alaw)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x8 (alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
[Nov 8 09:07:06] DEBUG[2148]: res_rtp_asterisk.c:2391 ast_rtp_remote_address_set: Setting RTCP address on RTP instance '0x5f9090’
Peer audio RTP is at port 192.168.0.10:36832
[Nov 8 09:07:06] DEBUG[2148]: rtp_engine.c:516 ast_rtp_codecs_payloads_copy: Copying payload 8 from 0x7e1fb910 to 0x5f9240
[Nov 8 09:07:06] DEBUG[2148]: rtp_engine.c:516 ast_rtp_codecs_payloads_copy: Copying payload 101 from 0x7e1fb910 to 0x5f9240
[Nov 8 09:07:06] DEBUG[2148]: chan_sip.c:8863 process_sdp: We’re settling with these formats: 0x8 (alaw)
[Nov 8 09:07:06] DEBUG[2148]: chan_sip.c:8868 process_sdp: We have an owner, now see if we need to change this call
[Nov 8 09:07:06] DEBUG[29496]: channel.c:4693 ast_write: Deadlock avoided for write to channel ‘SIP/mypeer-00000053’
[Nov 8 09:07:06] DEBUG[2148]: chan_sip.c:8875 process_sdp: Oooh, we need to change our audio formats since our peer supports only 0x8 (alaw) and not 0x800 (g726)
[Nov 8 09:07:06] DEBUG[2148]: channel.c:5048 set_format: Set channel SIP/mypeer-00000053 to read format g726
[Nov 8 09:07:06] DEBUG[2148]: channel.c:5048 set_format: Set channel SIP/mypeer-00000053 to write format g726
It is using G.726 because that is the only acceptable codec on the incoming side of the call! You only appear to have provided details about the negotiation for the outgoing side.
I think you should probably take this to the developer mailing list or IRC channel.
The codecs are constrained to those common between sip.conf and the remote device. That is very intentional. If it allowed all the codecs at that stage, it would still end up having to transcode.
Where Asterisk does have limitations is that it assumes that a peer will only send in the formats in which it is prepared to receive, so, if it makes the second offer, it will be constrained by the contents of the first offer.
The other limitation is that it will always have made its offer to the calling party before starting the negotiation with the called party, but, in late offer cases, it may not have seen the calling party’s offer before doing so. It always uses early offer, itself. This means that the choices for the called party are not influenced by the calling party.
There are variables you can set to constrain the outgoing side codec choice, if you have additional knowledge about the codec combination for the particular call.
Note that a SIP peer can use any of the negotiated codecs, and, at least in theory, can arbitrarily change, mid call.
The incoming side supports g726, alaw and ulaw. It’s configured with the same codecs in the same order as the outgoing side (SIP).
How is the incoming side notified of which codec is negotiated? I mean, after the reception of a “200 Ok”, how can the incoming side tell which codec is used? Should it only look at the incoming frames?
The incoming side is told the incoming codec in the incoming RTP.
On the SIP/SDP side:
a) Early offer:
The INVITE lists the codecs that the caller is prepared accept for upstream traffic. The 200 OK lists the codecs Asterisk is prepared to accept for downstream traffic. Asterisk limits these to those in common with those in the INVITE.
b) Late offer:
There is no SDP on the INVITE. Asterisk lists all the supported codecs for the device on the 200 OK. The device lists the codecs it is prepared to accept (which may or may not be constrained by those offered by Asterisk) on the ACK.
In both cases:
Asterisk uses the first choice(?) codec for the device for upstream traffic.
The device chooses one of the codecs offered by Asterisk for the downstream traffic.
On the outgoing side, Asterisk always does an early offer, using all the codecs permitted by sip.conf for that device, unless channel variables are set to further constrain that.
In both directions, if the codec chosen by the peer is acceptable to the other peer, it is passed through, otherwise it is transcoded.
To stress one point, codecs aren’t actually negotiated in SIP/SDP; each side simply says what it is prepared to accept (even if Asterisk does make use of early offer information, it doesn’t have to do so).
