On Fri, Nov 12, 2010 at 1:46 PM, Brett Woollum <[email protected]> wrote:
> 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 <[email protected]> 
> wrote:
>
>> Inline response :D
>>
>> On Fri, Nov 12, 2010 at 12:54 PM, Brett Woollum <[email protected]> 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
>>> [email protected]
>>>
>>>
>>> ----- Original Message -----
>>> From: "Sherwood McGowan" <[email protected]>
>>> To: "Asterisk Users Mailing List - Non-Commercial Discussion"
>>> <[email protected]>
>>> 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 <[email protected]> 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
>>>> [email protected]
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Brett Woollum" <[email protected]>
>>>> To: "Asterisk Users Mailing List - Non-Commercial Discussion"
>>>> <[email protected]>
>>>> 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_...@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:[email protected]: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
>>>> [email protected]
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Bradley Watkins" <[email protected]>
>>>> To: "Asterisk Users Mailing List - Non-Commercial Discussion"
>>>> <[email protected]>
>>>> 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: [email protected]
>>>>> [mailto:[email protected]] 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
>>>>> <[email protected]> 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
>
> --
> _____________________________________________________________________
> -- 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
>

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

-- 
_____________________________________________________________________
-- 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

Reply via email to