04-28-2011 11:29 PM - edited 03-21-2019 04:01 AM
My client has a UC540 and a SIP trunk for incoming calls. Incoming calls go to a blast group then after the timeout the call should go to voicemail however the caller is receiving a message from the SIP trunk provider stating that the number dialled is not valid.
PSTN calls to voicemail are working - just SIP calls are affected.
I have taken debugs of voice ccapi inout, and ccsip all and these are attached. In example the called number is 0394281062, and the calling number is 0390240631.
Any suggestions please...........
05-02-2011 02:11 AM
What is the timeout on the Blast Group? What is the Call Forward No Answer on the Phones in the Blast Group? Make sure your blast group timeout is lower then the phones, I usually do two to four seconds lower.
If thats not it, can you call a phone and does it forward to VM? That info is needed to know if any SIP call can reach VM.
Thanks,
05-02-2011 03:19 AM
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
05-02-2011 09:22 AM
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: 00394281062>0390240631>
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
09-08-2011 03:08 PM
Hi Damian
Did you manage to fix the poblem.
I'm having the same issue here. Isdn calls reach voice mail but not sip calls
any idea
Thanks
shameer
09-08-2011 04:52 PM
Hi Damian & Shameer,
This seems to be a reoccurring issue for some people, the last one that I looked at, it turned out that the issue resided with the carrier not supporting a codec renegotiation midway through, I.E if one codec was used to establish the call and then a second one was renegotiated to go to the Voice Mail module, normally the Cisco would handle this using transcoding, but it does not seem to be the case in previous grievances...
Can both of you check with your ITSP's to see if this is what is showing up in their logs? It should be fairly simple for them to check... But and FYI if they are using a Broadworx SBC then this is generally not a problem as these particular SBC's support mid-way negotiations.
Shameer,
I have received your e-mail and I will look into your problem as soon as my head gets clear from this flu, I just cant think straight at the moment, but I promise you I will respond once I get a chance to look at it with the diligence it deserves.
Cheers,
David.
09-08-2011 06:56 PM
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
09-08-2011 07:17 PM
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.
09-08-2011 07:31 PM
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
09-08-2011 09:48 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide