Hi Ryan,

Thanks for the response. The config of the blast group and extensions was done via CCA which doesn't allow the CFNA timeout for the blast group members to be less than the blast group timeout. I have double-checked this though and all members are 45 seconds and the blast group is 15 seconds.

I will need to test your second option tomorrow. I think that your statement at the end is the crux of the problem. When looking at debugs there is no invite to VM for the call at all - the call is disconnected for no obvious reason. VM does work fine internally though.

Damian

Damian,

It looks like the call is getting to the UC500, and I can see it trying to ring extensions: 201, 202, 203, 204...   Are those the only extensions configured in your blast group?

After it tries to ring those extensions, we get the message below..   Seems that it may be trying to ring another extension that does not exist, or one of the extensions has been configured to forward the call, but it is failing.

937135: Apr 29 15:38:56.212: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 110.173.232.162:5060;branch=z9hG4bK47f25179;rport
From: "0390240631" <0390240631>;tag=as0a98819d
To: <0394281062>;tag=45367874-164
Date: Fri, 29 Apr 2011 05:38:53 GMT
Call-ID: 45f53a9838222d6f4ccaaae176164566@110.173.232.162
CSeq: 102 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Reason: Q.850;cause=3
Content-Length: 0

Would be good to find out if your test to call an extension directly, and then forward to VM is working.

I would suggest that you check your blast group members, and maybe try trimming you blast group down to just 2 members for testing.

Thank you,

Darren

Hello all,

Where I got with this was to set up a lab test here with my chosen ITSP but I've been too busy to get into it.  I'm thinking that maybe November/December maybe?

The ITSP I've been using has Asterix as the back end. 

We did some deep investigating and found that at the moment the call was to go to voicemail on the UC the ITSP says they received a call hangup signal.  Below is the exact output they were receiving.  The funny thing is that the with all debugs on there was no evidence that the UC was doing anything to terminate the call.  Nothing in CME, VM, nada.  I have a feeling that it is a problem with Asterix (you can't trust those linux thingys   I spent an inordinate amount of time with Cisco support (who were excellent) and with the ITSP who were also excellent.

The only way we had to get around it was to use the ITSPs voicemail service which isn't the best but it gets around the problem for the moment.

For some reason the debug from the ITSP didn't get through so here it is:

-------------------Asterisk debug-------------------------

May 5 12:04:21 VERBOSE[18634] logger.c: -- Attempting native bridge of
SIP/580-1948 and SIP/pstn-b182
May 5 12:04:26 VERBOSE[18631] logger.c: -- SIP/5430-1688 is ringing
May 5 12:04:26 VERBOSE[18631] logger.c: -- SIP/5430-1688 is ringing
May 5 12:04:26 VERBOSE[18631] logger.c: -- SIP/5430-1688 is ringing
May 5 12:04:26 VERBOSE[18631] logger.c: -- SIP/5430-1688 is circuit-busy
May 5 12:04:26 VERBOSE[18631] logger.c: == Everyone is busy/congested at this
time (1:0/1/0)
May 5 12:04:26 VERBOSE[18631] logger.c: -- Executing Macro("SIP/5061-40c58b30",
"vmessage|5430@default") in new stack
May 5 12:04:26 VERBOSE[18631] logger.c: -- Executing
VoiceMail("SIP/5061-40c58b30", "u5430@default") in new stack
May 5 12:04:26 VERBOSE[18631] logger.c: -- Playing
'/var/spool/asterisk/voicemail/default/5430/unavail' (language 'en')

---------------------End--------------------------------------

Message was edited by: Damian Halloran

Hi Damian,

Thanks for the update

A properly configured Asterisk system (Running the latest code and using Real-Time DB) should work very comfortably with the Cisco IOS since there are many similarities between the two

I would place money on it that there is an internal error 500 happening which is issuing the hangup command and the Asterisk is seeing this as a clear cause 21 "403 Forbidden" or a 29 "501 Facility Rejected" and would go as far as to say that the system is not setup to support codec renegotiations mid-way, which is quite common with Asterisk Deployment as it can be perceived as a security issue and is often used in Toll Fraud situations.

I am trying to work out a way around this, it is a bit hard as I have no reference point to work of in the IOS, but if you force a G.711 Codec end to end this should not occurr, if it still does then there is another issue happening... Can we look at canvassing this just for the purpose of testing? I know the ITSP may not want that as they may not want that much bandwidth being used, but it would be good if they are willing to allow it for testing purposes, you could force it on the Cisco side, but you may then get call rejected every time.

I have a fair bit of experience with Asterisk, moreso than I do with Cisco UC-500's and I know for certain they play quite nice with each other.

Cheers,

David.

Not sure if you've seen David but my first post above has the debug output from the UC - not sure if that provides further clues.

I do have a test account set up with the ITSP so that I can try and isolate the problem but that is part of the problem - it is just me and I need to feed my family :-)

But I am expecting that November things will be quieter and I'll be able to focus on testing this with the ITSP.

In regards to the G711 codec I positive that the debug above shows that I've got G711 end to end.......but it also shows that the UC doesn't appear to be doing anything to terminate the call.

Only joking about the linux thing - cut my Unix teeth on RH5.1 so I know it is an excellent back-end OS ;-)

Damian

Hi Damian,

We are both in the same country and you have my mobile number, so when ever you want, give me a call and I would be more than happy to look into this with you after hours (Of course) and see if we can narrow down on the issue.

I have read through your logs, whilst there are some things of concern/suspicion happening within the logs, I still think the issue is coming from the ITSP and their system not the UC.

Cheers,

David.