[asterisk-bugs] [JIRA] (ASTERISK-26287) Asterisk working on create ICE session for RTP instance for unnormal period of time

[Asterisk Team (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-26287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Asterisk Team closed ASTERISK-26287.
------------------------------------


> Asterisk working on create ICE session for RTP instance for unnormal period of time
> -----------------------------------------------------------------------------------
>
>                 Key: ASTERISK-26287
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26287
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 11.23.0
>            Reporter: Eugene Voityuk
>            Assignee: Rusty Newton
>
> We have noticed that on one of our customer servers INVITE responses are  taking longer than usual after some period of time asterisk being in work (approx 2 weeks).  While investigating we find out that this happens while Creating ICE session. in attached example, it takes 7 seconds. It seems like this delay is increased over time, From unnoticeable  milliseconds just after asterisk started, to up to 7-8 seconds during 2 weeks, when this is becoming noticeable, and we have to restart asterisk. After asterisk restarts, the problem takes new circle.  There are no endpoints on that server that support ice, and we can turn off icesupport in rtp.conf, but I believe that this is a general issue, which can be faced in a mixed environment where some endpoints do support ICE and some are not. Also, i am curious what is the reason to create an ICE session for each call even if both (caller & callee) don't support ICE. As far as i know, chan_sip have two level of icesupport, peer and global from sip.conf, and it seems, like res_rtp_asterisk knows only about global icesupport from rtp.conf, correct me if i am wrong. 
> {noformat}
> [2016-08-10 03:30:17] DEBUG[32254][C-000001f3] chan_sip.c: Initializing initreq for method INVITE - callid 1-c549b2b00a020100.104d7ec2@${IP3}
> [2016-08-10 03:30:17] VERBOSE[32254][C-000001f3] chan_sip.c: Using INVITE request as basis request - 1-c549b2b00a020100.104d7ec2@${IP3}
> [2016-08-10 03:30:17] VERBOSE[32254][C-000001f3] chan_sip.c: Found peer '${peer_name}' for '${peer_name}' from ${IP1}:5060
> [2016-08-10 03:30:17] DEBUG[32254][C-000001f3] rtp_engine.c: Using engine 'asterisk' for RTP instance '0x7ff2d008a028'
> [2016-08-10 03:30:17] DEBUG[32254][C-000001f3] res_rtp_asterisk.c: Allocated port 15044 for RTP instance '0x7ff2d008a028'
> [2016-08-10 03:30:17] DEBUG[32254][C-000001f3] res_rtp_asterisk.c: Creating ICE session ${IP2}:15044 (15044) for RTP instance '0x7ff2d008a028'
> [2016-08-10 03:30:24] DEBUG[39585] manager.c: Running action 'Ping'
> [2016-08-10 03:30:26] DEBUG[32254][C-000001f3] rtp_engine.c: RTP instance '0x7ff2d008a028' is setup and ready to go
> [2016-08-10 03:30:26] DEBUG[32254][C-000001f3] res_rtp_asterisk.c: Setup RTCP on RTP instance '0x7ff2d008a028'
> [2016-08-10 03:30:26] VERBOSE[32254][C-000001f3] netsock2.c:   == Using SIP RTP TOS bits 184
> [2016-08-10 03:30:26] VERBOSE[32254][C-000001f3] netsock2.c:   == Using SIP RTP CoS mark 5
> {noformat}



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