Call forwarding always to internal or external # fails in inbound calls w/SIP trunk. Pick up and transfer works.

Answered Question
Apr 23rd, 2009

Hi,

We just moved to Nuvox as a SIP provider. Previously we had POTS lines and used "connection plar opx 599" on the voice-port to forward inbound calls immediately to the auto attendant.

Now, I'm trying to use to accomplish the same thing with the SIP trunk. If I forward to an internal extension or to our Exchange 07 server at 599 at the end of a hunt-group or with an ephone-dn the caller receive the message "We're sorry all circuits are busy now.  Please try again later?" ... however, if I take the forward all off, and pick up that line with a phone, then I am able to transfer the call to any ext including 599 without any issues and have full audio.

Here is the applicable config, I believe. Any thoughts?

-----
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
supplementary-service h450.12
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711ulaw
sip
header-passing
registrar server expires max 3600 min 3600
no update-callerid

--
dial-peer voice 1000 voip
permission term
description ** Incoming call from SIP trunk (NuVox) **
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target sip-server
incoming called-number .%
dtmf-relay rtp-nte
fax rate 14400
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711ulaw
ip qos dscp cs5 media
ip qos dscp cs4 signaling
no vad

--
ephone-dn 17 dual-line
number 1234567 no-reg primary

call-forward all 599

-----

THANKS!
-Joe

I have this problem too.
0 votes
Correct Answer by Maulik Shah about 7 years 9 months ago

So am shooting in the dark here. The only difference between the INVITEs for the internal call and external call (put xxx in numbers to hide it):

Diversion: ;privacy=off;reason=no-answer;counter=1;screen=no

This maybe what Exchange looks for, finds no corresponding user or mailbox and hence goes to the main prompt. You can try by adding the below

dial-peer voice 3013

mailbox-selection last-redirect-num

!

If that does not work, remove the above CLI and then try the below:

voice translation-rule 9999

rule 1 /^3145551212/ //

!! NOTE 3145551212 is an example - replace it with your exact number !!

!

voice translation-profile exchange

translate redirect-target 9999
translate redirect-called 9999
!

dial-peer voice 3013

translation-profile outgoing exchange

See if that helps any.

Correct Answer by Maulik Shah about 7 years 9 months ago

Thanks - looking at the logs. In the meantime - can you do me a favor and reduce the timeout on the parallel hunt group to be less than the call-forward no-answer timeout - make it say 5 seconds and see if this works?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Maulik Shah Thu, 04/23/2009 - 22:17

Are you using CCA 1.9.1 for your configuration of Nuvox?

Can you gather "deb ccsip message" for one failed call (preferably by setting call forward all on the ephone-dn) and attach to the thread. Also, what is the SW pack version on the UC520?

Joe Gadell Thu, 04/23/2009 - 22:30

Hi Maulik,

Configured Nuvox with CCA 1.9.1 and the most of the rest by CLI.  I have the latest EA pack.

Log attached. I replaced the phone #s in the log.

Thanks for your help!

Attachment: 
Maulik Shah Thu, 04/23/2009 - 23:14

  Seems like you added this CLI in:

voice service voip

  sip

   header passing

Can you remove the header passing CLI as am not sure why you need that. If things still fail - I will need your complete config (you can remove any customer config such as IP addresses / names)

Joe Gadell Thu, 04/23/2009 - 23:45

Not sure where the "header passing" config came from.... removed it, didn't help though.

The entire config is attached.

thanks

Joe

Attachment: 
Steven Smith Fri, 04/24/2009 - 07:22

On your inbound dial peer you have this.

dial-peer voice 1000 voip
permission term
description ** Incoming call from SIP trunk (NuVox) **
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target sip-server
incoming called-number .%
dtmf-relay rtp-nte
fax rate 14400
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711ulaw
ip qos dscp cs5 media
ip qos dscp cs4 signaling
no vad

voice class codec 1
codec preference 1 g729r8
codec preference 2 g711ulaw

On your dial peer to you exchange you have...

dial-peer voice 3013 voip
description ** UNIFIED MESSAGING **
destination-pattern 5..
session protocol sipv2
session target ipv4:192.168.5.29
session transport tcp
dtmf-relay rtp-nte
codec g711alaw

Change dial-peer 3013 to use g711ulaw, or change the voice class codec to have g711alaw in it above g711ulaw, or remove the voice class codec line from the inbound dial peer and only have g711alaw.

Joe Gadell Fri, 04/24/2009 - 08:30

Hi,

Tried adding g711alaw as a higher preference and changing the codec on 3013 to g711ulaw (seperately).  Didn't help.  Please note that this happens when you try to CFA to a standard phone extension (like 400) as well.  Not just to another dial peer.

Do seem to be getting a fast busy now at the point of the forward instead of the voice message we were getting last night.

Is there a possibility it's trying to send the call back to the trunk?

-----

Apr 24 15:37:55.990: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 480 Temporarily Not Available
Via: SIP/2.0/UDP 74.223.147.141:5060;branch=z9hG4bK0cBec384728edd432a7
From: "LADUE, MO" ;tag=gK0c1940e0
To: ;tag=268ED38-1AC1
Date: Fri, 24 Apr 2009 15:37:41 GMT
Call-ID: [email protected]
CSeq: 22306 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Reason: Q.850;cause=19
Content-Length: 0

-----

Thanks.

Joe

Maulik Shah Fri, 04/24/2009 - 09:33

Can you send the complete debug logs and the latest config (get debug ccsip message & deb voip ccapi inout). What extension are you CFAll to - is it 599? If so it does point to the 3013 dial peer only. Can you ensure both the SIP Trunk and Exchange dial peers are ONLY using 1 codec which is either G711ulaw or G711alaw? Also, you need to add the Exchange IP address in the below ACL:

access-list 1 permit 10.1.10.1
access-list 1 remark CCA_SIP_SOURCE_GROUP_ACL
access-list 1 remark SDM_ACL Category=1
access-list 1 permit 74.223.147.141

access-list 1 permit x.x.x.x <<< IP of Exchange server
access-list 1 deny   any

Can you try CFwdAll to an internal extension such as 20x which is on an IP phone registered to the IP phone?

Joe Gadell Fri, 04/24/2009 - 10:38

I tried adding the access-list rule as well.  Same result.  The log for a current test call and current config are attached.

The # I'm calling in on is the 1234567890 one.

ext 599 is a destination-pattern here:

dial-peer voice 3013 voip
description ** UNIFIED MESSAGING **
destination-pattern 5..
session protocol sipv2
session target ipv4:192.168.5.29
session transport tcp
dtmf-relay rtp-nte
codec g711alaw

I have also tried CFAll to several phone extensions with the same result.

Thanks!

Joe

Maulik Shah Fri, 04/24/2009 - 11:07

Sorry for the back and forth - the logs are cut off. Can you make the buffer larger:

logging buffered 100000 debug

and regather the debugs. Also if you can capture the log for a call forward to an extension - may make it simpler (not having to deal with Exchange SIP area).

Joe Gadell Fri, 04/24/2009 - 11:16

Sorry for the cutoff logs - wasn't paying close enough attention that time.  I've spent at least 7 hours on it now!

For this debug I changed the hunt-group final to be ext 200.

voice hunt-group 1 parallel
final 200
list 200,203,400
timeout 10
pilot 700

See attached.

Thanks.

Attachment: 
Correct Answer
Maulik Shah Fri, 04/24/2009 - 11:33

Thanks - looking at the logs. In the meantime - can you do me a favor and reduce the timeout on the parallel hunt group to be less than the call-forward no-answer timeout - make it say 5 seconds and see if this works?

Joe Gadell Fri, 04/24/2009 - 11:49

I adjusted the timeout on the hunt group, and that fixed it for internal phone extensions!  Howerver, I get nothing but silence when I make it final 599.

To make things simpler, I'm attaching fresh debugs for this last test call.  It is CFAll directly to 599 on the ephone-dn - eliminating the hunt group.

I can call 599 from an inside extension (desk phone) works fine.

As a side note, if I call in and do a manual transfer to 599 it works as well.

PROGRESS!!

-Joe

Attachment: 
Maulik Shah Fri, 04/24/2009 - 13:42

So glad to hear at least CFA to extension works - remember to make sure the call-forward no answer timeout is always higher than the timeout on the blast hunt group.

On the issue with going to exchange - it seems like the MSFT server is accepting SIP requests on 5067 - can you change the below:

dial-peer voice 3013 voip

session target ipv4:192.168.5.29:5067

See if that makes a difference.

Joe Gadell Fri, 04/24/2009 - 14:05

Ok, now we're really close.  What's really odd is that it worked before.

I have it call-foward all to 599, and it is reaching Exchange.  Yet, the proper autoattendant is not answering.  It isn't seeing the 599 come though, but is just answering the connection.

Does that make any sense?

When I dial 599 from a phone, the proper auto attendant does pick up.

Thanks for all of the help.

Maulik Shah Fri, 04/24/2009 - 14:08

Can I get the same debugs as before for an internal call that works (proper AA picks up) and an external call that fails. So 599 is NOT the AA - what is the number the Exchange is looking for?

Joe Gadell Fri, 04/24/2009 - 14:15

The Exchange AA is 599.  That's what it's looking for.  The weird thing it it matches the dial-pattern and sends the call to Exchange.  So I guess Exchange is just seeing the info wrong info when outside -> inside call comes in.

The two logs are attached / named appropiately.

Correct Answer
Maulik Shah Fri, 04/24/2009 - 14:44

So am shooting in the dark here. The only difference between the INVITEs for the internal call and external call (put xxx in numbers to hide it):

Diversion: ;privacy=off;reason=no-answer;counter=1;screen=no

This maybe what Exchange looks for, finds no corresponding user or mailbox and hence goes to the main prompt. You can try by adding the below

dial-peer voice 3013

mailbox-selection last-redirect-num

!

If that does not work, remove the above CLI and then try the below:

voice translation-rule 9999

rule 1 /^3145551212/ //

!! NOTE 3145551212 is an example - replace it with your exact number !!

!

voice translation-profile exchange

translate redirect-target 9999
translate redirect-called 9999
!

dial-peer voice 3013

translation-profile outgoing exchange

See if that helps any.

Joe Gadell Fri, 04/24/2009 - 15:14

That translation rule did the trick!  So what did that do exactly?  Strip the calling # off of the packet?

Thanks!!!

Joe

Maulik Shah Fri, 04/24/2009 - 15:22

Just removes the Diversion header from the SIP message by making the number null - Diversion header is used to indicate who forwarded the call in SIP, in this case Exchange was looking at that to decide what prompt to play.

Actions

This Discussion