Skip to main content

Upgrade to 6.1.1.5 and 1.6.2.13

Posted by owenc on Mon, 09/20/2010

Last week we upgraded from 6.0.1.81 to 6.1.1.5 in preparation for upgrade to 1.6.2.13 which we did over the weekend.

We thought all had gone well but today we are seeing problems with voicemail not working after a transfer.

For example of someone calls into the main number and transfers a call to an extension all is well unless that extension doesn't answer. When the call goes to voicemail I get the following in the logs:

-- Playing '/var/spool/asterisk/voicemail/default-hubris/201/unavail.gsm' (language 'en')

However, nothing ever plays and the call just "hangs". The caller stays on the call but nothing ever happens on the asterisk side of things.

If on the other hand I call into an IVR and choose to dial an extension everything works as expected and I get a very similar line in the logs:

-- Playing '/var/spool/asterisk/voicemail/default-hubris/201/unavail.gsm' (language 'en')

The only difference seems to be that the successful voicemail entry is via SIP/ and the unsuccessful one is via Local/

This sure looks like a config issue but I'm not sure where to start. Below is the full section of the two log entries.

We seem to be having similar issues with parking calls.

Unsuccessful:

-- Executing [s@macro-tl-userexten-base:164] Goto("Local/101@from-inside-hubris-dc23;2", "s-orig-NOANSWER,1") in new stack
-- Goto (macro-tl-userexten-base,s-orig-NOANSWER,1)
-- Executing [s-orig-NOANSWER@macro-tl-userexten-base:1] Goto("Local/101@from-inside-hubris-dc23;2", "s-NA,1") in new stack
-- Goto (macro-tl-userexten-base,s-NA,1)
-- Executing [s-NA@macro-tl-userexten-base:1] GotoIf("Local/101@from-inside-hubris-dc23;2", "0?s-exit,1") in new stack
-- Executing [s-NA@macro-tl-userexten-base:2] GotoIf("Local/101@from-inside-hubris-dc23;2", "1?s-NA-VOICEMAIL,1") in new stack
-- Goto (macro-tl-userexten-base,s-NA-VOICEMAIL,1)
-- Executing [s-NA-VOICEMAIL@macro-tl-userexten-base:1] Answer("Local/101@from-inside-hubris-dc23;2", "") in new stack
-- Executing [s-NA-VOICEMAIL@macro-tl-userexten-base:2] Wait("Local/101@from-inside-hubris-dc23;2", "2") in new stack
-- Executing [s-NA-VOICEMAIL@macro-tl-userexten-base:3] GotoIf("Local/101@from-inside-hubris-dc23;2", "0?ringing") in new stack
-- Executing [s-NA-VOICEMAIL@macro-tl-userexten-base:4] GotoIf("Local/101@from-inside-hubris-dc23;2", "0?ringing") in new stack
-- Executing [s-NA-VOICEMAIL@macro-tl-userexten-base:5] VoiceMail("Local/101@from-inside-hubris-dc23;2", "201@default-hubris,u") in new stack
-- Playing '/var/spool/asterisk/voicemail/default-hubris/201/unavail.gsm' (language 'en')

Successful:

-- Executing [s@macro-tl-userexten-base:164] Goto("SIP/SIP_TRUNK_DENVER-00000b72", "s-orig-NOANSWER,1") in new stack
-- Goto (macro-tl-userexten-base,s-orig-NOANSWER,1)
-- Executing [s-orig-NOANSWER@macro-tl-userexten-base:1] Goto("SIP/SIP_TRUNK_DENVER-00000b72", "s-NA,1") in new stack
-- Goto (macro-tl-userexten-base,s-NA,1)
-- Executing [s-NA@macro-tl-userexten-base:1] GotoIf("SIP/SIP_TRUNK_DENVER-00000b72", "0?s-exit,1") in new stack
-- Executing [s-NA@macro-tl-userexten-base:2] GotoIf("SIP/SIP_TRUNK_DENVER-00000b72", "1?s-NA-VOICEMAIL,1") in new stack
-- Goto (macro-tl-userexten-base,s-NA-VOICEMAIL,1)
-- Executing [s-NA-VOICEMAIL@macro-tl-userexten-base:1] Answer("SIP/SIP_TRUNK_DENVER-00000b72", "") in new stack
-- Executing [s-NA-VOICEMAIL@macro-tl-userexten-base:2] Wait("SIP/SIP_TRUNK_DENVER-00000b72", "2") in new stack
-- Executing [s-NA-VOICEMAIL@macro-tl-userexten-base:3] GotoIf("SIP/SIP_TRUNK_DENVER-00000b72", "0?ringing") in new stack
-- Executing [s-NA-VOICEMAIL@macro-tl-userexten-base:4] GotoIf("SIP/SIP_TRUNK_DENVER-00000b72", "0?ringing") in new stack
-- Executing [s-NA-VOICEMAIL@macro-tl-userexten-base:5] VoiceMail("SIP/SIP_TRUNK_DENVER-00000b72", "201@default-hubris,u") in new stack
-- Playing '/var/spool/asterisk/voicemail/default-hubris/201/unavail.gsm' (language 'en')

Any ideas?

Chris


Submitted by owenc on Mon, 09/20/2010 Permalink

BTW, is there something necessary to let PBX Manager know the upgrade to 1.6.2 happened? I ask because I still don't see any parking stuff anywhere in the GUI. If I updated last week and was still using 1.6.1 do I need to do anything now that we're at 1.6.2

Submitted by thirdlane on Tue, 09/21/2010 Permalink

Yes, you do need to put multiparking=1 in the features.txt file in the /etc/asterisk directory.

This file is used to determine baseline features of asterisk and thirdlane installation that the GUI is expected to support. Currently these are: multiparking=1 or 0 depending on an installed version of Asterisk (1 for 1.6.2) and conferenceprefix=1 that is simply set for the new installations to let the GUI know that a new meetme conference naming scheme can be used - more will be likely added in the future. The file keeps a baseline of features at the time of installation and gets created during fresh install. Not to be confused with features.conf Asterisk configuration file :). I guess we should have picked a different name.

Submitted by thirdlane on Tue, 09/21/2010 Permalink

I know there were changes to the Asterisk Local channels but these look too problematic. Please let me know if you'll find something, we'll try to do some testing as well

Submitted by owenc on Tue, 09/21/2010 Permalink

Any way this could be made to work with 1.6.1.x? As I've noted elsewhere we are using mutli-tenant parking with 1.6.1.x and the new version the module eats all those settings any time we touch an extension.

The module seems to recognize our parking config but then ignores it so it doesn't show up in other settings.

Submitted by owenc on Tue, 09/21/2010 Permalink

We had to give up on 1.6.2.x (obviously) but we've got a full testing environment set up with 1.6.2 if you need anything. Its a backup/testing box only so we can really do any testing on it. Can't run Thirdlane on it but all the settings are the same.

Submitted by owenc on Tue, 09/21/2010 Permalink

BTW, last night when we downgraded to 1.6.1.x there were probably 20 calls in this "hung" state. Most of those were parked calls for one tenant but all those calls were 6+ hours in duration. asterisk wouldn't even shutdown because of them.

Submitted by owenc on Mon, 12/20/2010 Permalink

We finally got back to this and are still seeing the same errors with both 1.6.2.x and 1.8.1.1.

All our configs had the multi-tenant parking stuff added manually because we are using 1.6.1.x on our production box but I've set up a new Thirdlane install using the ISO and confirmed that all our configs follow the same exact syntax and what a new Thirdlane install on 1.6.2.x does.

Figured out what the issue is though. Calls aren't being parked in the right parking lot. We've got a tenant named "test" and when I go to park a call on one of the extensions I get the following:

[Dec 20 16:28:59] VERBOSE[4440] features.c: == Parked SIP/102-test-00000066 on 701 (lot parkinglot_fitts). Will timeout back to extension [from-inside-redir-test] s, 1 in 120 seconds

"fitts" is the name of another tenant.

features.conf looks like:

[parkinglot_fitts]
context => parkedcalls-fitts
parkingtime => 120
parkext => 700
parkpos => 701-710
findslot => next

[snip other tenants out]

[parkinglot_test]
context => parkedcalls-test
parkingtime => 120
parkext => 700
parkpos => 701-710
findslot => next

extensions.include looks like:

[from-inside-redir-test]
include => local-extensions-test
include => feature-extensions-test
include => outgoing-emergency-test
include => outgoing-unrestricted-test
include => outgoing-test
include => parkedcalls-test
exten => t,1,Hangup
exten => h,1,Hangup
exten => i,1,Playback(invalid)
exten => i,n,Hangup

[from-inside-restricted-redir-test] - same

sip.conf looks like:

[101-test]
qualify=2000
nat=yes
callerid=Test Tenant <101>
context=from-inside-test
call-limit=99
canreinvite=no
vmexten=101
parkinglot=parkinglot_test
secret=xxxxxxxxx

"feature show" looks good:

voice2*CLI> features show
Builtin Feature Default Current
--------------- ------- -------
Pickup *8 **
Blind Transfer # ##
Attended Transfer #*
One Touch Monitor #9
Disconnect Call * #0
Park Call
One Touch MixMonitor

Dynamic Feature Default Current
--------------- ------- -------
(none)

Feature Groups:
---------------
(none)

Call parking (Parking lot: parkinglot_fitts)
------------
Parking extension : 700
Parking context : parkedcalls-fitts
Parked call extensions: 701-710
Parkingtime : 120000
MusicOnHold class :

[snip other tenants]

Call parking (Parking lot: parkinglot_test)
------------
Parking extension : 700
Parking context : parkedcalls-test
Parked call extensions: 701-710
Parkingtime : 120000
MusicOnHold class :

(note that parkinglot_fitts is listed first out of all tenants, not sure why)

"show peer" looks good too:

voice2*CLI> sip show peer 101-test

* Name : 101-test
Secret :
MD5Secret :
Remote Secret:
Context : from-inside-test
Subscr.Cont. : local-extensions-test
Language :
AMA flags : Unknown
Transfer mode: open
CallingPres : Presentation Allowed, Not Screened
Callgroup :
Pickupgroup :
MOH Suggest :
Mailbox : 101@default-test
VM Extension : 101
LastMsgsSent : 32767/65535
Call limit : 99
Max forwards : 0
Dynamic : Yes
Callerid : "Test Tenant" <101>
MaxCallBR : 384 kbps
Expire : 1598
Insecure : no
Force rport : Yes
ACL : No
DirectMedACL : No
T.38 support : Yes
T.38 EC mode : FEC
T.38 MaxDtgrm: -1
DirectMedia : No
PromiscRedir : No
User=Phone : No
Video Support: Yes
Text Support : No
Ign SDP ver : No
Trust RPID : No
Send RPID : No
Subscriptions: Yes
Overlap dial : Yes
DTMFmode : rfc2833
Timer T1 : 500
Timer B : 32000
ToHost :
Addr->IP : 10.211.0.42:5060
Defaddr->IP : (null)
Prim.Transp. : UDP
Allowed.Trsp : UDP
Def. Username: 101-test
SIP Options : (none)
Codecs : 0x106 (gsm|ulaw|g729)
Codec Order : (g729:20,ulaw:20,gsm:20)
Auto-Framing : No
100 on REG : No
Status : OK (34 ms)
Useragent : Aastra 55i/2.6.0.1008
Reg. Contact : sip:101-test@10.211.0.42:5060;transport=udp
Qualify Freq : 60000 ms
Sess-Timers : Accept
Sess-Refresh : uas
Sess-Expires : 1800 secs
Min-Sess : 90 secs
RTP Engine : asterisk
Parkinglot : parkinglot_test
Use Reason : No
Encryption : No

Yet if I do a park from one the test tenants I always get:

[Dec 20 16:50:33] VERBOSE[4524] features.c: == Parked SIP/101-test-0000006f on 701 (lot parkinglot_fitts). Will timeout back to extension [from-inside-redir-test] s, 1 in 120 seconds

Not sure how things are ending up in the wrong context.

Submitted by eeman on Tue, 12/21/2010 Permalink

I do not experience this with 1.6.2.14, I recently upgraded from 1.4 to 1.6.2 and the tenants I converted manually plus the 3 new tenants all show up. When parking a call I confirm it arrives in the correct lot.

Submitted by owenc on Tue, 12/21/2010 Permalink

I'll look into MOH but the hold music does work just fine.

What happens is that when you park someone there isn't any way to unpark them (since they are parked in the wrong context). The person who is parked though hears the hold music as normal. After 120 second timeout the person parked does ring back and all is well. So really parking is working totally normally, it is just that they aren't in the right context.

One other issue that we are having that may or may not be related is that blind transfers don't work. Doing an attended transfer works just fine but with a blind transfer the calls is hung up as soon as the sender hangs up the phone. I've not really looked into that closely because I figured the parking issue might be easier and we might get lucky and they are related.

Submitted by owenc on Tue, 12/21/2010 Permalink

That bug appears to be related to DAHDI. This is all 100% SIP.

Also MOH actually works fine when the person is parked.

Submitted by eeman on Tue, 12/21/2010 Permalink

i had the blind transfer bug in 1.6.2.15-rc1 and had to back-up to 1.6.2.14 .. not sure which branch you are running but try rolling back to 1.6.2.14 or 1.8.0 and see if that fixes your blind transfer issue.

FWIW I cant use 1.8.x branch yet due to the new use of UPDATE sip messages. Its going to force me to upgrade all my customers running older versions of siproxd (transfers crashes the damn proxies on older versions).

Submitted by owenc on Tue, 12/21/2010 Permalink

We may have had the problem with 1.6.2.13 but I can't be sure as we backed off pretty quick on it. We've been testing with 1.8.1.1 though and that is where we are seeing both the blind transfer and parking issue. Parking issue was the same as 1.6.2.13.

Submitted by eeman on Tue, 12/21/2010 Permalink

you do understand what the dahdi timing source is for right? you can't play MOH or voicemail, IVR greetings or conference rooms without it.. SIP or no SIP in order to bridge to a media file, it has to be sampled out with the correct timing ticks. This is where the dahdi dummy drivers come into play. I had to noload the dahdi timing source and change to pthread to get MOH to work atleast till the patch goes through.

Submitted by owenc on Tue, 12/21/2010 Permalink

Well I can look at that but MOH works perfectly. As soon as the person is parked they hear hold music like they should. It continues to play just fine until they time out of parking.

It works other places fine too.

Submitted by xxot on Fri, 06/29/2012 Permalink

Hello, All.
We run into a weird problem with the parked calls on a multi-tenant version. Overall it seems working - you may park a call, MOH is played and you even can dial the parking slot and take the call back. But sometimes, for some reason, MOH for parked calls stops playing, especially, when the call bounced back by timeout and it was parked again. The customer thinks that call is hung and hangup. One time in the logs ("parkedcalls show") I've seen negative value for the parking time and this call never was returned back. Also, there are strange ZOMBIE channels in the logs, when I park a call. Does anybody faced such problem? Asterisk version 1.6.2.11. PBX Manager 6.1.1.6