nanosonde
commented
2 years ago Maybe it also makes sense to watch the browser console for the cards messages. Also the webrtc diagnose page from chrome would be helpful.
Closed TECH7Fox closed 2 years ago
nanosonde
commented
2 years ago Maybe it also makes sense to watch the browser console for the cards messages. Also the webrtc diagnose page from chrome would be helpful.
nanosonde
commented
2 years ago Are those people using NAT? Is a STUN server configured in rtp.conf? Maybe also a SIP trace would be helpful: pjsip logger set on
TECH7Fox
commented
2 years ago Will ask for the webrtc debug and pjsip trace.
They do use stun, they got the latest add-on configuration.
TECH7Fox
commented
2 years ago They don't get anything, seems like Asterisk doesn't even try to reach it. Here is a picture:
https://media.discordapp.net/attachments/927579367855521812/959360626575171664/unknown.png
And here is the full log: https://cdn.discordapp.com/attachments/927579367855521812/959361779790671912/message.txt
With the Asterisk log:
[Apr 1 09:59:35] -- Called PJSIP/100/sip:7ofoqh81@82.146.119.172:30309;transport=ws
[Apr 1 10:00:07] == Everyone is busy/congested at this time (1:0/0/1)
[Apr 1 10:00:07] -- Auto fallthrough, channel 'PJSIP/6001-00000002' status is 'CHANUNAVAIL'Here are logs with the pjsip trace.
https://cdn.discordapp.com/attachments/927579367855521812/960210654608916511/message.txt
https://cdn.discordapp.com/attachments/927579367855521812/960241757935767642/PJSIP_log.txt
Both give a 503 service unavailable.
pergolafabio
commented
2 years ago @nanosonde , any clue? this log was mine:
https://cdn.discordapp.com/attachments/927579367855521812/960210654608916511/message.txt
the card i use with duckdns and a simple port forward for RTP and websocket 8099 Calling from card 100 to extension 6000/6001 works, but from 6000 or 6001 to 100 doesnt nothing to see in the f12 developer logs, it just looks like the endpoint can be found
this is my config
[transport-udp]
type = transport
protocol = udp
bind=0.0.0.0:5050
local_net=192.168.0.0/24
local_net=10.8.0.0/24
local_net=172.30.32.0/24
external_media_address=mydomain.com
external_signaling_address=mydomain.com
[transport-wss]
type=transport
protocol=wss
bind=0.0.0.0
local_net=192.168.0.0/24
local_net=10.8.0.0/24
local_net=172.30.32.0/24
external_media_address=mydomain.com
external_signaling_address=mydomain.com
[6000]
type=endpoint
context=default
disallow=all
allow=ulaw,alaw
allow=h264,vp8
auth=auth6000
aors=6000
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
direct_media=no
[auth6000]
type=auth
auth_type=userpass
password=blabla
username=6000
[6000]
type=aor
qualify_frequency=60
max_contacts=1
remove_existing=yes
remove_unavailable=yesi also tried copy/pasting @TECH7Fox his config, and then i have the same issue
pergolafabio
commented
2 years ago @nanosonde , your comment is gone?
yes, i ue the addon, ICE is there:
[general]
rtpstart=10000
rtpend=20000
icesupport=yes
stunaddr=stun.l.google.com:19302i also use it in card config:
iceTimeout: 3
iceConfig:
iceCandidatePoolSize: 0
iceTransportPolicy: all
iceServers:
- urls:
- stun:stun.l.google.com:19302
- stun:stun1.l.google.com:19302But with or without, doesnt make any difference :-(
pergolafabio
commented
2 years ago I think the extension is just unreachable, remember we disabled qualify when i turn qualify back to 60 sec, as soon as i register a websocket extension , it becomes immediately "Unreachable"
[Apr 4 14:09:03] -- Added contact 'sip:pglm7aco@192.168.0.1:5613;transport=ws' to AOR '102' with expiration of 600 seconds
[Apr 4 14:09:06] -- Contact 102/sip:pglm7aco@192.168.0.1:5613;transport=ws is now Unreachable. RTT: 0.000 mseci just created an extra wss endpoint for 102 in the pjsip_custom file, where i enabled qualify back to 60
PS/ whats also , strange, why is there 192.168.0.1 in the above log, thats my router .... shouldnt that be the public ip? its quite normal that 192.168.0.1:5613 is not reachable...
EDIT: when i go mobile with android instead of browser, then i see my public IP
[Apr 4 14:20:06] -- Added contact 'sip:b7dl7au3@178.144.xx.xx:59475;transport=ws' to AOR '102' with expiration of 600 seconds
[Apr 4 14:20:09] -- Contact 102/sip:b7dl7au3@178.144.xx.xx:59475;transport=ws is now Unreachable. RTT: 0.000 msecBut as you can see, goes immediately unreachable, ... thats why it cant be called...
TECH7Fox
commented
2 years ago @pergolafabio here is my logs.
Local, but set the host as my external duckdns address. From hardphone to card.
pergolafabio
commented
2 years ago Hey, what happens if you turn on qualify , do you see the wss extensions still reachable ? I copied over the wss extensions to the custom file, so it doesnt get overwritten...
Mine are always unreachable after 2 sec after the register, so I think that's the reason that I can't call them... But why...
pergolafabio
commented
2 years ago @TECH7Fox as requested the info you wanted :
Global Settings:
ParameterName : ParameterValue
======================================================================
contact_expiration_check_interval : 30
debug : no
default_from_user : asterisk
default_outbound_endpoint : default_outbound_endpoint
default_realm : asterisk
default_voicemail_extension :
disable_multi_domain : false
endpoint_identifier_order : ip,username,anonymous
ignore_uri_user_options : false
keep_alive_interval : 90
max_forwards : 70
max_initial_qualify_time : 0
mwi_disable_initial_unsolicited : false
mwi_tps_queue_high : 500
mwi_tps_queue_low : -1
norefersub : yes
regcontext :
send_contact_status_on_update_registration : no
taskprocessor_overload_trigger : global
unidentified_request_count : 5
unidentified_request_period : 5
unidentified_request_prune_interval : 30
use_callerid_contact : no
user_agent : Asterisk PBX 18.10.1
System Settings:
ParameterName : ParameterValue
============================================
accept_multiple_sdp_answers : false
compact_headers : false
disable_rport : false
disable_tcp_switch : true
follow_early_media_fork : true
threadpool_auto_increment : 5
threadpool_idle_timeout : 60
threadpool_initial_size : 0
threadpool_max_size : 50
timer_b : 32000
timer_t1 : 500
3e533915-asterisk*CLI> pjsip show aor 100
Aor: <Aor..............................................> <MaxContact>
Contact: <Aor/ContactUri............................> <Hash....> <Status> <RTT(ms)..>
==========================================================================================
Aor: 100 6
ParameterName : ParameterValue
=====================================
authenticate_qualify : false
contact :
default_expiration : 3600
mailboxes :
max_contacts : 6
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 :
Thanks, it looks excactly the same for me as expected. Except for the contact of course.
This bug is really weird. Think we should ask the Asterisk community for help.
I also thought about adding the older version of the add-on with chan_sip to the repo.
Also, these could be helpful:
Will look into it some more this week. Hope we can fix it soon.
pergolafabio
commented
2 years ago Yes, it's really weird, more and more people have the issue it seems, will also have a look on forums
pergolafabio
commented
2 years ago The first thread you posted is interesting , what does he mean by :
I took a closer look to the way I handled OPTIONS and saw I wasn’t properly using the branch from the Options request in the Via header of the response. The Contact is now reachable:
pergolafabio
commented
2 years ago as suggested, i reverted back to old card 1.0.1 , there i saw error below again
That leaded me to :
https://community.asterisk.org/t/webrtc-two-servers-registered-but-unavailable-only-one-one/91631/2
_I finally found the problem. I finally noticed the “sip.Parser | error parsing header ‘From’” in the browser console. When I used the ‘from_domain’ option in the endpoint then it worked. By default the From in Asterisk uses the hostname. The problem came from the naming scheme on our production servers have leading digits. Even though, in my opinion, these are correct hostnames, SIP.js doesn’t like it. If I use the ‘fromdomain’ to change it to anything without a leading digit then it works. The working systems just happened to have hostnames without leading digits.
so after adding the from_domain on the webrtc endpoints, it finally worked!!!
like below for example:
; Common ENDPOINT parameters (template)
[sipjs-phone-endpoint](!)
type=endpoint
send_rpid=yes
send_pai=yes
device_state_busy_at=1
webrtc=yes
from_domain=asterisk
; Setting webrtc=yes is a shortcut for setting the following options:
; use_avpf=yes
; media_encryption=dtls
; dtls_auto_generate_cert=yes (if dtls_cert_file is not set)
; dtls_verify=fingerprint
; dtls_setup=actpass
; ice_support=yes
; media_use_received_transport=yes
; rtcp_mux=yes
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
direct_media=no
context=default
disallow=all
allow=ulaw,alaw,speex,gsm,g726,g723,g722,opusI also thought about adding the older version of the add-on with chan_sip to the repo.
Do you really want to go back to chan_sip?
pergolafabio
commented
2 years ago not needed anymore, its fixed now seems the cause was the hostname of the addon, its not allowed to start by digits for asterisk
@nanosonde , in my case the addon was named : 3e533915-asterisk seems thats not allowed @TECH7Fox his addon was named : b35499aa-asterisk
thats why he didnt notice the issue, and some users did
nanosonde
commented
2 years ago According to this more recent RFC a hostname starting with a digit is valid: https://www.rfc-editor.org/rfc/rfc1123#page-13
In the older RFC-952 this was initially specified to be a letter only for the first character.
Anyway, good finding! 👍🏻
So does asterisk needs to fixed here?
pergolafabio
commented
2 years ago So what RFC this addon is based on? Yes, PR already submitted, it's working now
TECH7Fox
commented
2 years ago Do you really want to go back to chan_sip?
Was a idea to test and compare, but it's already fixed.
So does asterisk needs to fixed here?
I guess so, seems like a neasty bug.
Multiple people are having trouble with PJSIP when calling to the card. Calling from does work.
Here is a entire log with debug enabled:
And here is another one:
And here one without debug:
Does anybody know what the issue could be? @nanosonde @felipecrs any ideas?