Asterisk 20.0.1 Realtime Codec negotiation failed

Hi everyone,

I hope someone can help, I’ve been trying to get a new server up and running on RHEL 8.

I’ve installed Asterisk 20.0.1 and set it up to load PJSIP & extension config from Mariadb.

Outgoing calls from my Yealink T48S works as expected but inbound calls fail and I cannot figure out why, I’m bummed as I’ve check codec settings on both Ast box and phone.

I’ve added the log extract of failure below, I’ve allowed g722,alaw,ulaw and g729 codecs on both endpoint and phone. I’ve even tried to play around with different codecs to no success.

I’ve got this setup running parallel on Centos 7 and Asterisk 16 no issues, same config etc.

I’ve replaced AST server’s public address with XXXX.

<— Transmitting SIP request (1817 bytes) to UDP:41.193.130.94:1025 —>
INVITE sip:2688533014100@41.193.130.94:1025 SIP/2.0
Via: SIP/2.0/UDP XXXX:5060;rport;branch=z9hG4bKPj41798e24-41f6-4e55-ad0b-9c04976f5888
From: sip:2688533014100@XXXX;tag=b79c8089-c87c-4fb4-82c3-a780d69672df
To: sip:2688533014100@41.193.130.94
Contact: sip:2688533014100@XXXX:5060
Call-ID: feb883f9-adb1-47da-a16b-31d9d0a0993d
CSeq: 17014 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 20.0.1
Content-Type: application/sdp
Content-Length: 1123

v=0
o=- 1702441716 1702441716 IN IP4 XXXX
s=Asterisk
c=IN IP4 XXXX
t=0 0
a=msid-semantic:WMS *
a=group:BUNDLE audio-0
m=audio 10064 UDP/TLS/RTP/SAVPF 8 18 9 0 101
a=connection:new
a=setup:actpass
a=fingerprint:SHA-256 B0:AF:2A:D1:EE:C8:D5:CE:CF:84:F7:1F:04:1B:D4:5B:AC:B0:A6:CC:F5:C2:35:1B:DF:9F:87:06:B5:CC:FC:EA
a=ice-ufrag:68f2c9244c0d19ed3866ebce0312c331
a=ice-pwd:3b36b02431c3c4cf6ebf76617f13a9bd
a=candidate:H29489235 1 UDP 2130706431 XXXX 10064 typ host
a=candidate:Ha0a0a06 1 UDP 2130706431 10.10.10.6 10064 typ host
a=candidate:Ha6e8f60f 1 UDP 2130706431 fe80::20c:29ff:fea6:4334 10064 typ host
a=candidate:Ha6e8f619 1 UDP 2130706431 fe80::20c:29ff:fea6:433e 10064 typ host
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
a=rtcp-mux
a=ssrc:2068640042 cname:cd42e494-9a7f-474c-80f8-c23324df94b6
a=msid:f6f7e79e-ae97-4996-9cba-417e22635c94 101ffdcb-63a1-4bb9-8238-062dfc4b2827
a=rtcp-fb:* transport-cc
a=mid:audio-0

<— Received SIP response (397 bytes) from UDP:41.193.130.94:1025 —>
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/UDP XXXX:5060;rport=5060;branch=z9hG4bKPj41798e24-41f6-4e55-ad0b-9c04976f5888
From: sip:2688533014100@XXXX;tag=b79c8089-c87c-4fb4-82c3-a780d69672df
To: sip:2688533014100@41.193.130.94;tag=2461526418
Call-ID: feb883f9-adb1-47da-a16b-31d9d0a0993d
CSeq: 17014 INVITE
User-Agent: Yealink SIP-T48S 66.84.0.10
Content-Length: 0

This is a WebRTC SDP. You can’t enable WebRTC for a non-WebRTC device in Asterisk, the resulting SDP is incompatible and will fail.

1 Like

I’ve tried to force endpoint to use UDP transport then I get response below: (PS on my ast16 box I make use of mixed transports per endpoint and it works?)

<— Transmitting SIP request (1657 bytes) to UDP:41.193.130.94:1025 —>
INVITE sip:2688533014100@41.193.130.94:1025 SIP/2.0
Via: SIP/2.0/UDP XXXX:5060;rport;branch=z9hG4bKPj7c63b2ba-d5ed-4616-af93-7704291661ae
From: sip:2688533014100@XXXX;tag=63a23d14-54b5-4a5e-bf0c-d4e33605ddfa
To: sip:2688533014100@41.193.130.94
Contact: sip:2688533014100@:5060
Call-ID: cbfbd36c-c420-4e60-8a29-052b59213793
CSeq: 31928 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 20.0.1
Content-Type: application/sdp
Content-Length: 963

v=0
o=- 1211199381 1211199381 IN IP4 XXXX
s=Asterisk
c=IN IP4 XXXX
t=0 0
a=msid-semantic:WMS *
a=group:BUNDLE audio-0
m=audio 12032 UDP/TLS/RTP/SAVPF 8 18 9 0 101
a=connection:new
a=setup:actpass
a=fingerprint:SHA-256 E9:F4:14:5A:0E:E8:BF:B3:B4:74:D3:87:12:60:94:86:95:55:6D:7E:60:2A:83:E7:E0:02:37:47:1F:A9:20:CE
a=ice-ufrag:1b11c62e06e4656f4a9140363fd9421d
a=ice-pwd:4331069604f7556d77a5f67350c39666
a=candidate:H29489235 1 UDP 2130706431 XXXX 12032 typ host
a=candidate:Ha0a0a06 1 UDP 2130706431 10.10.10.6 12032 typ host
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
a=rtcp-mux
a=ssrc:1514990662 cname:40c4a165-34ea-4c3d-96ab-88aa3d66c08f
a=msid:49fbece2-bf45-4f7a-acab-dfb46590f89d fce5009c-9df6-4d1d-bfb4-a335c3084708
a=rtcp-fb:* transport-cc
a=mid:audio-0

UDP transport has nothing to do with SDP. There is the “webrtc” option on endpoints which enables WebRTC functionality, otherwise you’d need to show your endpoint configuration.

May I kindly ask where in the SIP response did you identify that it tried webRTC? would help if I could identify it myself?

I didn’t in the SIP response. It’s in the SDP from Asterisk:

a=msid-semantic:WMS *
a=group:BUNDLE audio-0
a=rtcp-mux
a=ssrc:1514990662 cname:40c4a165-34ea-4c3d-96ab-88aa3d66c08f
a=msid:49fbece2-bf45-4f7a-acab-dfb46590f89d fce5009c-9df6-4d1d-bfb4-a335c3084708
a=rtcp-fb:* transport-cc
a=mid:audio-0

These are only used with WebRTC.

1 Like

This is an extract from DB for said endpoint:

id,“transport”,“aors”,“auth”,“context”,“disallow”,“allow”,“direct_media”,“connected_line_method”,“direct_media_method”,“direct_media_glare_mitigation”,“disable_direct_media_on_nat”,“dtmf_mode”,“external_media_address”,“force_rport”,“ice_support”,“identify_by”,“mailboxes”,“moh_suggest”,“outbound_auth”,“outbound_proxy”,“rewrite_contact”,“rtp_ipv6”,“rtp_symmetric”,“send_diversion”,“send_pai”,“send_rpid”,“timers_min_se”,“timers”,“timers_sess_expires”,“callerid”,“callerid_privacy”,“callerid_tag”,“100rel”,“aggregate_mwi”,“trust_id_inbound”,“trust_id_outbound”,“use_ptime”,“use_avpf”,“media_encryption”,“inband_progress”,“call_group”,“pickup_group”,“named_call_group”,“named_pickup_group”,“device_state_busy_at”,“fax_detect”,“t38_udptl”,“t38_udptl_ec”,“t38_udptl_maxdatagram”,“t38_udptl_nat”,“t38_udptl_ipv6”,“tone_zone”,“language”,“one_touch_recording”,“record_on_feature”,“record_off_feature”,“rtp_engine”,“allow_transfer”,“allow_subscribe”,“sdp_owner”,“sdp_session”,“tos_audio”,“tos_video”,“sub_min_expiry”,“from_domain”,“from_user”,“mwi_from_user”,“dtls_verify”,“dtls_rekey”,“dtls_cert_file”,“dtls_private_key”,“dtls_cipher”,“dtls_ca_file”,“dtls_ca_path”,“dtls_setup”,“srtp_tag_32”,“media_address”,“redirect_method”,“set_var”,“cos_audio”,“cos_video”,“message_context”,“force_avp”,“media_use_received_transport”,“accountcode”,“user_eq_phone”,“moh_passthrough”,“media_encryption_optimistic”,“rpid_immediate”,“g726_non_standard”,“rtp_keepalive”,“rtp_timeout”,“rtp_timeout_hold”,“bind_rtp_to_media_address”,“voicemail_extension”,“mwi_subscribe_replaces_unsolicited”,“deny”,“permit”,“acl”,“contact_deny”,“contact_permit”,“contact_acl”,“subscribe_context”,“fax_detect_timeout”,“contact_user”,“preferred_codec_only”,“asymmetric_rtp_codec”,“rtcp_mux”,“allow_overlap”,“refer_blind_progress”,“notify_early_inuse_ringing”,“max_audio_streams”,“max_video_streams”,“webrtc”,“dtls_fingerprint”,“incoming_mwi_mailbox”,“bundle”,“dtls_auto_generate_cert”,“follow_early_media_fork”,“accept_multiple_sdp_answers”,“suppress_q850_reason_headers”,“trust_connected_line”,“send_connected_line”,“ignore_183_without_sdp”
2688533014100,“transport-udp”,“2688533014100”,“2688533014100”,“2688533014”,“all”,“g722,alaw,ulaw,g729”,“no”,NULL,NULL,NULL,NULL,NULL,NULL,“yes”,NULL,NULL,NULL,NULL,NULL,NULL,“yes”,NULL,“yes”,NULL,NULL,NULL,NULL,NULL,NULL,“”“Allan”" <100>",NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,“1”,“1”,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,“2688533014100”,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,“yes”,NULL,NULL,NULL,“yes”,NULL,NULL,NULL,NULL,NULL,NULL

I… am not going to line up everything to figure out what is what.

You can view the settings of an endpoint in Asterisk using “pjsip show endpoint ”. If WebRTC is set to yes, then it’s enabled, would cause this, and would fail. It should be no.

Thank you will try, but why would it work on my Asterisk 16 though?

I don’t know, it’s never been supported and would always fail in any version. Which would mean that something is different - be it configuration, or something else.

Thank you kindly your solution worked! disabled webrtc on endpoint and can now receive inbound calls.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.