[asterisk-bugs] [JIRA] (ASTERISK-27251) chan_sip doesn't honour rtptimeout setting

Ian Gilmour (JIRA) noreply at issues.asterisk.org
Mon Sep 11 10:07:08 CDT 2017


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

Ian Gilmour commented on ASTERISK-27251:
----------------------------------------

Note, I can also reregister the same chan_sip SIP client (Jitsi) with Asterisk, rejoin the same conf call, and again kill the sip client's network connection, and I can do this multiple times. This results in the same user appearing in the conf call multiple times. Every time I do this it adds another outgoing Asterisk media stream, that continues to be sent  packets indefinitely, with (potentially) nothing at the other end to receive it.

{noformat}
*CLI> sip show channelstats
Peer             Call ID      Duration Recv: Pack  Lost       (     %) Jitter Send: Pack  Lost       (     %) Jitter
10.10.0.19       0f2e4ed2355  00:00:22 0000000901  0000000000 ( 0.00%) 0.0000 0000000822  0000000000 ( 0.00%) 0.0060
10.10.0.19       daa1c4bb415  00:51:44 0000001761  0000000000 ( 0.00%) 0.0000 0000000154K 0000000000 ( 0.00%) 0.0063
*CLI> sip show channelstats
Peer             Call ID      Duration Recv: Pack  Lost       (     %) Jitter Send: Pack  Lost       (     %) Jitter
10.10.0.19       ac65cff28ff  00:01:09 0000003297  0000000000 ( 0.00%) 0.0000 0000003076  0000000003 ( 0.10%) 0.0062
10.10.0.19       0f2e4ed2355  00:21:52 0000034224  0000000000 ( 0.00%) 0.0000 0000064726  0000000000 ( 0.00%) 0.0063
10.10.0.19       daa1c4bb415  01:13:14 0000001761  0000000000 ( 0.00%) 0.0000 0000000217K 0000000000 ( 0.00%) 0.0063
10.10.0.19       1e1f8c48ab4  00:03:12 0000002196  0000000000 ( 0.00%) 0.0000 0000008971  0000000000 ( 0.00%) 0.0060
4 active SIP channels
*CLI> sip show channelstats
Peer             Call ID      Duration Recv: Pack  Lost       (     %) Jitter Send: Pack  Lost       (     %) Jitter
10.10.0.19       ac65cff28ff  00:01:11 0000003413  0000000000 ( 0.00%) 0.0000 0000003192  0000000003 ( 0.09%) 0.0063
10.10.0.19       0f2e4ed2355  00:21:54 0000034224  0000000000 ( 0.00%) 0.0000 0000064842  0000000000 ( 0.00%) 0.0063
10.10.0.19       daa1c4bb415  01:13:17 0000001761  0000000000 ( 0.00%) 0.0000 0000000218K 0000000000 ( 0.00%) 0.0063
10.10.0.19       1e1f8c48ab4  00:03:15 0000002196  0000000000 ( 0.00%) 0.0000 0000009087  0000000000 ( 0.00%) 0.0060
4 active SIP channels
*CLI> sip show channelstats
Peer             Call ID      Duration Recv: Pack  Lost       (     %) Jitter Send: Pack  Lost       (     %) Jitter
10.10.0.19       ac65cff28ff  00:01:13 0000003517  0000000000 ( 0.00%) 0.0000 0000003296  0000000003 ( 0.09%) 0.0057
10.10.0.19       0f2e4ed2355  00:21:56 0000034224  0000000000 ( 0.00%) 0.0000 0000064946  0000000000 ( 0.00%) 0.0063
10.10.0.19       daa1c4bb415  01:13:19 0000001761  0000000000 ( 0.00%) 0.0000 0000000218K 0000000000 ( 0.00%) 0.0063
10.10.0.19       1e1f8c48ab4  00:03:17 0000002196  0000000000 ( 0.00%) 0.0000 0000009191  0000000000 ( 0.00%) 0.0060
4 active SIP channels
*CLI> sip show channelstats
Peer             Call ID      Duration Recv: Pack  Lost       (     %) Jitter Send: Pack  Lost       (     %) Jitter
10.10.0.19       ac65cff28ff  00:01:16 0000003629  0000000000 ( 0.00%) 0.0000 0000003408  0000000003 ( 0.09%) 0.0066
10.10.0.19       0f2e4ed2355  00:21:58 0000034224  0000000000 ( 0.00%) 0.0000 0000065058  0000000000 ( 0.00%) 0.0063
10.10.0.19       daa1c4bb415  01:13:21 0000001761  0000000000 ( 0.00%) 0.0000 0000000218K 0000000000 ( 0.00%) 0.0063
10.10.0.19       1e1f8c48ab4  00:03:19 0000002196  0000000000 ( 0.00%) 0.0000 0000009303  0000000000 ( 0.00%) 0.0060
4 active SIP channels
*CLI> sip show channelstats
Peer             Call ID      Duration Recv: Pack  Lost       (     %) Jitter Send: Pack  Lost       (     %) Jitter
10.10.0.19       ac65cff28ff  00:01:17 0000003687  0000000000 ( 0.00%) 0.0000 0000003466  0000000003 ( 0.09%) 0.0061
10.10.0.19       0f2e4ed2355  00:22:00 0000034224  0000000000 ( 0.00%) 0.0000 0000065116  0000000000 ( 0.00%) 0.0063
10.10.0.19       daa1c4bb415  01:13:22 0000001761  0000000000 ( 0.00%) 0.0000 0000000218K 0000000000 ( 0.00%) 0.0063
10.10.0.19       1e1f8c48ab4  00:03:20 0000002196  0000000000 ( 0.00%) 0.0000 0000009361  0000000000 ( 0.00%) 0.0060
4 active SIP channels
*CLI> sip show channelstats
Peer             Call ID      Duration Recv: Pack  Lost       (     %) Jitter Send: Pack  Lost       (     %) Jitter
10.10.0.19       ac65cff28ff  00:01:18 0000003754  0000000000 ( 0.00%) 0.0000 0000003533  0000000003 ( 0.08%) 0.0060
10.10.0.19       0f2e4ed2355  00:22:01 0000034224  0000000000 ( 0.00%) 0.0000 0000065183  0000000000 ( 0.00%) 0.0063
10.10.0.19       daa1c4bb415  01:13:23 0000001761  0000000000 ( 0.00%) 0.0000 0000000218K 0000000000 ( 0.00%) 0.0063
10.10.0.19       1e1f8c48ab4  00:03:21 0000002196  0000000000 ( 0.00%) 0.0000 0000009428  0000000000 ( 0.00%) 0.0060
4 active SIP channels
*CLI> conf
confbridge  config      
*CLI> confbridge 
kick    list    lock    mute    record  show    unlock  unmute  
*CLI> confbridge list 1234 
Channel                        Flags  User Profile     Bridge Profile   Menu             CallerID
============================== ====== ================ ================ ================ ================
SIP/1006-00000000              ME     USER             conferences      admin_menu       1006
SIP/1006-00000001              ME     USER             conferences      user_menu        1006
SIP/1006-00000002              ME     USER             conferences      user_menu        1006
SIP/1006-00000003              ME     USER             conferences      user_menu        1006
*CLI> 
{noformat}

This simulates a SIP client at the end of a dodgy network connection - so it seems reasonable to expect Asterisk to handle.


> chan_sip doesn't honour rtptimeout setting
> ------------------------------------------
>
>                 Key: ASTERISK-27251
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27251
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 13.17.1
>         Environment: Ubuntu 16.04 (64-bit)
>            Reporter: Ian Gilmour
>            Assignee: Unassigned
>         Attachments: cli.tgz
>
>
> I have Asterisk running in the cloud with sip.conf configured with:
> {noformat}
> rtptimeout=60
> rtpholdtimeout=300
> rtpkeepalive=20
> {noformat}
> I have a confbridge managed conference room, configured to play MOH if there is only 1 participant.
> I have a SIP client (Jitsi) configured to use TLS+SRTP. It registers with Asterisk on a chan_sip managed IP address + port.
> The SIP client is behind a NAT.
> If the SIP client enters the conference room MOH plays as expected. If I then disconnect the SIP client from the network (so it doesn't deregister, or issue a SIP BYE) I see Asterisk sending media (MOH) to the SIP client's orginal IP address and port indefinitely (>24hours+) and the CLI shows the user as present in the conf call. Media output only terminates if I kick the user manually out of the conf call via the CLI.
> Once the SIP client is disconnected from the network wireshark shows ICMP Destination unreachable messages being returned in response to each Asterisk (MOH) outgoing media packet.
> n.b. I see similar behaviour if I run both Asterisk and client locally. i.e. no NAT.
> The bug seems to be related to ASTERISK-26523.
> Reverting the ASTERISK-26523 change so that it only updates the lastrtprx if the frame isn't AST_FRAME_NULL gives me a chan_sip that honours the sip.conf rtptimeout.



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



More information about the asterisk-bugs mailing list