FreePBX SIP Trunk Register Timer?

I have another client using a BroadVoice SIP Trunk, this time it is Residential with a dynamic IP. It is configured differently than the Business SIP Trunk and requires a Register String, but I was able to get it working, thanks to this article:

[http://www.freepbx.org/support/documentation/howtos/howto-setting-up-voip-provider-trunks/broadvoice-alternative-corrected][1]

The trunk works! I have no audio problems, and I can make and receive calls. However, BroadVoice tech support called me and the tech said he was looking at the debug from my calls and he had no idea how it was working…

  • He said I was registering as <my number>:[email protected]<my own IP> instead of <my number>:[email protected]
  • Also, he said the register time was too low (its supposed to be 3600) and was giving an error msg

trunk config PEER details

disallow=all
allow=ulaw&alaw&g729
context=from-trunk
dtmf=auto
dtmfmode=inband
fromdomain=sip.phonepower.com
fromuser=2193074080
host=sip.phonepower.com
insecure=port,invite
qualify=yes
secret=secret
type=peer
user=2193079999
username=2193079999

Register String

2193079999:[email protected]/2193079999

As for the wrong IP when registering, I can only assume he is confused or something (how could calls work if it really was registering to the wrong IP…)

But I’m curious about where to change the trunk registration to be 3600

Thanks!
[1]: http://www.freepbx.org/support/documentation/howtos/howto-setting-up-voip-provider-trunks/broadvoice-alternative-corrected

Try using:-

qualify=3600

thanks dicko, i removed qualify=yes and added qualify=3600

will check with support on Monday to see if that gets rid of the error.

dicko,

Im still seeing the error message in asterisk debug

[2014-12-06 09:09:56] WARNING[3022]: chan_sip.c:23419 handle_response_register: Got 423 Interval too brief for service [email protected], minimum is 3600 seconds

Any ideas?

add

registertimeout = 3600

to your “other sip settings”

tried registertimeout=3600

error still occurring.

I only changed the “from” number in the output

[2014-12-06 15:56:45] WARNING[2993]: chan_sip.c:23419 handle_response_register: Got 423 Interval too brief for service [email protected], minimum is 3600 seconds
[2014-12-06 15:58:30] WARNING[2993]: chan_sip.c:23419 handle_response_register: Got 423 Interval too brief for service [email protected], minimum is 3600 seconds
[2014-12-06 16:00:15] WARNING[2993]: chan_sip.c:23419 handle_response_register: Got 423 Interval too brief for service [email protected], minimum is 3600 seconds
[2014-12-06 16:02:00] WARNING[2993]: chan_sip.c:23419 handle_response_register: Got 423 Interval too brief for service [email protected], minimum is 3600 seconds
[2014-12-06 16:03:45] WARNING[2993]: chan_sip.c:23419 handle_response_register: Got 423 Interval too brief for service [email protected], minimum is 3600 seconds
[2014-12-06 16:05:31] WARNING[2993]: chan_sip.c:23419 handle_response_register: Got 423 Interval too brief for service [email protected], minimum is 3600 seconds
[2014-12-06 16:07:16] WARNING[2993]: chan_sip.c:23419 handle_response_register: Got 423 Interval too brief for service [email protected], minimum is 3600 seconds

Sorry, I don’t have that trouble, did you reload sip?

I have reloaded the server but how to reload sip?

I dont really care, like i said its working so not sure that it matters, just curious if anyone knew how to fix

from bash

rasterisk -s ‘sip reload’

I’ll let you guess how to do that from the asterisk CLI :slight_smile:

also

rasterisk -x ‘sip show settings’

to see what you actually have set. if they don’t suit your provider then there is always google.

It took me a few days to finally figure out what the issue was with drop calls every 60 minutes (after a bounce of SIP/Asterisk) that corresponded to a warning of 423 interval too brief log entry. I was lucky to have someone on the Trunk provider side (Consolidated Communications here in Champaign, IL) help with feedback from their logs.

Every 60 minutes our phone calls would drop (occurring after bouncing the SIP service or rebooting the Asterisk SIP engine). I was using a test conference line provided by freeconferenceline.com. I’d dial in from a few of the phones here at the office. I’d then would wait to get a summary report from freeconferenceline.com showing the exact moment the call was dropped. Looking at the Asterisk log files (full) I was seeing “423 interval too brief…, minimum 3600 seconds.” Apparently, per the RFC4361 rules the registrar must reply with the minimum. I tried every registry configuration - except I didn’t make them all the same - which in my case was the key. In my instance I finally got to a successful configuration by setting Asterisk SIP Settings > Chan SIP Settings > Registration Settings - Registration Min/Max/Default all 3600.

Moral of the story - this took FOREVER to figure out and there is very little documentation on the purpose behind some of these settings. I guess they are like this so Sangoma support can make some $$$.

I verrrrrrry seriously doubt they would do that on purpose…

I have found some of the help texts to be lacking but I don’t believe in any conspiracy

I am pretty sure that uf you submitted a pull request against the relevant module or modules they would merge/commit it…

Have a nice day,

Nick

Maybe I’m a little paranoid?

I also believe that fast food joints conveniently forget to put CHEESE on their burgers, subs, etc. so they can make extra money. No one is going to drive 15 minutes back to the establishment just to get $0.60! Multiply this occurrence by a couple hundred a day over the course of a year and you have yourself about $21,000 extra in the bank!

What is a pull request? Do I do that on the ticket system?

These default settings have existed for years this way and worked for hundreds of thousands of people, except for you. When they don’t work for you then you automatically jump to the conclusion of “so Sangoma support can make some $$$”. The community at large actually flagged your post because it was concerning.

Here are the settings you are referencing

And here are the defaults from Asterisk themselves. They are the exact same. Which is why we set them this way. (asterisk/sip.conf.sample at master · asterisk/asterisk · GitHub)

The descriptions we provided are also the same descriptions that are in the sample files.

I shouldn’t have had to even explain this.

1 Like

Between

https://wiki.freepbx.org AND https://wiki.asterisk.org/wiki/display/AST/Home everything should be generally covered. Our “labels” are either exact or close (more human readable) versions of the exact settings. If there is ever any documentation lacking you have options:

  1. Ask here, perhaps something is not easily found or can be written/updated
  2. Submit a ticket at http://issues.freepbx.org requesting additional documentation
  3. Any given support option, including 2 community support options (here and IRC) which are Free.

There is no conspiracy we have thousands of pages of documentation. The Asterisk project has thousands of pages of documentation. Google has probably thousands more. Also the code is open source if you want to “see what it does” No one is hiding anything. There may be use cases we simply don’t cover but for 1000 users there can be 1000 use cases. Document yours for the next guy.

Furthermore @tdixon81 the ticket system is not a place to ask questions. It is a place to report bugs, submit improvements and add feature requests. Its not a place to go to for ‘support’ or to ask questions about how the product works. Especially when you asked relatively the same thing in this thread except accused Sangoma of trying to get $$$ because of a setting that has documentation copied over from Asterisk that you couldn’t understand.

I am submitting this ticket to request more information on all of the Asterisk SIP Settings. For instance - when you see 423 Interval too brief, “…,” minimum 3600 seconds - what is that and where is it coming from? What registry setting will do the trick?

A quick google search lead me to the RFC for the SIP protocol and specifically your error of 423 (https://tools.ietf.org/html/rfc3261#page-188)

The server is rejecting the request because the expiration time of
the resource refreshed by the request is too short. This response
can be used by a registrar to reject a registration whose Contact
header field expiration time was too small. The use of this response
and the related Min-Expires header field are described in Sections
10.2.8, 10.3, and 20.23.

To me the error is clear. The server doesn’t like what you are telling it you want the expiration to be. In fact the server is going as far as telling you it’s too short. Letting you know it needs to be increased.

If I follow this out and read section 20.23 I see

20.23 Min-Expires

   The Min-Expires header field conveys the minimum refresh interval
   supported for soft-state elements managed by that server.  This
   includes Contact header fields that are stored by a registrar.  The
   header field contains a decimal integer number of seconds from 0 to
   (2**32)-1.  The use of the header field in a 423 (Interval Too Brief)
   response is described in Sections 10.2.8, 10.3, and 21.4.17.

   Example:

      Min-Expires: 60

If anything I would blame your provider who has failed to tell you that this is a required setting for them (not for SIPStation, Voip.ms, SIP.Us… the list goes on). Although their server IS telling you about the misconfiguration with error code 423 and the Min-Expires header. However perhaps it’s your provider looking to get more $$$ through support. Or in reality it’s your provider who doesn’t want everyone to register to them every 60 seconds. Who knows why but you’d have to ask them. (Also note that the Min-Expires in the RFC is 60 as well)

In this RFC there are over 40 responses a server can reply back with and each response can mean something different in the context of a call. Writing a wiki to describe all outcomes of all responses of all RFC responses would get out of control and would be different for each server, provider… etc.

Furthermore you went and increased maxexpiry, minexpiry and defaultexpiry globally for all of your extensions when you should have just set these values on your trunks (in trunks). As now you will most-likely have registration issues with your phones.

FreePBX is a Unified Communications tool built on top of Asterisk. FreePBX’s goal is to not explain everything to you for every setting that exists in Asterisk and how that setting relates to the over 40 different RFC responses a server replies with.

https://issues.freepbx.org/browse/FREEPBX-15674

*Note: I work for Sangoma and I provided this response for free.

My apologies folks - didn’t know that I would stir up so much backlash. It was really a joke - hence my cheese conspiracy comment. I guess my snarky remark deserves a snarky reply

My frustration was that when I would google “423 interval too brief” everything but the registry came to the top. Heck - this thread is 3 years old. So I thought, as an alright community contributor, I would provide my perspective and the resolution to my problem for another newbie Asterisk/FreePBX self-proclaimed administrator.

Sorry folks. I’ll leave with my tail between my legs now.

1 Like

Hi,

Now that I know it’s a joke I understand what you were trying to do and say but it was not that apparent initially…

Your cheese in the burgers joke made me think you were even more :stuck_out_tongue_winking_eye: than I initially thought… :grin:

Like one of my very good friends once said writing is one of the best ways to misunderstand each other (I am paraphrasing). It’s already sometimes hard to understand what someone means when it is in writing it is even harder if it contains a joke or sarcasm…

Be very sure it’s very apparent you are not serious when you attempt to do this in writing and especially if it is about a subject that might be sensitive…

A pull request is a request you do against a repository like Github to have files you have modified committed in the main repository… This is one way of submitting code (or other type of files) to be included in the official version.

What I was suggesting you to do was for you to modify the help text in the PHP pages and submit back those pages for inclusion in FreePBX.

As for your question, the pull request is done against a repository (like Github) and depending on the project you might have to create a ticket as well to have it committed…

I could be wrong but from reading what you wrote it sounds to me like it is the error messages reported by Asterisk which should be improved with a possible reference to the appropriate RFC so that you know what settings you should play with, not the other way around…

Have a nice day,

Nick