[asterisk-bugs] [JIRA] (ASTERISK-29090) Asterisk tries to persist TCP and TLS Subscriptions and always fails

[Peter Sokolov (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252195#comment-252195 ] 

Peter Sokolov commented on ASTERISK-29090:
------------------------------------------

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 at 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 at mysipproxy.com>;tag=zyk5sm3l9w\r\nt: <sip:290 at 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 at 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.

> Asterisk tries to persist TCP and TLS Subscriptions and always fails
> --------------------------------------------------------------------
>
>                 Key: ASTERISK-29090
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29090
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip_pubsub
>    Affects Versions: 17.7.0
>            Reporter: Peter Sokolov
>            Assignee: Peter Sokolov
>            Severity: Minor
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)