[asterisk-bugs] [JIRA] (ASTERISK-21203) res_xmpp socket error: takes upto 19 minutes to restore xmpp socket connection to google

Chirag Chhatriwala (JIRA) noreply at issues.asterisk.org
Wed Mar 13 15:40:01 CDT 2013


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

Chirag Chhatriwala edited comment on ASTERISK-21203 at 3/13/13 3:38 PM:
------------------------------------------------------------------------

David: In certain regions of the world, there are no other options because of the internet providers that are available in the area. Point is the ISP may also be doing this to protect against DDoS attacks on the service to its customers (who happen to be facing a lot of hacker traffic, which is also common). I'm not trying to argue how the internet or the PPP protocol were designed to work. I also want to show that Asterisk is working as a server on a connection which is forced to renew an IP address however the connection "google xmpp re-establishment" takes a long time. If it does the re-establishment, why take 20 minutes ? Why not a shorter interval to realize that the connection is stale and re-connect quicker?

Did anyone even look at the Logfile and try to understand why the re-connection took so long?

[2013-02-13 09:17:02]... call dropped due to IP address change...
.
.
.
[2013-02-13 09:35:41] WARNING[2898] res_xmpp.c: JABBER: socket read error
[2013-02-13 09:35:41] DEBUG[2898] res_xmpp.c: Connecting client 'google'

Thats about 19 minutes. Surely there has to be a way to speed this up. 

You have to understand that even DHCP which upon IP renewal can issue a different IP address if the ISP forces. This isn't really about PPPoE.
Its about the re-establishment of the xmpp connection to google. 

Edit: This instance shows the time it took to reconnect as about 19 minutes because the call dropped during the IP address change. However, in the case no calls are on-going, there is "no-way" to tell that the google connection is stale unless I look at the time it elapsed since the IP address changed (which only my router can tell).
                
      was (Author: cchhat01):
    David: In certain regions of the world, there are no other options because of the internet providers that are available in the area. Point is the ISP may also be doing this to protect against DDoS attacks on the service to its customers (who happen to be facing a lot of hacker traffic, which is also common). I'm not trying to argue how the internet or the PPP protocol were designed to work. I also want to show that Asterisk is working as a server on a connection which is forced to renew an IP address however the connection "google xmpp re-establishment" takes a long time. If it does the re-establishment, why take 20 minutes ? Why not a shorter interval to realize that the connection is stale and re-connect quicker?

Did anyone even look at the Logfile and try to understand why the re-connection took so long?

[2013-02-13 09:17:02]... call dropped due to IP address change...
.
.
.
[2013-02-13 09:35:41] WARNING[2898] res_xmpp.c: JABBER: socket read error
[2013-02-13 09:35:41] DEBUG[2898] res_xmpp.c: Connecting client 'google'

Thats about 19 minutes. Surely there has to be a way to speed this up. 

You have to understand that even DHCP which upon IP renewal can issue a different IP address if the ISP forces. This isn't really about PPPoE.
Its about the re-establishment of the xmpp connection to google. 
                  
> res_xmpp socket error: takes upto 19 minutes to restore xmpp socket connection to google
> ----------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-21203
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21203
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_xmpp
>    Affects Versions: 11.3.0
>         Environment: Linux OpenWrt 3.7.5 #2 Wed Feb 6 20:40:48 EST 2013 mips GNU/Linux
>            Reporter: Chirag Chhatriwala
>         Attachments: messages
>
>
> 11.3.0-rc1 addresses a problem in which if a res_xmpp connection becomes stale (network interruption/IP address change), the res_xmpp performs a reconnect and the filters are also refreshed to make sure it responds to jingle/chan_motif signalling.
> Now, it takes about 18-20 minutes to recover from a network outage. I.e. IP Address change. There doesn't seem to be any way to minimize the time before the following message:
> [2013-03-02 09:18:13] WARNING[15652][C-00000026] res_rtp_asterisk.c: RTP Transmission error of packet to 74.125.135.127:19305: Network is unreachable
> [2013-03-02 09:18:13] WARNING[15652][C-00000026] res_rtp_asterisk.c: RTP Transmission error of packet to 74.125.135.127:19305: Network is unreachable
> [2013-03-02 09:18:13] WARNING[15652][C-00000026] res_rtp_asterisk.c: RTP Transmission error of packet to 74.125.135.127:19305: Network is unreachable
> [2013-03-02 09:36:29] WARNING[2872] res_xmpp.c: JABBER: socket read error
> I have a log file which is about 21.6MB in size so I'm not uploading it here just as yet.
> I have a smaller log file which does show this time difference of 18+ minutes as well. The file shows that a google voice call gets interrupted (as a result of IP renewal resulting in a changed IP) and then the jabber socket read error appears around 18+ minutes later.
> This is indicative of all IP Address renewals.
> In the above, the time between 09:18:13 and 09:36:29, any outbound calls [through google voice] do not work and any inbound calls [through google voice] do not terminate on my SIP phone. After, 09:36:29, everything works as it should. I'm trying to minimize this window where the connection is in limbo.
> Please help.
> Thanks,
> Chirag

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list