docx
March 17, 2021, 9:30am
1
Hello everyone,
I’m using Asterisk 16.16.1 with PJSIP.
Problem is that after one or two days, the PJSIP endpoint to the ISP stays/hangs “in use”. This endpoint is monitored on BLF, so it seems that the line to the ISP is always busy.
But there are no active channels, nor any other active endpoints.
New incoming or outgoing calls work fine, but don’t clear “in use”.
Just reloading PJSIP, (sometimes restart asterisk) clears the state to “idle”.
I observe this behavior since two years now, it started in Asterisk 13.
Unfortunately I have no idea how to debug this or what might be the cause.
In the dialplan every extension is ending in Hangup(); Return() to terminate the channels correctly.
Any help or hints are really appreciated.
Marco
jcolp
March 17, 2021, 9:36am
2
Are you using realtime? What does “core show hints” show? If you enable “debug” to go to the full log in logger.conf and do “core set debug 5” does it show any information around when it occurs?
docx
March 17, 2021, 10:33am
3
Thanks a lot for your quick reply.
No, I’m not using realtime.
I can enable the logger, but I can’t monitor the PXB personally, so I can’t tell when the state hang exactly occurs. This is part of the problem.
> core show hints
:
1080@ext-hints : PJSIP/telekom_endpoi State:InUse Presence:not_set Watchers 5
:
All other endpoints are Idle.
What is technically needed to bring an endpoint from InUse back to Idle state?
How did you establish there were no active channels? You would need to use the pjsip command, not the core one, to determine whether it had a user.
jcolp
March 17, 2021, 10:39am
5
From a device perspective this[1] is the logic for calculating device state for PJSIP. From a device perspective I’d expect this to only occur if it believes there are channels still associated with the endpoint. If you confirmed that it is the device state that is incorrect, then it would be something relating to that. If the device state is correct but the hint is wrong, then it would be in the hints code.
You can’t reset the state of a device from the CLI or elsewhere.
[1] asterisk/chan_pjsip.c at master · asterisk/asterisk · GitHub
docx
March 17, 2021, 10:42am
6
How did you establish there were no active channels?
DE-H-IPFIRE*CLI> pjsip show channels
No objects found.
while the endpoint is “InUse”.
docx
March 17, 2021, 10:48am
7
It’s definitely not the hint, it’s the endpoint itself:
DE-H-IPFIRE*CLI> pjsip show endpoint telekom_endpoint
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: telekom_endpoint In use 0 of inf
OutAuth: telekom_auth/05115555555
Aor: telekom_aor 0
Contact: telekom_aor/sip:tel.t-online.de 79e95ae29c NonQual nan
Transport: transport-udp udp 0 0 0.0.0.0:5060
Identify: telekom_ident/telekom_endpoint
Match: 217.0.0.0/13
ParameterName : ParameterValue
===================================================================
100rel : yes
accept_multiple_sdp_answers : false
accountcode :
acl :
aggregate_mwi : true
allow : (g722|alaw|g729|g726|gsm|ulaw)
allow_overlap : true
allow_subscribe : true
allow_transfer : true
aors : telekom_aor
asymmetric_rtp_codec : false
auth :
bind_rtp_to_media_address : false
bundle : false
call_group :
callerid : <unknown>
callerid_privacy : allowed_not_screened
callerid_tag :
connected_line_method : invite
contact_acl :
context : from-trunk-telekom
cos_audio : 0
cos_video : 0
device_state_busy_at : 0
direct_media : false
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 : tel.t-online.de
from_user :
g726_non_standard : false
ice_support : false
identify_by : username,ip
ignore_183_without_sdp : false
inband_progress : false
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 : telekom_auth
outbound_proxy : sip:tel.t-online.de;lr
pickup_group :
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 : 0
rtp_timeout_hold : 0
sdp_owner : -
sdp_session : Asterisk
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 : 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 : transport-udp
trust_connected_line : yes
trust_id_inbound : false
trust_id_outbound : false
use_avpf : false
use_ptime : false
user_eq_phone : false
voicemail_extension :
webrtc : no
jcolp
March 17, 2021, 10:49am
8
Then it likely believes it still has a channel for some reason, why that is I do not know.
docx
March 17, 2021, 10:53am
9
Right.
Is it possible to get the endpoints (still) assigned channel by CLI?
That would narrow down the debug.
jcolp
March 17, 2021, 10:54am
10
I can’t think of a CLI command to do so. The ARI interface for endpoints should give a list, though, of the channels which are on the endpoint.
The “pjsip show endpoint” CLI command doesn’t do that, it looks at the complete list of channels on the system instead which is separate.
system
Closed
April 16, 2021, 10:56am
12
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.