Official Documentation for Asterisk 1.6 Realtime ODBC Tables

Home » Asterisk Users » Official Documentation for Asterisk 1.6 Realtime ODBC Tables
Asterisk Users 13 Comments

Hi All,

I’m having an issue where Asterisk continuously sends out a GAZILLION “SIP NOTIFY” messages when a user has a voice message in their INBOX. This issue is only present when my SIP users and peers are configured from my ODBC backend (MySQL). A static configuration of users in sip.conf resolves this and everything works fine.

I’d like to confirm the layout of the sip_users table in my MySQL database to make sure it’s what Asterisk is looking for. I cannot find any official documentation that specifies what the sip_users table should look like. Their documentation system does a great job of showing what the table should look like for the Voicemail ODBC storage, for example. But not for the Realtime sip_users table.

I’m currently using the table listed here:

Is there any official documentation on this?

Brett Woollum

13 thoughts on - Official Documentation for Asterisk 1.6 Realtime ODBC Tables

  • href=””>

    I agree with Paul, this sounds like a bugs that’s been fixed.

    What does the ‘Mailbox :’ line look like when you do a ‘sip show peers’?

    My guess is that there will be multiple entries of the same mailbox, and
    that’s why you’re receiving a bunch of NOTIFY messages.

    – Brad

  • Hi Paul, I’ll go ahead and update to and see how that works. I did see a couple bugs in the bug tracker for this, but they were resolved a while ago (I want to say 1.6.1 timeframe…). There was also a post on this list about the problem arising from LDAP integration, but I didn’t see any resolution posted.

    Brett Woollum


  • Hi Brad,

    I did notice that bug in the bug tracker. That’s different from the behavior I am seeing. I don’t get multiple values in the “Mailbox”. I just upgraded to and it’s still there.

    By the way, the quantity of SIP NOTIFY’s generated is significant. It appears to be way more that the number of peers I have (3) times a handful of duplicates per peer. I’ve been doing a Wireshark capture, and it appears as though any time there is a new message in the ODBC voicemail store for a mailbox that has been subscribed to, Asterisk continually generates as many of the messages as possible. At one point I noticed my CPU jump from 0% to ~50% just by moving one message from an mailbox that hadn’t been subscribed to to a mailbox that was subscribed to by the 3 peers. It only came back to ~0-1% by moving the message back to an unsubscribed user.

    When I set rtcachefriends = yes in sip.conf, I get the following for each peer:

    ast01*CLI> sip show peer 412

    * Name : 412
    Realtime peer: Yes, cached
    Secret :
    MD5Secret :
    Remote Secret:

    Context : sipphones
    Subscr.Cont. : blf_subscriptions
    Language : en
    AMA flags : Unknown
    Transfer mode: open
    CallingPres : Presentation Allowed, Not Screened
    Callgroup :
    Pickupgroup :
    Mailbox : vm_bob@default
    VM Extension : asterisk
    LastMsgsSent : 32767/65535
    Call limit : 0
    Dynamic : Yes
    Callerid : “” <>
    MaxCallBR : 384 kbps
    Expire : 69
    Insecure : no
    Nat : RFC3581
    ACL : No
    T.38 support : No
    T.38 EC mode : Unknown
    T.38 MaxDtgrm: -1
    DirectMedia : Yes
    PromiscRedir : No
    User=Phone : No
    Video Support: No
    Text Support : No
    Ign SDP ver : No
    Trust RPID : No
    Send RPID : No
    Subscriptions: Yes
    Overlap dial : Yes
    Forward Loop : Yes
    DTMFmode : rfc2833
    Timer T1 : 500
    Timer B : 32000
    ToHost :
    Addr->IP : Port 5064
    Defaddr->IP : Port 5060
    Prim.Transp. : UDP
    Allowed.Trsp : UDP
    Def. Username: 412
    SIP Options : (none)
    Codecs : 0x1004 (ulaw|g722)
    Codec Order : (g722:20,ulaw:20)
    Auto-Framing : No
    100 on REG : Yes
    Status : Unmonitored
    Useragent : Yealink SIP-T28P
    Reg. Contact : sip:412@
    Qualify Freq : 120000 ms
    Sess-Timers : Accept
    Sess-Refresh : uas
    Sess-Expires : 1800 secs
    Min-Sess : 90 secs
    Parkinglot :

    This is Asterisk using the ODBC store for voicemail and ODBC for sip_peers.

    Brett Woollum


  • More information: When I have “rtcachefriends = yes” in sip.conf, everything seems fine. With “rtcachefriends = no” I see this behavior.

    I’d rather not cache. I’m aiming for as near real-time as possible.

    Any thoughts?

    Brett Woollum


  • href=””>

    That’s the problem, you’ve got rtcache friends turned off. If full
    realtime is that important, modify whatever scripts you have that make
    updates to your sip accounts to run “asterisk -rx ‘sip prune realtime
    peer PEERNAME’ ” and then “asterisk -rx ‘sip show peer PEERNAME load’
    ” after it makes the update to the sip table. That clears Asterisk’s
    cache for the modified sip peer and then loads the information from
    the database. Technically, I believe you might be able to get away
    with not clearing the cached info, but I’ve always played it safe.

    Sherwood McGowan
    A LOOOOONG Time user of all things Asterisk Realtime

  • On Fri, Nov 12, 2010 at 9:36 AM, Sherwood McGowan

    oooh, also, I saw a blf subscription in there. Have you performed a
    capture of the sip signaling between asterisk and the peer(s) in
    question? If you haven’t, you might want to do that, and investigate
    the contents of the notify message. Just a troubleshooting thought 😀


  • Hi Sherwood,

    Thanks for the reply. That’s interesting to me. What is the point of rtcachefriends = no if it causes weird things like this to happen?

    As mentioned, I’d like to stay real-time and fully database driven for everything. Not only does it make life easier in terms of changing settings on the system (without reloads!), but it will make scaling the system to more Asterisk servers much easier. Is there a way for Asterisk to automatically look up the sip user or peer’s information from the ODBC backend every time and work properly? It seems to be doing that with rtcachefriends = no, with the exception of the MWI subsystem. How can I retain the database driven behavior of rtcachefriends = yes, but still keep the MWI working?

    Also, the BLF subscriptions and subsequent NOTIFY’s are working fine. A capture of the wire by the phone shows the only issue as being the NOTIFY’s for MWI.


    Brett Woollum


  • Inline response 😀

    Most definitely mate, since I’ve used realtime so much, I enjoy
    digging in there. However, I use the MySQL realtime architecture, so
    forgive me if we find there’s differences between the ODBC
    architecture’s behavior and what I believe it should be 🙂

    The long and short of it is, IIRC, MWI did not work with realtime
    until they added the realtime cache functionality. So, when you turn
    it off, it goes back to the “good old days” of 2005, when Realtime was
    still experimental. Well, not really, you just have weirdness with
    notification packets, in ’05 the realtime engine would just randomly
    crash asterisk…that made my life hell, seeing as how I had built a
    certain ITSP’s system with the experimental realtime because they
    insisted 😛

    Trust me, I’m pickin’ up what you’re putting down mate.

    Well, you can do one of two things, I reckon:

    1) Submit a bug report about the excess of notify messages and whatnot
    and work with whoever picks up the ticket as much as possible. I did
    that with Murf concerning improving AEL AND rectifying the macro
    iteration depth issue (I was the poor bastard that discovered it, in
    the middle of a 3 month long development of a LARGE
    wholesale/reseller/ITSP project)…


    2) Learn C (if you don’t already know it), and take a crack at the
    code yourself.

    There’s a couple others, but those two are the sure fire methods 😉

    Right on, I kinda figured as soon as you mentioned rtcachefriends.
    We’re basically stuck at “The RealTime engine has had this issue since
    2005/2006, and there’s been no massive complaints about this”… I
    don’t like it, I’d personally like MWI to work without caching, or
    maybe only caching a LITTLE bit of data.

    One other quick note though, there’s a good reason to not be
    COMPLETELY realtime with your SIP or IAX clients’
    configurations…That would mean that Asterisk would have to query the
    database for EVERY realtime client configuration every time it needs
    to do a MWI check, which is probably why it would crash back in the
    days of me getting 1-2 hours sleep in 24-48 hours constantly…

    Sorry I can’t do anything more than explain what I know, but I’ve
    never delved into it because even in my clustering/HA setups, I’ve
    just dealt with doing the prune and loads. Keep in mind, the prune and
    load method only performs the action on THE SPECIFIC CLIENT you
    request it for, it’s not a sip reload 😀

    Slainte Mate!

  • Yeah a production system that crashes is not fun.. I hear you there.

    Maybe the solution will be to design some sort of method for each asterisk server to auto prune and load as necessary. The first issue that is coming to mind is that I’m doing configuration and db changes/updates on a different server than asterisk. This would mean my web server would need to reach out to each asterisk server to tell it to update. This will be interesting.

    I think I will try opening a bug ticket. I think a stable database backend for Asterisk is critical for easy integration with other systems and scaling the platform. Fixing MWI is just a stepping stone. As far as I can tell the rest of the Realtime architecture I’ve implemented works fine. Unfortunately I’m not a C coder. I never could get used to it. I actually tried to run through the code last night to see what I could find, but I didn’t understand much. I was able to find some of the MWI notify functions (in and for example), but nothing stood out to me. I would like to work with whomever I can to try resolving this.

    Hopefully we can figure it out and get MWI working with rtcachefriends = “no” (or maybe “a little” hahaha)!

    Brett Woollum

    Sent from my iPhone


  • href=””>

    Sounds good mate, keep me posted, and let me know the issue number so
    I can check in on it 😀 Who knows, I might be able to offer some
    testing or somethin’ for the digium guys or something