[asterisk-users] Official Documentation for Asterisk 1.6 Realtime ODBC Tables
Brett Woollum
brett at woollum.com
Fri Nov 12 13:46:30 CST 2010
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 chan_sip.so and events.so 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
On Nov 12, 2010, at 11:17 AM, Sherwood McGowan <sherwood.mcgowan at gmail.com> wrote:
> Inline response :D
>
> On Fri, Nov 12, 2010 at 12:54 PM, Brett Woollum <brett at woollum.com> wrote:
>> Hi Sherwood,
>>
>> Thanks for the reply.
>
> 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 :)
>
>> That's interesting to me. What is the point of
>> rtcachefriends = no if it causes weird things like this to happen?
>
> 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 :P
>
>> 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.
>
> Trust me, I'm pickin' up what you're putting down mate.
>
>> 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?
>
> 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)...
>
> OR
>
> 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 ;-)
>
>> 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.
>
> 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 :D
>
> Slainte Mate!
> Sherwood
>>
>> Thanks!
>>
>> Brett Woollum
>> Brett at Woollum.com
>>
>>
>> ----- Original Message -----
>> From: "Sherwood McGowan" <sherwood.mcgowan at gmail.com>
>> To: "Asterisk Users Mailing List - Non-Commercial Discussion"
>> <asterisk-users at lists.digium.com>
>> Sent: Friday, November 12, 2010 7:36:22 AM GMT -08:00 US/Canada Pacific
>> Subject: Re: [asterisk-users] Official Documentation for Asterisk 1.6
>> Realtime ODBC Tables
>>
>> On Fri, Nov 12, 2010 at 7:52 AM, Brett Woollum <brett at woollum.com> wrote:
>>> 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
>>> Brett at Woollum.com
>>>
>>>
>>> ----- Original Message -----
>>> From: "Brett Woollum" <brett at woollum.com>
>>> To: "Asterisk Users Mailing List - Non-Commercial Discussion"
>>> <asterisk-users at lists.digium.com>
>>> Sent: Friday, November 12, 2010 5:34:03 AM GMT -08:00 US/Canada Pacific
>>> Subject: Re: [asterisk-users] Official Documentation for Asterisk 1.6
>>> Realtime ODBC Tables
>>>
>>> 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 1.6.2.14 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 : <Set>
>>> MD5Secret : <Not set>
>>> Remote Secret: <Not set>
>>> Context : sipphones
>>> Subscr.Cont. : blf_subscriptions
>>> Language : en
>>> AMA flags : Unknown
>>> Transfer mode: open
>>> CallingPres : Presentation Allowed, Not Screened
>>> Callgroup :
>>> Pickupgroup :
>>> Mailbox : vm_bob at 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 : 10.20.1.225 Port 5064
>>> Defaddr->IP : 0.0.0.0 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 2.50.0.52
>>> Reg. Contact : sip:412 at 10.20.1.225:5064
>>> Qualify Freq : 120000 ms
>>> Sess-Timers : Accept
>>> Sess-Refresh : uas
>>> Sess-Expires : 1800 secs
>>> Min-Sess : 90 secs
>>> Parkinglot :
>>>
>>> This is Asterisk 1.6.2.14 using the ODBC store for voicemail and ODBC for
>>> sip_peers.
>>>
>>> Brett Woollum
>>> Brett at Woollum.com
>>>
>>>
>>> ----- Original Message -----
>>> From: "Bradley Watkins" <Bradley.Watkins at compuware.com>
>>> To: "Asterisk Users Mailing List - Non-Commercial Discussion"
>>> <asterisk-users at lists.digium.com>
>>> Sent: Friday, November 12, 2010 5:14:49 AM GMT -08:00 US/Canada Pacific
>>> Subject: Re: [asterisk-users] Official Documentation for Asterisk 1.6
>>> Realtime ODBC Tables
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: asterisk-users-bounces at lists.digium.com
>>>> [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of
>>>> Paul Belanger
>>>> Sent: Friday, November 12, 2010 7:58 AM
>>>> To: Asterisk Users Mailing List - Non-Commercial Discussion
>>>> Subject: Re: [asterisk-users] Official Documentation for
>>>> Asterisk 1.6 Realtime ODBC Tables
>>>>
>>>> On Fri, Nov 12, 2010 at 6:07 AM, Brett Woollum
>>>> <brett at woollum.com> wrote:
>>>>> 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.
>>>>>
>>>> What version of 1.6? I _think_ this may have been a bug, that
>>>> was fixed.
>>>>
>>>> Don't hold me to that.
>>>
>>> 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
>>>
>>> --
>>> _____________________________________________________________________
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>>> http://www.asterisk.org/hello
>>>
>>> asterisk-users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>> http://lists.digium.com/mailman/listinfo/asterisk-users
>>>
>>> -- _____________________________________________________________________
>>> --
>>> Bandwidth and Colocation Provided by http://www.api-digital.com -- New to
>>> Asterisk? Join us for a live introductory webinar every Thurs:
>>> http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE
>>> or
>>> update options visit:
>>> http://lists.digium.com/mailman/listinfo/asterisk-users
>>> --
>>> _____________________________________________________________________
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>>> http://www.asterisk.org/hello
>>>
>>> asterisk-users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>> http://lists.digium.com/mailman/listinfo/asterisk-users
>>>
>>
>> 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.
>>
>> Cheers,
>> Sherwood McGowan
>> A LOOOOONG Time user of all things Asterisk Realtime
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>> http://www.asterisk.org/hello
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-users
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>> http://www.asterisk.org/hello
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
> http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
More information about the asterisk-users
mailing list