Same registration in the webrtc and sip udp ; extension

hello. I have an Asterisk working perfectly with webrct and sip udp. I’m using pjsip.
I need the user to register the webrtc and sip udp extension with the same credentials.
Follow my settings. This way I get the error that aors was not found.

[8000]
type=auth
auth_type=userpass
password=teste123 ; Replace ‘secret’ with the actual password
username=michel ; Replace ‘6001’ with the actual username

[8000]
type=aor
max_contacts=5
remove_existing=yes

[endpoint_dtls]
type=endpoint
context=default
disallow=all
allow=ulaw
aors=8000
auth=8000
dtls_auto_generate_cert=yes
media_encryption=dtls
dtls_verify=no
dtls_setup=actpass
dtls_rekey=0
webrtc=yes ; Assuming WebRTC clients might use this endpoint

[endpoint_no_dtls]
type=endpoint
context=default
disallow=all
allow=ulaw
aors=8000
auth=8000
media_encryption=no

[identify_user_agent_dtls]
type=identify
endpoint=endpoint_dtls
match_header=User-Agent: /.JsSIP./

[identify_user_agent_no_dtls]
type=identify
endpoint=endpoint_no_dtls
match_header=User-Agent: /.*/

You should show the actual SIP traffic for a REGISTER attempt and console output.

what I gave you was an example I will give you my settings.
I am using realtime database.

Endpoint: 3590dtls Not in use 0 of inf
InAuth: 3590/3590
Aor: 3590 3
Transport: transport-wss ws 0 0 0.0.0.0:5060

ParameterName : ParameterValue

100rel : yes
accept_multiple_sdp_answers : false
accountcode :
acl :
aggregate_mwi : true
allow : (alaw|ulaw|h263|h263p|h264|vp8|g729|opus)
allow_overlap : true
allow_subscribe : true
allow_transfer : true
allow_unauthenticated_options : false
aors : 3590
asymmetric_rtp_codec : false
auth : 3590
bind_rtp_to_media_address : false
bundle : true
call_group : 6
callerid :
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 : padrao
cos_audio : 0
cos_video : 0
device_state_busy_at : 0
direct_media : false
direct_media_glare_mitigation : outgoing
direct_media_method : invite
disable_direct_media_on_nat : false
dtls_auto_generate_cert : Yes
dtls_ca_file :
dtls_ca_path :
dtls_cert_file :
dtls_cipher :
dtls_fingerprint : SHA-256
dtls_private_key :
dtls_rekey : 0
dtls_setup : actpass
dtls_verify : Yes
dtmf_mode : rfc4733
fax_detect : false
fax_detect_timeout : 0
follow_early_media_fork : true
force_avp : true
force_rport : true
from_domain :
from_user :
g726_non_standard : false
geoloc_incoming_call_profile :
geoloc_outgoing_call_profile :
ice_support : true
identify_by : username,ip
ignore_183_without_sdp : false
inband_progress : true
incoming_call_offer_pref : local
incoming_mwi_mailbox :
language :
mailboxes :
max_audio_streams : 1
max_video_streams : 1
media_address : mysererip
media_encryption : dtls
media_encryption_optimistic : false
media_use_received_transport : true
message_context :
moh_passthrough : false
moh_suggest : default
mwi_from_user :
mwi_subscribe_replaces_unsolicited : yes
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
overlap_context :
pickup_group : 6
preferred_codec_only : false
record_off_feature : automixmon
record_on_feature : automixmon
refer_blind_progress : true
rewrite_contact : true
rpid_immediate : false
rtcp_mux : true
rtp_engine : asterisk
rtp_ipv6 : false
rtp_keepalive : 0
rtp_symmetric : true
rtp_timeout : 120
rtp_timeout_hold : 0
sdp_owner : -
sdp_session : Asterisk
security_mechanisms :
security_negotiation : no
send_aoc : false
send_connected_line : yes
send_diversion : true
send_history_info : false
send_pai : false
send_rpid : false
set_var :
srtp_tag_32 : false
stir_shaken : off
stir_shaken_profile :
sub_min_expiry : 0
subscribe_context :
suppress_q850_reason_headers : false
t38_bind_udptl_to_media_address : 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 : transport-wss
trust_connected_line : yes
trust_id_inbound : false
trust_id_outbound : false
use_avpf : true
use_ptime : true
user_eq_phone : false
voicemail_extension :
webrtc : yes

Endpoint: 3590dtlsno Not in use 0 of inf
InAuth: 3590/3590
Aor: 3590 3
Transport: transport-udp udp 0 0 0.0.0.0:21693

ParameterName : ParameterValue

100rel : yes
accept_multiple_sdp_answers : false
accountcode :
acl :
aggregate_mwi : true
allow : (alaw|ulaw|h263|h263p|h264|vp8|g729|opus)
allow_overlap : true
allow_subscribe : true
allow_transfer : true
allow_unauthenticated_options : false
aors : 3590
asymmetric_rtp_codec : false
auth : 3590
bind_rtp_to_media_address : true
bundle : false
call_group : 6
callerid :
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 : padrao
cos_audio : 0
cos_video : 0
device_state_busy_at : 0
direct_media : false
direct_media_glare_mitigation : outgoing
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 : actpass
dtls_verify : No
dtmf_mode : rfc4733
fax_detect : false
fax_detect_timeout : 0
follow_early_media_fork : true
force_avp : true
force_rport : true
from_domain :
from_user :
g726_non_standard : false
geoloc_incoming_call_profile :
geoloc_outgoing_call_profile :
ice_support : true
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 : my ip adress
media_encryption : no
media_encryption_optimistic : false
media_use_received_transport : true
message_context :
moh_passthrough : false
moh_suggest : default
mwi_from_user :
mwi_subscribe_replaces_unsolicited : yes
named_call_group :
named_pickup_group :
notify_early_inuse_ringing : true
one_touch_recording : false
outbound_auth :
outbound_proxy :
outgoing_call_offer_pref : remote_merge
overlap_context :
pickup_group : 6
preferred_codec_only : false
record_off_feature : automixmon
record_on_feature : automixmon
refer_blind_progress : true
rewrite_contact : true
rpid_immediate : false
rtcp_mux : false
rtp_engine : asterisk
rtp_ipv6 : false
rtp_keepalive : 0
rtp_symmetric : true
rtp_timeout : 120
rtp_timeout_hold : 0
sdp_owner : -
sdp_session : Asterisk
security_mechanisms :
security_negotiation : no
send_aoc : false
send_connected_line : yes
send_diversion : true
send_history_info : false
send_pai : false
send_rpid : false
set_var :
srtp_tag_32 : false
stir_shaken : off
stir_shaken_profile :
sub_min_expiry : 0
subscribe_context :
suppress_q850_reason_headers : false
t38_bind_udptl_to_media_address : 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 : transport-udp
trust_connected_line : yes
trust_id_inbound : false
trust_id_outbound : false
use_avpf : false
use_ptime : true
user_eq_phone : false
voicemail_extension :
webrtc : no

I/OAuth: <AuthId/UserName…>

 Auth:  3590/3590

ParameterName : ParameterValue

auth_type : userpass
md5_cred :
nonce_lifetime : 32
oauth_clientid :
oauth_secret :
password : 9ghHYgf71@
realm :
refresh_token :
username : 3590

  Aor:  3590                                                 3

ParameterName : ParameterValue

authenticate_qualify : false
contact :
default_expiration : 3600
mailboxes :
max_contacts : 3
maximum_expiration : 7200
minimum_expiration : 60
outbound_proxy :
qualify_frequency : 0
qualify_timeout : 3.000000
remove_existing : true
remove_unavailable : true
support_path : false
voicemail_extension :

[2024-05-24 10:52:54] NOTICE[35383]: res_pjsip/pjsip_distributor.c:673 log_failed_request: Request ‘REGISTER’ from ‘sip:3590@177.107.192.225’ failed for ‘177.107.192.10:61508’ (callid: 0f803c887d4c4d04ac3ca8be19112715) - Failed to authenticate

I thought the relationship between AORs and endpoints was 1 to many; you are assuming many to many. However the whole process is not well documented.

[ Turns out that it is documented as many to many, but see below about the confusion this could cause with multiple transports. ]

You are not using “extension” in a sense that is meaningful to Asterisk.

As far as I know, you need separate endpoints and AORs, but you then list both endpoint/AOR combinations in extension’s dial string.

I can’t have two endpoints for the same aors?

That is not the message you previously stated, or the configuration you originally gave, and no SIP traffic. I expect if it’s a combination of all the configuration that it’s matching a different endpoint with a different username/password.

You’re in uncharted complicated territory with configuration and usage, trying to mix WebRTC and normal SIP with same naming.

Just using separate endpoints/AORs/auth is far far far simpler and just works.

Yes, the first configuration I made in the pjsip.conf file and the extension 8000 resgitra in both webrctc and micrisip.
I replicate and same configuration in realtime the branches do not register

but I have webrct and sip udp extensions registered normally in realtime. only when I try to register webrtc and sip udp in the same extension this error occurs.

You cannot register to an extension. You can only register to a combination of endpoint and AOR. Extensions are only defined in extensions*.*.

This is dangerous, from a security point of view, and I have not seen any documentation saying that matches are attempted in any particular order, and I can’t imagine it goes to the trouble of doing a a best match, so I would assume it is not defined as to whether this will succeed with JsSIP in the header.

Whilst, as I said, the documentation is lacking (it’s typical of technical product that interfaces are described without how they interact - TV user guides are the classic example), if you can have many to many for endpoints versus aors, the only documented dialstring formats, that I can find, require an endpoint, and it may well work out that only the first contact is tried. In that case, if you dial with the SIP endpoint, and the first contact is a WS one, it is going to fail.

I believe this is incompatible with match_header!

Incidentally. it looks to me as though the default is dangerous, given that most people make the minimum changes for things to work, and this will allow IP authentication to be bypassed. I think it should just be username, so that matching by IP will fail, until a specific setting is made.

This last point has been raised in relation to FreePBX: Attack based on trunk name - #24 by jcolp - Security - FreePBX Community Forums

Strange that I have this configuration working. is registering both webrtc and sip udp. using the same username and password.
I made this configuration directly in pjsip.conf when I do it in the database, it does not authenticate the extensions.

[8000]
type=auth
auth_type=userpass
password=teste123 ; Replace ‘secret’ with the actual password
username=8000 ; Replace ‘6001’ with the actual username

[8000]
type=aor
max_contacts=5
remove_existing=yes

[endpoint_dtls]
type=endpoint
context=padrao
disallow=all
allow=ulaw
aors=8000
auth=8000
dtls_auto_generate_cert=yes
media_encryption=dtls
dtls_verify=no
dtls_setup=actpass
dtls_rekey=0
webrtc=yes ; Assuming WebRTC clients might use this endpoint

[endpoint_no_dtls]
type=endpoint
context=padrao
disallow=all
allow=ulaw
aors=8000
auth=8000
media_encryption=no

[identify_user_agent_dtls]
type=identify
endpoint=endpoint_dtls
match_header=User-Agent: /.JsSIP./

[identify_user_agent_no_dtls]
type=identify
endpoint=endpoint_no_dtls
match_header=User-Agent: /.*/

Something is broken if that works without identify_by =header.

As far as I can see, this is the only filtering done on the contacts in the AOR, and the endpoint has been lost this deep in the code, so I don’t see that it can checking that the transport is compatible, and will only give the first match. I’m therefore reasonably sure that that, when you actually make a call, the result could be a contact which is incompatible with the endpoints’ transport.

It looks to me as though type=aor is an Asterisk thing, not a pjproject one. I also get the impression that type=identify is Asterisk, but I haven’t worked out where that code is, yet, to determine whether there is any guarantee with respect to the order in which overlapping match_header operations are done.

Given that I think there are implementation dependencies in your type=identify processing, one difference between database and conf file may well be the order in which the endpoints are checked for matches. Data stored internally is in hashed lists, and the order in which a list is scanned is not necessarily the order in which it appeared in the file.

It seems to me that the match_header fields work differently when written in the database. in the pjsip.conf file it works fine, but when I put it in the database the extension does not register [identify_user_agent_dtls]
type=identify
endpoint=endpoint_dtls
match_header=User-Agent: /.JsSIP./

[identify_user_agent_no_dtls]
type=identify
endpoint=endpoint_no_dtls
match_header=User-Agent: /.*/

I’ve already explained the only difference I can think of.

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