[Home]

Summary:ASTERISK-29090: Asterisk tries to persist TCP and TLS Subscriptions and always fails
Reporter:Peter Sokolov (peterdoo)Labels:
Date Opened:2020-09-21 11:14:04Date Closed:2020-10-06 12:00:01
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Resources/res_pjsip_pubsub
Versions:17.7.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:
Description:When Endpoints subscribe via TCP and TLS transport, Asterisk persists those subscriptions and tries to recreate them after restart. However, as no TCP connection survives a restart, all intents to recreate them after a restart fail. The following three lines are logged after restart for each persisted subscription:

[Sep 21 17:27:57] ERROR[3888] res_pjsip.c: Could not create dialog with endpoint 295. Invalid URI (PJSIP_EINVALIDURI)
[Sep 21 17:27:57] WARNING[3888] res_pjsip_pubsub.c: Unable to create dialog for SIP subscription
[Sep 21 17:27:57] WARNING[3888] res_pjsip_pubsub.c: Failed recreating '295' subscription: Could not create subscription tree.

In my opinion Asterisk should not try to recreate persisted subscriptions which came in via TCP or TLS after Asterisk restarts.

I don't know whether there is a case where subscriptions in Asterisk get lost and need to be recreated without all sockets being closed. Only in such a case recreating TCP and TLS subscriptions would be necessary, but not in the cases like Asterisk (and PJSIP?) restart, where all the sockets are closed which causes all TCP connections to drop.
Comments:By: Asterisk Team (asteriskteam) 2020-09-21 11:14:05.043-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/].
By: Joshua C. Colp (jcolp) 2020-09-22 05:15:33.534-0500

What's the actual configuration, contents of "database show", and SIP traffic?

TCP/TLS connections can actually be recreated if the endpoint is actually reachable by the given Contact address. If connection reuse is enabled (rewrite_contact=yes) then we indeed should not persist.
By: Peter Sokolov (peterdoo) 2020-09-22 09:03:20.402-0500

The endpoints normally are behind the firewall. In the case of TCP this means that after closing a socket it is impossible to establish a new TCP connection triggered by Asterisk with the same pair of source/destination IP-Address/port which would be required for the registration/subscription to keep working. The only possibility that I see for reestablishing a TCP connection is, that an endpoint establishes a new TCP connection to Asterisk (TCP Asterisk to endpoint is usually blocked by a firewall). This would be from a different source port number. However, in that case a client knows that it has to restart registration/subscription process and there is no need for persistance of registrations and subscriptions.

My endpoint is configured in the following way. The only way Asterisk can reach it is by reusing the TCP connection:
{noformat}
[295]
type=endpoint
context=clientcontext
subscribe_context=clientcontext
from_domain=mysipproxy.com
call_group=5
pickup_group=6
disallow=all
allow=g722
auth=295
aors=295
direct_media=no
media_encryption=sdes
device_state_busy_at=1
allow_subscribe=yes
tone_zone=de
language=de

[295]
type=auth
auth_type=userpass
password=mypass
username=295
realm=mysipproxy.com

[295]
type=aor
max_contacts=1
remove_existing=yes
maximum_expiration=180
{noformat}

database show displays the following for it:
{noformat}
/registrar/contact/295;@f4d013f27a39bd0638520378a54aac2d: {"via_addr":"2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx","qualify_timeout":"3.000000","call_id":"3136303037373431363138373538-ba9cjz0zy42x","reg_server":"","prune_on_boot":"no","path":"","endpoint":"295","via_port":"36305","authenticate_qualify":"no","uri":"sip:295@[2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]:36305;transport=Tls;line=chwp3qcs","qualify_frequency":"0","user_agent":"snomD315/10.1.49.11","expiration_time":"1600776405","outbound_proxy":""}

/subscription_persistence/subscription_persistence/bbeaaa29-e09d-4635-ab30-860cab412188: {"src_port":"36305","expires":"1600776565","transport_key":"TLS","cseq":"349","prune_on_boot":"no","endpoint":"295","generator_data":"{\"20\":0}","packet":"SUBSCRIBE sip:290@mysipproxy.com SIP/2.0\r\nv: SIP/2.0/TLS [2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]:36305;branch=z9hG4bK-gc63s2oxdnit;rport\r\nf: <sip:295@mysipproxy.com>;tag=zyk5sm3l9w\r\nt: <sip:290@mysipproxy.com>;user=phone\r\ni: 313630303737343136303432343435-gmp8kwe7jjen\r\nCSeq: 1 SUBSCRIBE\r\nMax-Forwards: 70\r\nUser-Agent: snomD315/10.1.49.11\r\nm: <sip:295@[2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]:36305;transport=Tls;line=chwp3qcs>;reg-id=1\r\nEvent: dialog\r\nAccept: application/dialog-info+xml\r\nAuthorization: Digest username=\"295\",realm=\"mysipproxy.com\",nonce=\"1600774164/eeb294e4c53ad8df77702f1c9db0aa3b\",uri=\"sip:290@mysipproxy.com\",qop=auth,nc=00000005,cnonce=\"6e1c9fb5\",response=\"f79b403ee4e15dee1b8d4c397803eacf\",opaque=\"639a6d563df55313\",algorithm=MD5\r\nExpires: 600\r\nl: 0\r\n\r","src_name":"2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx","local_name":"2a01:xxxx:xxxx:xxxx::2","tag":"8fd0dead-0f62-4b68-aa7b-59041b7dc45a","contact_uri":"<sip:295@[2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]:36305;transport=Tls;line=chwp3qcs>","local_port":"5061"}
{noformat}

However the message after Asterisk restart is not indicating that the endpoint cannot be reached via TCP. It says "Invalid URI (PJSIP_EINVALIDURI)". From that message one might understand that PJSIP is not even trying to recreate a subscription when used protocol is TCP or TLS.
By: Joshua C. Colp (jcolp) 2020-09-22 09:07:07.113-0500

I would expect the "rewrite_contact" option to be set to yes in order to do connection reuse, if you enable it does that cause the behavior you are expecting?
By: Asterisk Team (asteriskteam) 2020-10-06 12:00:00.884-0500

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines