Upgraded To 13 And Now “Mailbox” Is Empty In Sip Show Peers

Home » Asterisk Users » Upgraded To 13 And Now “Mailbox” Is Empty In Sip Show Peers
Asterisk Users 15 Comments

Using realtime for SIP. Using standard DB schema. Tried mailbox as varchar(50) and bigint(10)
“sip show peer XXX” shows “Mailbox: ” (empty)
So MWI isn’t working This happened before when we tried to go up to 1.8, so we stayed at 1.4
We’re forced to go to 13 now. Obviously a lack of MWI is a big issue for
500 units.

Any idea why we’re not getting it?
We’re tried filling it into MySQL like “xxx@context” or just “xxx”
No matter what, it doesn’t work.

Or maybe some how to debug/diagnose this?

Thanks!

15 thoughts on - Upgraded To 13 And Now “Mailbox” Is Empty In Sip Show Peers

  • The “mailbox” column in a database schema should be varchar, and big enough to hold a fully qualified mailbox name.

    Per the CHANGES notes, you must now fully qualify a mailbox:

    * Mailboxes defined by app_voicemail MUST be referenced by the rest of the
    system as mailbox@context. The rest of the system cannot add @default
    to mailbox identifiers for app_voicemail that do not specify a context
    any longer. It is a mailbox identifier format that should only be
    interpreted by app_voicemail.

    So, if using app_voicemail, your mailboxes should always be
    ‘xxx@vm_context’ where appropriate. I don’t think this is your problem however.

    Are the rest of the fields in your peers being extracted correctly?
    Can you provide the output from your database for one of your peers?
    Which realtime backend are you using?

  • It was originally varchar(50) and contained mailbox@context — but that didn’t work, so we tried changing it to bigint(10). It’s been changed back and does contain varchar(50) with mailbox@context now.

    Everything else seems to be working properly, yes.

    Here’s one entry from our realtime table (MySQL):

    INSERT IGNORE INTO “ (`id`, `name`, `username`, `secret`, `callerid`, `context`,
    `mailbox`, `mwi`, `host`, `setvar`, `nat`, `type`, `accountcode`,
    `amaflags`, `call-limit`, `callgroup`, `cancallforward`, `canreinvite`,
    `defaultip`, `dtmfmode`, `fromuser`, `fromdomain`, `insecure`, `language`,
    `md5secret`, `deny`, `permit`, `mask`, `musiconhold`, `pickupgroup`,
    `qualify`, `regexten`, `restrictcid`, `rtpholdtimeout`, `rtptimeout`,
    `disallow`, `allow`, `parkinglot`, `fullcontact`, `ipaddr`, `port`,
    `regserver`, `regseconds`, `lastms`, `defaultuser`, `subscribecontext`,
    `useragent`, `limitonpeers`) VALUES (96, ‘7191111111’, ‘7191111111’,
    ‘000000000000000000000000’, NULL, ‘outbound’, ‘7191111111@default’, NULL,
    ‘dynamic’, NULL, ‘yes’, ‘friend’, NULL, NULL, 2, NULL, ‘yes’, ‘no’, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, ‘all’, ‘ulaw’, NULL, ‘
    sip:7191111111@10.105.14.7:5060’, ‘10.105.14.7’, 5060, NULL, 1416407370, 6,
    ‘7196868170’, NULL, ‘Linksys/SPA2102-5.2.10’, NULL);

    And then what “sip show peer 7191111111” shows:

    *CLI> sip show peer 7196868100

    * Name : 7191111111
    Description :
    Realtime peer: Yes, cached
    Secret :
    MD5Secret :
    Remote Secret:

    Context : outbound
    Record

  • This same issue has happened on 1.8 as well. And so far on all 6 of our systems we upgraded to 13. It must be something simple? How can we diagnose it?

  • As the MySQL DB is on the same servers as the Asterisk software, I’m afraid a tcpdump won’t show much. We have looked at the SQL traffic and all we see is the usual “SELECT * FROM sip_buddies WHERE…” — well that doesn’t do much good, as we know the “mailbox” column is being returned properly during a SQL SELECT.

    It seems like Asterisk is just throwing that field away. But not always. Sometimes after a sip reload a few SIP registrations will have the Mailbox field populated.

    Looking at debug in Asterisk doesn’t show anything other than that Asterisk found the SQL fields (including “mailbox”) and what SQL SELECT statements it’s running.

    This just seems so simple! Has to be something we have contextually wrong somewhere or something. Thanks for the help.

  • ********** THIS IS NOT WHERE YOUR REPLY BELONGS **********

    First try this;

    mysql> SHOW VARIABLES LIKE “general_log%” ;
    +——————+—————————+
    | Variable_name | Value |
    +——————+—————————+
    | general_log | OFF |
    | general_log_file | /var/lib/mysql/debian.log |
    +——————+—————————+
    2 rows in set (0.00 sec)

    Note the value for “general_log_file”. Now enter

    mysql> SET GLOBAL general_log = 1;

    Exit out of mysql (if you’re not using screen, or multiple tabs in your terminal emulator) and run

    $ tail -fn0 /var/lib/mysql/debian.log

    (or whatever the log file is called). Now you will get every SQL query executed on the server scroling past, and you might get a clue from this what might be the matter.

  • Well we’ve ruled out that this is in anyway MySQL or even res_config_mysql related.

    This morning our guys wrote a backend for res_config_curl to return static information (in no way touching anything SQL at all).

    Still we are getting intermittent “Mailbox” results in a “sip show peer”. Sometimes it’s there for some endpoints. Sometimes it’s not. Sometimes it’ll show up (or disappear) after the endpoint’s registry expires. Or if we do a “sip reload” it’ll come and go.

    Since we’ve totally ruled out this being at all a problem with MySQL that helps somewhat (I guess?).

    Could this in any way be related to the endpoint themselves? All Linksys/Sipura stuff. I wouldn’t think so, but maybe the endpoint’s are all misconfigured? Or could it be a setting in sip.conf that is incorrect? Here’s the total of the sip.conf (again since we’re using realtime it’s mostly empty).

    Or maybe this is something in the realtime engine? Is there something
    “realtime” shared between mysql and curl?

    Thanks for help!!

    sip.conf:
    [general]
    progressinband=never rtcachefriends=yes rtupdate=yes ignoreregexpire=yes checkmwi`
    trustrpid=yes sendrpid=yes sendrpid=rpid rpid_update=yes shrinkcallerid=no t38pt_udptl=yes,redundancy,maxdatagram@0
    vmexten=*98
    canreinvite=no qualify=yes tos_sip=cs3
    tos_audio

  • ********** THIS IS NOT WHERE YOUR REPLY BELONGS **********

    Which part of “THIS IS NOT WHERE YOUR REPLY BELONGS” do you not understand?

  • ********** THIS IS NOT WHERE YOUR REPLY BELONGS **********

    You are supposed to reply *after* the thing you are replying to. Like this.
    So the conversation flows neatly.

  • I doubt the person cares, if you don’t like people top posting then stop reading their messages. If someone top posts, nothing you do will make them stop top posting. Complaining about something you cannot change just wastes everyone’s time. I have a rule which deletes messages with “top post” in them so I don’t usually see these silly messages.

    —–Original Message—

  • Mailbox continues to be missing most times. Touching (or rm’ing) the file in /var/spool/asterisk/voicemail does nothing until a “core restart now”
    then as soon as the phone registers the light is sync’ed. MySQL or CURL, doesn’t matter, anything realtime. Seems so odd to have this issue on 6
    installations, 3 different versions, and nobody knows. We’ve even stripped it down barebones, loading only about 7 modules and clean config files.

  • Eric Wieling wrote:
    Some might even say that the constant complaining about top posting, expecting different results, is a definition of insanity!

    Some of the same folks who constantly complain about top posting will leave many many footers from the list in place, which makes the “neatly flowing conversation” nearly impossible.

    Peg Leg O’Brien

  • It’s not clear from your descriptions; but if you have at least one machine where it’s working properly, then you need to work out what is different between that “working” and your “non-working” installations.

    The fact of it not responding to realtime changes certainly suggests a misconfiguration somewhere; one or more modules is not expecting things to change, and so picking up on it when they do. So the question now becomes:
    What is the minimum you need to do, to persuade your Asterisk to accept the new configuration?

    “core restart now” is a pretty big sledgehammer to be using to crack the nut of a configuration file not being reread. Try “core reload” or even “voicemail reload”. And then once you’ve found the module whose config you need to reload explicitly, that is where the misconfiguration most probably resides.