[Home]

Summary:ASTERISK-26315: chan_sip does not produce outbound registration - Negative time interval
Reporter:Stepan (tcp22)Labels:
Date Opened:2016-08-25 09:16:55Date Closed:
Priority:MajorRegression?
Status:Open/NewComponents:Channels/chan_sip/Registration
Versions:11.23.0 13.18.4 Frequency of
Occurrence
Occasional
Related
Issues:
is related toASTERISK-21295 Sip registration fails, wrong parsing when secret has parentheses symbol
is related toASTERISK-17787 SIP registration fails in parsing
is related toASTERISK-25843 chan_sip: Registration passwords can not contain @
Environment:Ubuntu 14.04.5Attachments:( 0) debug
( 1) messages
( 2) sip.conf
Description:After {{sip reload}} command sip peers even realtime or mentioned in configuration files does not register. Reloading sip module again won't fix the issue. Only fully restart asterisk by {{service asterisk restart}} can restore outbound registrations.

messages appeared in console and _messages_ log file:
{noformat}
[2016-08-25 09:56:03] WARNING[27462] sched.c: Bug likely: Negative time interval -47959 (interpreted as 4294919337 ms) requested!
{noformat}
part of debug and messages files will be in an attachment
Comments:By: Asterisk Team (asteriskteam) 2016-08-25 09:16:55.376-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

By: Stepan (tcp22) 2016-08-25 09:21:25.419-0500

part of debug log with masked IP-addresses

By: Stepan (tcp22) 2016-08-25 09:22:36.628-0500

part of messages log file

By: Rusty Newton (rnewton) 2016-08-25 09:50:16.304-0500

Can you attach the sip.conf configuration required to reproduce this behavior using conf file instead of realtime?

By: Stepan (tcp22) 2016-08-25 12:38:39.159-0500

I'm not sure that this behaviour due to sip.conf. I really don't know about reasons. It happened just twice on my system although `sip reload` command executes really often

By: David Brillert (aragon) 2016-08-30 15:03:15.246-0500

I have the same issue and not using realtime
{noformat}
type            =  friend
faxdetect       =  no
defaultuser     =  scrubbed
secret          =  scrubbed
host            =  scrubbed
dtmfmode        =  rfc2833
rfc2833compensate =  no
transport       =  udp
icesupport      =  no
nat             =  no
directmedia     =  no
insecure        =  invite
encryption      =  no
keepalive       =  20
qualify         =  yes
qualifyfreq     =  60
disallow        =  all
allow           =  g729
accountcode     =  default
amaflags        =  default
trustrpid       =  no
sendrpid        =  pai
{noformat}
sip show peers shows the peer OK
sip show registry shows unregistered and dnsmgr N
We are using direct IP and not a FQDN for the registrar address
Asterisk does not send any registration attempt on startup or reload when watched with tcpdump
sip reload always generates something like 'WARNING[23307]: sched.c:489 sched_settime: Bug likely: Negative time interval -120000 (interpreted as 4294847296 ms) requested!'

Tried versions between Asterisk 11.16 and 11.23 and all have the same problem. Work around is to downgrade to 1.8

By: Joel Vandal (jvandal) 2016-10-06 17:26:13.920-0500

The comment from David Brillert was fixed. The problem was very strange and related to an invalid format for register => parameter in sip.conf.

Ex.

reglster => patton:patton@
register => user:pass@host

The first register statement miss the @host part and cause all others entries to be ignored by Asterisk.

This problem happen when using Asterisk 11, we do not have this issue with Asterisk 1.8.