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

[Ian Gilmour (JIRA)]

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

Ian Gilmour edited comment on ASTERISK-27251 at 9/14/17 10:39 AM:
------------------------------------------------------------------

[^ast-conf.tgz] contains the requested config files.

Asterisk is running on a local ubuntu 16.04 VM.

The asterisk config supports registrations from 20 chan_sip users (1001-1020 - defined in users.conf), each with no password.

I've simplified the dialplan to just support a conf room on 1234 being dialed by a local chan_sip user. The user gets prompted for conf room number and pin (both 1-20 digits in length).

To aid debugging I've also simplified the chan_sip setup to accept clients on tcp rather than tls and use rtp rather than srtp.

musiconhold is now off by default. The problem still occurs.

The Jitsi SIP client is running on a local host and registers with asterisk as user 1006, on tcp port 5060. Jitsi is configured to use ulaw and alaw. 

To reproduce the problem:

* Having registered a SIP client with asterisk, dial 1234. You'll get prompted for a conf room number and pin. Enter 1-20 digits for each and you'll enter the dynamically created conf room.

* You'll be told "you are the only participant in the conference".

* Disconnect the SIP client host from the network and terminate the SIP client app. 

* "sip show channelstats" confirms media continues to play beyond the rtptimeout configured in sip.conf (60 secs). Media continues to flow  indefinitely.

* Reconnect the SIP client host, restart the SIP client app (Jitsi) and reregister it with asterisk.

* Again dial 1234 and re-enter the same conf room as before, using the same pin.

* You'll get told "there is 1 other user in the conference".

* "confbridge list <confRoomNumber>" confirms the same user is now in the conference twice.

* "sip show channelstats" confirms media is now playing to 2 users. Media continues to flow to both users indefinitely.

You can repeat the above to get the same user in the conference multiple times, with media streams flowing indefinitely to each.

The only way to stop the media flow is to kick the user out of the conference. Or to disable the confbridge jitterbuffer (i.e. set jitterbuffer=no in confbridge.conf) and restart asterisk. Or to revert the ASTERISK-26523 change.
 


was (Author: tuxian):
[^ast-conf.tgz] contains the requested config files.

Asterisk is running on a local ubuntu 16.04 VM.

The asterisk config supports registrations from 20 chan_sip users (1001-1020 - defined in users.conf), each with no password.

I've simplified the dialplan to just support a conf room on 1234 being dialed by a local chan_sip user. The user gets prompted for conf room number and pin (both 1-20 digits in length).

To aid debugging I've also simplified the chan_sip setup to accept clients on tcp rather than tls and use rtp rather than srtp.

musiconhold is now off by default. The problem still occurs.

The Jitsi SIP client is running on a local host and registers with asterisk as user 1006, on tcp port 5060. Jitsi is configured to use ulaw and alaw. 

To reproduce the problem:

* Having registered a SIP client with asterisk, dial 1234. You'll get prompted for a conf room number and pin. Enter 1-20 digits for each and you'll enter the dynamically created conf room.

* You'll be told "you are the only participant in the conference".

* Disconnect the SIP client host from the network and terminate the SIP client app. 

* "sip show channelstats" confirms media continues to play beyond the rtptimeout configured in sip.conf (60 secs). Media continues to flow  indefinitely.

* Reconnect the SIP client host, restart the SIP client app (Jitsi) and reregister it with asterisk.

* Again dial 1234 and re-enter the same conf room as before, using the same pin.

* You'll get told "there is 1 other user in the conference".

* "confbridge list <confRoomNumber>" confirms the same user is now in the conference twice.

* "sip show channelstats" confirms media is now playing to 2 users. Media continues to flow to both users indefinitely.

You can repeat the above to get the same user in the conference multiple times, with media streams flowing indefinitely to each.

The only way to stop the media flow is to kick the user out of the conference. Or to disable the confbridge jitterbuffer (i.e. set jitterbuffer=no in confbridge.conf) and restart asterisk.
 

> 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: ast-conf.tgz, 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)