I have found the following in asterisk doc.: “The 4 control points and their parameters are all configured on PJSIP endpoints. The control point parameters are named…
codec_prefs_incoming_offer
codec_prefs_outgoing_offer
codec_prefs_incoming_answer
codec_prefs_outgoing_answer …”
It seems that above 4 control points do not work in asterisk 18.1.0 and 19-rc1. I try these and result is the same - I compare SDPs under wireshark. Are there implemented in asterisk?
I answered this on the ticket you filed, but it is still being worked on.
Yep, but when will be ready, in which version?
I don’t have a specific version that it will be ready in. It’s still a project that is in progress, but other things have come up which preempted it.
ok, tx, but my problem is to get direct media when two sip phones has the same codecs in the same order but, asterisk has reverse order and in such case I got the following results instead of direct media:
*CLI> pjsip show channelstats
...........Receive......... .........Transmit..........
BridgeId ChannelId ........ UpTime.. Codec. Count Lost Pct Jitter Count Lost Pct Jitter RTT....
===========================================================================================================
425cd447 15-00000003 00:00:07 g722 215 0 0 0.000 212 0 0 0.002 0.000
425cd447 23-00000002 00:00:07 alaw 212 0 0 0.000 215 0 0 0.003 0.000
Objects found: 2
> 0xb667bef0 -- Strict RTP learning complete - Locking on source address 192.168.0.103:8000
> 0xb6683718 -- Strict RTP learning complete - Locking on source address 192.168.0.100:8000
Ok? Currently direct media will only occur if both preferred codecs are the same.
Codecs are the same but, order is different.
The combined codecs are different, but the order is different, and the preference is different - therefore it won’t do direct media.
devive 1 has the following codecs: G.722; ulaw; alaw.
device 2 has the following codecs: G.722; ulaw; alaw.
asterisk endpoints has the following codes:
fusion_codecs](!)
disallow=all
allow=alaw
allow=ulaw
allow=g722
allow=g729
allow=g726
What was actually negotiated in the SDP across both sides?
There is no codec negotiations.
*CLI> pjsip show endpoint 15
Endpoint: <Endpoint/CID.....................................> <State.....> <Channels.>
I/OAuth: <AuthId/UserName...........................................................>
Aor: <Aor............................................> <MaxContact>
Contact: <Aor/ContactUri..........................> <Hash....> <Status> <RTT(ms)..>
Transport: <TransportId........> <Type> <cos> <tos> <BindAddress..................>
Identify: <Identify/Endpoint.........................................................>
Match: <criteria.........................>
Channel: <ChannelId......................................> <State.....> <Time.....>
Exten: <DialedExten...........> CLCID: <ConnectedLineCID.......>
==========================================================================================
Endpoint: 15 Not in use 0 of inf
InAuth: auth15/15
Aor: 15 1
Contact: 15/sip:15@192.168.0.100:5060 d28283c181 NonQual nan
ParameterName : ParameterValue
===================================================================================================
100rel : yes
accept_multiple_sdp_answers : false
accountcode :
acl :
aggregate_mwi : true
allow : (alaw|ulaw|g722|g729|g726)
allow_overlap : true
allow_subscribe : true
allow_transfer : true
aors : 15
asymmetric_rtp_codec : false
auth : auth15
bind_rtp_to_media_address : false
bundle : false
call_group :
callerid : <unknown>
callerid_privacy : allowed_not_screened
callerid_tag :
codec_prefs_incoming_answer : prefer:pending, operation:intersect, keep:all, transcode:allow
codec_prefs_incoming_offer : prefer:pending, operation:intersect, keep:all, transcode:allow
codec_prefs_outgoing_answer : prefer:pending, operation:intersect, keep:all, transcode:allow
codec_prefs_outgoing_offer : prefer:pending, operation:union, keep:all, transcode:allow
connected_line_method : invite
contact_acl :
context : fusion
cos_audio : 0
cos_video : 0
device_state_busy_at : 0
direct_media : true
direct_media_glare_mitigation : none
direct_media_method : invite
disable_direct_media_on_nat : false
dtls_auto_generate_cert : No
dtls_ca_file :
dtls_ca_path :
dtls_cert_file :
dtls_cipher :
dtls_fingerprint : SHA-256
dtls_private_key :
dtls_rekey : 0
dtls_setup : active
dtls_verify : No
dtmf_mode : rfc4733
fax_detect : false
fax_detect_timeout : 0
follow_early_media_fork : true
force_avp : false
force_rport : true
from_domain :
from_user :
g726_non_standard : false
ice_support : false
identify_by : username,ip
ignore_183_without_sdp : false
inband_progress : false
incoming_call_offer_pref : local
incoming_mwi_mailbox :
language :
mailboxes :
max_audio_streams : 1
max_video_streams : 1
media_address :
media_encryption : no
media_encryption_optimistic : false
media_use_received_transport : false
message_context :
moh_passthrough : false
moh_suggest : default
mwi_from_user :
mwi_subscribe_replaces_unsolicited : no
named_call_group :
named_pickup_group :
notify_early_inuse_ringing : false
one_touch_recording : false
outbound_auth :
outbound_proxy :
outgoing_call_offer_pref : remote_merge
pickup_group :
preferred_codec_only : false
record_off_feature : automixmon
record_on_feature : automixmon
refer_blind_progress : true
rewrite_contact : false
rpid_immediate : false
rtcp_mux : false
rtp_engine : asterisk
rtp_ipv6 : false
rtp_keepalive : 0
rtp_symmetric : false
rtp_timeout : 0
rtp_timeout_hold : 0
sdp_owner : -
sdp_session : Asterisk
send_connected_line : yes
send_diversion : true
send_history_info : false
send_pai : true
send_rpid : true
set_var :
srtp_tag_32 : false
stir_shaken : false
sub_min_expiry : 0
subscribe_context :
suppress_q850_reason_headers : false
t38_udptl : false
t38_udptl_ec : none
t38_udptl_ipv6 : false
t38_udptl_maxdatagram : 0
t38_udptl_nat : false
timers : yes
timers_min_se : 90
timers_sess_expires : 1800
tone_zone :
tos_audio : 0
tos_video : 0
transport :
trust_connected_line : yes
trust_id_inbound : true
trust_id_outbound : true
use_avpf : false
use_ptime : false
user_eq_phone : false
voicemail_extension :
webrtc : no
fusion*CLI>
endpoint 23 is the same
asterisk ip 192.168.0.101
device no 23 ip 192.168.0.103
device no 15 ip 192.168.0.100
The provided screenshots show that Asterisk negotiated alaw (the preferred codec), ulaw, and g722 with 192.168.0.103. For the device at 192.168.0.100 only g722 (the preferred codec by it) was negotiated. Therefore one channel was using alaw and the other was using g722.
Yep, but for both devices (192.168.0.100 & 192.168.0.103) the preferred codec was g.722 as it was first on both devices codecs lists. The asterisk endpoints was preferred codec alaw.
And Asterisk will prefer its order by default, unless you play with some of the options - some of them will work, I don’t recall specifically for this. So as it is it is working as it should.
Why do not both sip phone devices use one codec: g.722 or alaw as each of these support these codecs, but now is used two codecs and asterisk is doing unnecessary transcoding?
(I have attached wireshark logs (pcapng) to JIRA, as here I can’t.)
What is a suggested option that should be used to achieve direct media in such case?
We offered multiple codecs to the phone on the outgoing leg, and it chose only g722. On the incoming leg you configured a preference of alaw, so that was used. Be more explicit in your codec ordering or try out the various ACN options that do exist (some do work and may help in this case). Functionality to forward back the answer codec on the outgoing leg to the incoming leg, however, is not present. Otherwise, things are working as expected.
I’m not going to look at the packet captures if they’re the same as the images and with same configuration. Based on those, what is happening is expected.
