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

Answered Question
Apr 23rd, 2009
User Badges:

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

Correct Answer by Maulik Shah about 8 years 2 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 8 years 2 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
User Badges:
  • Silver, 250 points or more

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
User Badges:

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
User Badges:
  • Silver, 250 points or more

  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
User Badges:

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
User Badges:
  • Gold, 750 points or more

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
User Badges:

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
User Badges:
  • Silver, 250 points or more

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
User Badges:

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
User Badges:
  • Silver, 250 points or more

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
User Badges:

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
User Badges:
  • Silver, 250 points or more

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
User Badges:

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
User Badges:
  • Silver, 250 points or more

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
User Badges:

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
User Badges:
  • Silver, 250 points or more

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
User Badges:

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
User Badges:
  • Silver, 250 points or more

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
User Badges:

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
User Badges:
  • Silver, 250 points or more

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