[asterisk-bugs] [JIRA] (ASTERISK-30069) res_pjsip: Asterisk keeps qualifying after contact expiry

Yury Kirsanov (JIRA) noreply at issues.asterisk.org
Mon May 30 01:08:49 CDT 2022


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

Yury Kirsanov edited comment on ASTERISK-30069 at 5/30/22 1:08 AM:
-------------------------------------------------------------------

Hi,
My apologies, after digging deeper into this issue it turned out to be not really the way I described. Everything works fine when contact is managed by Asterisk. But if we use 'database deltree registrar/contact/XXXX' after the SIP device has crashed - Asterisk keeps sending Options.

But if the contact is getting deleted manually - by issuing asterisk console command "database del registrar/contact xxxxxxxxxxxxxxxxxxxxxxxx" - then Asterisk keeps sending OPTIONS forever.
An example of the second instance is as follows (I have timestamped some events so it would be easier to track them in the log file):

At 18:05:05 the SIP-device 100001 is registered with expire time 600;
At 18:09:00 the SIP-device 100001 was turned off - the power cable pulled out - so the SIP-device didn't send unregister;
Asterisk is trying to qualify the SIP-device 100001 - it receives "408 Request Timeout" response. At 18:09:09 SIP-device 100001 is getting marked as "Unavail"

At 18:11:23 the command is issued in asterisk console - "database del registrar/contact 100001;@0130c7279da65e995ae218246fddc1e4". The contact for 100001 is deleted as well as a record in the database

I'm attaching debug log and PCAP SIP capture showing this behaviour. Thanks!



was (Author: lt_flash):
Hi,
My apologies, after digging deeper into this issue it turned out to be not really the way I described. Everything works fine when contact is managed by Asterisk. But if we use 'database deltree registrar/contact/XXXX' after the SIP device has crashed - Asterisk keeps sending Options.

But if the contact is getting deleted manually - by issuing asterisk console command "database del registrar/contact xxxxxxxxxxxxxxxxxxxxxxxx" - then Asterisk keeps sending OPTIONS forever.
An example of the second instance is as follows (I have timestamped some events so it would be easier to track them in the log file):

At 18:05:05 the SIP-device 100001 is registered with expire time 600;
At 18:09:00 the SIP-device 100001 was turned off - the power cable pulled out - so the SIP-device didn't send unregister;
Asterisk is trying to qualify the SIP-device 100001 - it receives "408 Request Timeout" response. At 18:09:09 SIP-device 100001 is getting marked as "Unavail"

At 18:11:23 the command is issued in asterisk console - "database del registrar/contact 100001;@0130c7279da65e995ae218246fddc1e4". The contact for 100001 is deleted as well as a record in the database



> res_pjsip: Asterisk keeps qualifying after contact expiry
> ---------------------------------------------------------
>
>                 Key: ASTERISK-30069
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-30069
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip
>    Affects Versions: 18.7.0, 18.12.0
>         Environment: Ubuntu 20.04.4LTS
>            Reporter: Yury Kirsanov
>            Assignee: Unassigned
>         Attachments: asterisk.log, sip.pcap
>
>
> We have Asterisk server that acts as a registrar and a SIP device that connects to Asterisk via a SIP proxy that adds Path header to stay in between Asterisk and SIP device.
> After successful registration if SIP device has disconnected without sending Unregister SIP packet with Expiry=0 Asterisk would keep qualifying that device forever.
> 'pjsips show contacts' show that contact is removed as well as 'database show'. Also logs show that contact has been removed due to expiry but still SIP proxy receives SIP OPTIONS packets from Asterisk.
> Here's output of 'pjsip set logger host <sip_proxy>':
> [May 18 03:57:10] <--- Transmitting SIP request (519 bytes) to UDP:X.X.X.X:5060 --->
> [May 18 03:57:10] OPTIONS sip:XXXXXX at X.X.X.X:62024 SIP/2.0
> [May 18 03:57:10] Via: SIP/2.0/UDP X.X.X.X:5060;rport;branch=z9hG4bKPj73d001de-73b5-445c-895e-2d492e876c25
> [May 18 03:57:10] From: <sip:XXXXXX at X.X.X.X>;tag=43bd3567-53ed-46b5-8ddf-b2c5bddb4042
> [May 18 03:57:10] To: <sip:XXXXXX at X.X.X.X>
> [May 18 03:57:10] Contact: <sip:XXXXXX at X.X.X.X:5060>
> [May 18 03:57:10] Call-ID: b1a62aed-8b66-40b4-8d1d-6b1f6718318c
> [May 18 03:57:10] CSeq: 27361 OPTIONS
> [May 18 03:57:10] Supported: path
> [May 18 03:57:10] Route: <sip:X.X.X.X;lr;received=sip:X.X.X.X:62024%3btransport%3dwss>
> [May 18 03:57:10] Max-Forwards: 70
> [May 18 03:57:10] User-Agent: Agent
> [May 18 03:57:10] Content-Length:  0
> The only way to stop this is to restart Asterisk.



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



More information about the asterisk-bugs mailing list