[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=238642#comment-238642 ] 

Ian Gilmour edited comment on ASTERISK-27251 at 9/12/17 5:41 AM:
-----------------------------------------------------------------

Rereading ASTERISK-25270, I checked my confbridge setup.

In the previous tests I had "jitterbuffer=yes" configured in the confbridge.conf user profile.

Setting "jitterbuffer=no" results in a conf room that honours the rtptimeout setting again, but presumably will potentially result in poorer audio heard by the conf room participants.

I also confirmed that setting confbridge "music_on_hold_when_empty=no", when jitterbuffer="yes", results in the same behaviour as when "music_on_hold_when_empty=yes". i.e. I can get the same user in a conference call multiple times, each being sent a media stream indefinitely, with no client at the other end of the media stream. Presumably the music on hold media is simply replaced with silence frames.


was (Author: tuxian):
Rereading ASTERISK-25270, I checked my confbridge setup.

In the previous tests I had "jitterbuffer=yes" configured in the confbridge.conf user profile.

Setting "jitterbuffer=no" results in a conf room that honours the rtptimeout setting again, but presumably will potentially result in poorer audio heard by the conf room participants.

I also confirmed that setting confbridge "music_on_hold_when_empty=no", when jitterbuffer="yes", results in the same behaviour as when "music_on_hold_when_empty=yes". i.e. I can get the same user in a conference call multiple times, each being sent a media stream indefinitely. Presumably the music on hold media is simply replaced with silence frames.

> 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)