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

[Rusty Newton (JIRA)]

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

Rusty Newton updated ASTERISK-26287:
------------------------------------

    Assignee: Eugene Voityuk  (was: Rusty Newton)
      Status: Waiting for Feedback  (was: Triage)

I'm thinking we will need to be capable of reproducing this to have a chance at finding the root of the issue.

What would really help is if you could provide a very basic Asterisk configuration with a simple SIPp (or some other tool) scenario for repeated calls that would reproduce the issue over time.

We haven't identified the issue in anything that we currently have going yet.

In the meantime it could be helpful to get a full log (including warning,notice,error and verbose and debug messages at level 5 or above) or excerpts showing three or four points where the gap is increasing over time. It would be nice to have a few hundred lines before the INVITE to see what is going on clearly.


> 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: Eugene Voityuk
>
> 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)