Does Asterisk Translate Ulaw to G722

Hello,

Does Asterisk Translate Ulaw to g722 ? When I test to call endpoint that supports g722 and other doesn’t. I can hear voice on the devices that support ulaw but I can’t hear on the devicees that support g722. By the way My system is Asterisk 13.7

4073:supports g722
6025 supports ulaw

*CLI> pjsip show endpoint 4073
ParameterName : ParameterValue

100rel : yes
accountcode :
aggregate_mwi : true
allow : (g722|ulaw|alaw|g729|h264)
allow_subscribe : true
allow_transfer : true
aors : 4073
auth : 4073
call_group : 10
callerid : “Yealink T28” <4073>

CLI> pjsip show endpoint 6025

ParameterName : ParameterValue

100rel : yes
accountcode :
aggregate_mwi : true
allow : (g722|ulaw|alaw|g729)
allow_subscribe : true
allow_transfer : true
aors : 6025
auth : 6025
call_group : 10
callerid : “XPEECH” <6025>

*CLI> core show translation recalc

       ulaw  alaw  g726 g726aal2 adpcm  slin  slin  slin  slin  slin  slin  slin  slin  slin lpc10  g729  ilbc  g722 testlaw
 ulaw     -  9150 15000    15000 15000  9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 15000 15000 17250   15000
 alaw  9150     - 15000    15000 15000  9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 15000 15000 17250   15000
 g726 15000 15000     -    15000 15000  9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 15000 15000 17250   15000

g726aal2 15000 15000 15000 - 15000 9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 15000 15000 17250 15000
adpcm 15000 15000 15000 15000 - 9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 15000 15000 17250 15000
slin 6000 6000 6000 6000 6000 - 8000 8000 8000 8000 8000 8000 8000 8000 6000 6000 6000 8250 6000
slin 14500 14500 14500 14500 14500 8500 - 8000 8000 8000 8000 8000 8000 8000 14500 14500 14500 14000 14500
slin 14500 14500 14500 14500 14500 8500 8500 - 8000 8000 8000 8000 8000 8000 14500 14500 14500 6000 14500
slin 14500 14500 14500 14500 14500 8500 8500 8500 - 8000 8000 8000 8000 8000 14500 14500 14500 14500 14500
slin 14500 14500 14500 14500 14500 8500 8500 8500 8500 - 8000 8000 8000 8000 14500 14500 14500 14500 14500
slin 14500 14500 14500 14500 14500 8500 8500 8500 8500 8500 - 8000 8000 8000 14500 14500 14500 14500 14500
slin 14500 14500 14500 14500 14500 8500 8500 8500 8500 8500 8500 - 8000 8000 14500 14500 14500 14500 14500
slin 14500 14500 14500 14500 14500 8500 8500 8500 8500 8500 8500 8500 - 8000 14500 14500 14500 14500 14500
slin 14500 14500 14500 14500 14500 8500 8500 8500 8500 8500 8500 8500 8500 - 14500 14500 14500 14500 14500
lpc10 15000 15000 15000 15000 15000 9000 17000 17000 17000 17000 17000 17000 17000 17000 - 15000 15000 17250 15000
g729 15000 15000 15000 15000 15000 9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 - 15000 17250 15000
ilbc 15000 15000 15000 15000 15000 9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 15000 - 17250 15000
g722 15600 15600 15600 15600 15600 9600 17500 9000 17000 17000 17000 17000 17000 17000 15600 15600 15600 - 15600
testlaw 15000 15000 15000 15000 15000 9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 15000 15000 17250 -

Yes, it does. You’ll need to provide more information for this such as the SIP signaling (pjsip set logger on) as well as a description of the call flow.

-- Executing [6025@custom-uluslararasi:1] Macro("PJSIP/4073-00004acb", "sifre-sor,4073") in new stack
-- Executing [s@macro-sifre-sor:1] Set("PJSIP/4073-00004acb", "durum=0") in new stack
-- Executing [s@macro-sifre-sor:2] GotoIf("PJSIP/4073-00004acb", "1?sifre_pasif") in new stack
-- Goto (macro-sifre-sor,s,17)
-- Executing [s@macro-sifre-sor:17] NoOp("PJSIP/4073-00004acb", ""Arama sifresi yok."") in new stack
-- Executing [s@macro-sifre-sor:18] NoOp("PJSIP/4073-00004acb", ""Arama sifresi dogru."") in new stack
-- Executing [6025@custom-uluslararasi:2] GotoIf("PJSIP/4073-00004acb", "0?nochgcid") in new stack
-- Executing [6025@custom-uluslararasi:3] Set("PJSIP/4073-00004acb", "CALLERID(num)=4073") in new stack
-- Executing [6025@custom-uluslararasi:4] Goto("PJSIP/4073-00004acb", "from-internal,6025,1") in new stack
-- Goto (from-internal,6025,1)
-- Executing [6025@from-internal:1] Macro("PJSIP/4073-00004acb", "isy-vm-dial,6025,20") in new stack
-- Executing [s@macro-isy-vm-dial:1] Macro("PJSIP/4073-00004acb", "yonlendir,6025") in new stack
-- Executing [s@macro-yonlendir:1] Set("PJSIP/4073-00004acb", "yon_durum=") in new stack
-- Executing [s@macro-yonlendir:2] GotoIf("PJSIP/4073-00004acb", "1?yon_pasif") in new stack
-- Goto (macro-yonlendir,s,10)
-- Executing [s@macro-yonlendir:10] NoOp("PJSIP/4073-00004acb", ""Arama yonledirmesi yok. Cagrı baslatiliyor"") in new stack
-- Executing [s@macro-isy-vm-dial:2] Macro("PJSIP/4073-00004acb", "call-control,6025") in new stack
-- Executing [s@macro-call-control:1] ChanIsAvail("PJSIP/4073-00004acb", "PJSIP/6025,s") in new stack
-- Executing [s@macro-call-control:2] NoOp("PJSIP/4073-00004acb", "Channel 6025 is 1") in new stack
-- Executing [s@macro-call-control:3] GotoIf("PJSIP/4073-00004acb", "0?mesgul:musait") in new stack
-- Goto (macro-call-control,s,7)
-- Executing [s@macro-call-control:7] NoOp("PJSIP/4073-00004acb", "Numara Musait Cagri Baslatiliyor.") in new stack
-- Executing [s@macro-isy-vm-dial:3] GotoIf("PJSIP/4073-00004acb", "1?:callgroup") in new stack
-- Executing [s@macro-isy-vm-dial:4] Dial("PJSIP/4073-00004acb", "PJSIP/6025,20,tr") in new stack
-- Called PJSIP/6025

<— Transmitting SIP response (484 bytes) to UDP:10.15.163.153:5062 —>
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.15.163.153:5062;rport=5062;received=10.15.163.153;branch=z9hG4bK1502501305
Call-ID: 2045393290@10.15.163.153
From: “4073” sip:4073@10.20.6.234;tag=1979882638
To: sip:6025@10.20.6.234;tag=ae518769-e745-44db-bcda-c34ecff525a7
CSeq: 2 INVITE
Server: Asterisk PBX 13.7.2
Contact: sip:10.20.6.234:5060
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Content-Length: 0

<— Transmitting SIP request (1055 bytes) to UDP:10.15.160.31:5060 —>
INVITE sip:6025@10.15.160.31:5060;line=31663 SIP/2.0
Via: SIP/2.0/UDP 10.20.6.234:5060;rport;branch=z9hG4bKPj95c45ccb-bba8-4f95-9528-5e05498fc636
From: “BEYTULLAH ARSLAN” sip:4073@10.20.6.234;tag=d21ffeee-31cb-4e39-bce6-e6d972171aa1
To: sip:6025@10.15.160.31;line=31663
Contact: sip:asterisk@10.20.6.234:5060
Call-ID: 07850425-0edc-4cc6-ab45-903642ce15ea
CSeq: 14372 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 13.7.2
Content-Type: application/sdp
Content-Length: 367

v=0
o=- 2007907451 2007907451 IN IP4 1.1.1.2
s=Asterisk
c=IN IP4 10.20.6.234
t=0 0
m=audio 12110 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
m=video 17788 RTP/AVP 99
a=rtpmap:99 H264/90000
a=sendrecv

pjsip set logger on output bellow. Could you see any problem?

<— Received SIP response (337 bytes) from UDP:10.15.160.31:5060 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.20.6.234:5060;rport=5060;branch=z9hG4bKPj95c45ccb-bba8-4f95-9528-5e05498fc636
From: “BEYTULLAH ARSLAN” sip:4073@10.20.6.234;tag=d21ffeee-31cb-4e39-bce6-e6d972171aa1
To: sip:6025@10.15.160.31;line=31663
Call-ID: 07850425-0edc-4cc6-ab45-903642ce15ea
CSeq: 14372 INVITE
Content-Length: 0

The log output is incomplete but nothing stands out. An “rtp set debug on” would also be useful.

10.15.160.31 is device that sopports ulaw , 10.15.163.153 is device that sopports g722
Do you have an idea?

Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051020, ts 226606400, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051021, ts 226606560, len 000160)
Sent RTP packet to      10.15.160.31:50038 (type 00, seq 034080, ts 000048, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051022, ts 226606720, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051023, ts 226606880, len 000160)
Sent RTP packet to      10.15.160.31:50038 (type 00, seq 034081, ts 000208, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051024, ts 226607040, len 000160)
Sent RTP packet to      10.15.160.31:50038 (type 00, seq 034082, ts 000368, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051025, ts 226607200, len 000160)
Sent RTP packet to      10.15.160.31:50038 (type 00, seq 034083, ts 000528, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051026, ts 226607360, len 000160)
Sent RTP packet to      10.15.160.31:50038 (type 00, seq 034084, ts 000688, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051027, ts 226607520, len 000160)
Sent RTP packet to      10.15.160.31:50038 (type 00, seq 034085, ts 000848, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051028, ts 226607680, len 000160)
Sent RTP packet to      10.15.160.31:50038 (type 00, seq 034086, ts 001008, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051029, ts 226607840, len 000160)
Sent RTP packet to      10.15.160.31:50038 (type 00, seq 034087, ts 001168, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051030, ts 226608000, len 000160)
Sent RTP packet to      10.15.160.31:50038 (type 00, seq 034088, ts 001328, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051031, ts 226608160, len 000160)
Sent RTP packet to      10.15.160.31:50038 (type 00, seq 034089, ts 001488, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051032, ts 226608320, len 000160)
Sent RTP packet to      10.15.160.31:50038 (type 00, seq 034090, ts 001648, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051033, ts 226608480, len 000160)
Sent RTP packet to      10.15.160.31:50038 (type 00, seq 034091, ts 001808, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051034, ts 226608640, len 000160)
Sent RTP packet to      10.15.160.31:50038 (type 00, seq 034092, ts 001968, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051035, ts 226608800, len 000160)
Sent RTP packet to      10.15.160.31:50038 (type 00, seq 034093, ts 002128, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051036, ts 226608960, len 000160)
Sent RTP packet to      10.15.160.31:50038 (type 00, seq 034094, ts 002288, len 000160)
Sent RTP packet to      10.15.160.31:50038 (type 00, seq 034095, ts 002448, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051037, ts 226609120, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051038, ts 226609280, len 000160)
Sent RTP packet to      10.15.160.31:50038 (type 00, seq 034096, ts 002608, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051039, ts 226609440, len 000160)
Sent RTP packet to      10.15.160.31:50038 (type 00, seq 034097, ts 002768, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051040, ts 226609600, len 000160)
Sent RTP packet to      10.15.160.31:50038 (type 00, seq 034098, ts 002928, len 000160)
Got  RTP packet from    10.15.160.31:50038 (type 00, seq 051041, ts 226609760, len 000160)

Got  RTP packet from    10.15.163.153:11784 (type 09, seq 032649, ts 131440, len 000160)
Sent RTP packet to      10.15.163.153:11784 (type 00, seq 060989, ts 226711360, len 000160)
Got  RTP packet from    10.15.163.153:11784 (type 09, seq 032650, ts 131600, len 000160)
Sent RTP packet to      10.15.163.153:11784 (type 00, seq 060990, ts 226711520, len 000160)
Got  RTP packet from    10.15.163.153:11784 (type 09, seq 032651, ts 131760, len 000160)
Sent RTP packet to      10.15.163.153:11784 (type 00, seq 060991, ts 226711680, len 000160)
Got  RTP packet from    10.15.163.153:11784 (type 09, seq 032652, ts 131920, len 000160)
Sent RTP packet to      10.15.163.153:11784 (type 00, seq 060992, ts 226711840, len 000160)
Got  RTP packet from    10.15.163.153:11784 (type 09, seq 032653, ts 132080, len 000160)
Sent RTP packet to      10.15.163.153:11784 (type 00, seq 060993, ts 226712000, len 000160)
Got  RTP packet from    10.15.163.153:11784 (type 09, seq 032654, ts 132240, len 000160)
Sent RTP packet to      10.15.163.153:11784 (type 00, seq 060994, ts 226712160, len 000160)
Got  RTP packet from    10.15.163.153:11784 (type 09, seq 032655, ts 132400, len 000160)
Sent RTP packet to      10.15.163.153:11784 (type 00, seq 060995, ts 226712320, len 000160)
Got  RTP packet from    10.15.163.153:11784 (type 09, seq 032656, ts 132560, len 000160)
Sent RTP packet to      10.15.163.153:11784 (type 00, seq 060996, ts 226712480, len 000160)
Got  RTP packet from    10.15.163.153:11784 (type 09, seq 032657, ts 132720, len 000160)
Sent RTP packet to      10.15.163.153:11784 (type 00, seq 060997, ts 226712640, len 000160)
Got  RTP packet from    10.15.163.153:11784 (type 09, seq 032658, ts 132880, len 000160)
Sent RTP packet to      10.15.163.153:11784 (type 00, seq 060998, ts 226712800, len 000160)
Got  RTP packet from    10.15.163.153:11784 (type 09, seq 032659, ts 133040, len 000160)
Sent RTP packet to      10.15.163.153:11784 (type 00, seq 060999, ts 226712960, len 000160)
Got  RTP packet from    10.15.163.153:11784 (type 09, seq 032660, ts 133200, len 000160)
Sent RTP packet to      10.15.163.153:11784 (type 00, seq 061000, ts 226713120, len 000160)
Got  RTP packet from    10.15.163.153:11784 (type 09, seq 032661, ts 133360, len 000160)
Sent RTP packet to      10.15.163.153:11784 (type 00, seq 061001, ts 226713280, len 000160)
Got  RTP packet from    10.15.163.153:11784 (type 09, seq 032662, ts 133520, len 000160)
Sent RTP packet to      10.15.163.153:11784 (type 00, seq 061002, ts 226713440, len 000160)
Got  RTP packet from    10.15.163.153:11784 (type 09, seq 032663, ts 133680, len 000160)
Sent RTP packet to      10.15.163.153:11784 (type 00, seq 061003, ts 226713600, len 000160)
Got  RTP packet from    10.15.163.153:11784 (type 09, seq 032664, ts 133840, len 000160)

It appears as though Asterisk is sending ulaw to the G722 device, which while valid according to the spec many devices don’t like things not to match. I’d suggest providing the full SIP traces as well so we can see what the SDP negotiation yielded.

There seem to be spurious ()'s in our allow line.

I took full SIP trace. Could you check and suggest me how fix it.

The packet capture shows RTP and SIP OPTIONS. It does not show the call setup, which is needed.

Hello,

How can I take call setup log.

“sip set debug on” before a call is initiated and then “sip set debug off” after the call is terminated. This will show the complete trace.

I use PJSIP therefore I can take pjsip set logger on and off. is this log useful.

Yes, provided you do it before you do a call and only turn it off after the call is terminated.

I toke debug log.
4073:10.15.163.153 is support g722,ulaw,alw codec
beytullaharslan:136.10.195.20 is support just ulaw codec
I try to call 4073 to beytullaharslan, I hear sound on beytullah arslan but I can’t hear 4073
log file below:

If you remove all codecs except g722 from the configuration of 4073 does it then work?

Yes. It worked in that case and I think I realized the bug:
The codec is negotiated with the call initiator when the initator places a call and a codec is choosed. For instance g722 was choosed between the caller and Asterisk.
Between called party and Asterisk a suitable another codec for instance ulaw was choosed.
When the sound starts from the caller, for the translation, Asterisk looks for the list of available codecs of the called party’s allowed codec list and if it founds the caller’s codec (g722) it uses it. INSTEAD of using the negotiated codec (ulaw) af called party. And this a problem that can be simulated easily with different codecs also.
Do you agree with me?
And I think you can fix this problem easily.

Please file an issue on the issue tracker[1] attaching the complete output you provided, the configuration, and the description.

[1] https://issues.asterisk.org/jira

SIP doesn’t negotiate a codec. Each side says what it is prepared to accept. Although it is normal to prefer a codec that is listed for both sides of a dialog, it is perfectly legal to use any codec that was listed in the SDP from the peer, when sending to the peer, even if it isn’t the first choice and even if the sender hasn’t said that it is prepared to accept it in the other direction.