Asterisk --> CUCM = OK CUCM --> Asterisk = Fast Busy
Experts, I have a working inbound SIP trunk from Asterisk (AsteriskNow to be exact) to CUCM.
Anything originating on the Asterisk side of the house has absolutely no issues dialing and reaching any extension or even other SIP trunk (Exchange UM, etc.) connected to CUCM.
Unfortunately, the same can't be said for the return path. Calls originating from extensions attached to the CUCM side, get a fast-busy when trying to go out of the trunk towards Asterisk. I'm willing to wager the configuration of CUCM is to blame, but I've checked everything and can't seem to find anything wrong. I believe the issue's probably CSS, but everything checks fine as far as I can tell.
Could I get your guys' take on this to see what I could be doing wrong? Thanks.
//========================
CUCM Config
Device Name: AsteriskTrunk
Device Pool: <Associated DP>
Call Classification: OffNet <-- have swapped back and forth between OnNet as well
Media Termination Point Required: Checked
Retry Video Call as Audio: Checked
Remote-Party-Id: Checked
Asserted-Identity: Checked
Calling Search Space: CSS_Internal
I also have an Exchange UM trunk configured in the same CSS.
Phones and extensions within CUCM all sit within "CSS_FullAccess" which has all of the partitions available to them.
Redirecting Diversion Header Delivery - Inbound: Checked
Redirecting Diversion Header Delivery - Outbound: Checked
Destination Address: <IP Address>
Destination Port: 5060
MTP Preferred Originating Codec: 711ulaw
SIP Trunk Security Profile: STSP_UDP_Accept_OutOfDialo
Outgoing Transport Type: UDP
Accept out-of-dialog refer**: Checked
Accept unsolicited notification: Checked
Accept replaces header: Checked
Transmit security status: Checked
SIP Profile: Standard SIP Profile <-- Default built-in SIP Profile
//========================
AsteriskNow Config
Trunk Name: CUCM
Outbound CallerID: Blank <-- This allows for inbound calls from the world to show their caller-id
CID Options: Allow Any CID
Dial Number Manipulation Rules
match pattern = XXXX <-- All extensions and trunks on the CUCM side are 4 digits
Outgoing Settings
Trunk Name: CUCM
Peer Details:
type=friend <-- Have used "peer" as well here
qualify=yes
nat=no
insecure=very
host=<IP Address of CUCM>
fromdomain=<IP Address of CUCM>
dtmf=rfc2833
disallow=all
context=from-internal
canreinvite=no
allow=ulaw
Incoming Settings
User Context: <IP Address of CUCM>
User Details:
type=friend <-- Have used "peer" as well here
qualify=yes
nat=no
insecure=very
host=<IP Address of CUCM>
fromdomain=<IP Address of CUCM>
dtmf=rfc2833
disallow=all
context=from-internal
canreinvite=no
allow=ulaw
Anything originating on the Asterisk side of the house has absolutely no issues dialing and reaching any extension or even other SIP trunk (Exchange UM, etc.) connected to CUCM.
Unfortunately, the same can't be said for the return path. Calls originating from extensions attached to the CUCM side, get a fast-busy when trying to go out of the trunk towards Asterisk. I'm willing to wager the configuration of CUCM is to blame, but I've checked everything and can't seem to find anything wrong. I believe the issue's probably CSS, but everything checks fine as far as I can tell.
Could I get your guys' take on this to see what I could be doing wrong? Thanks.
//========================
CUCM Config
Device Name: AsteriskTrunk
Device Pool: <Associated DP>
Call Classification: OffNet <-- have swapped back and forth between OnNet as well
Media Termination Point Required: Checked
Retry Video Call as Audio: Checked
Remote-Party-Id: Checked
Asserted-Identity: Checked
Calling Search Space: CSS_Internal
I also have an Exchange UM trunk configured in the same CSS.
Phones and extensions within CUCM all sit within "CSS_FullAccess" which has all of the partitions available to them.
Redirecting Diversion Header Delivery - Inbound: Checked
Redirecting Diversion Header Delivery - Outbound: Checked
Destination Address: <IP Address>
Destination Port: 5060
MTP Preferred Originating Codec: 711ulaw
SIP Trunk Security Profile: STSP_UDP_Accept_OutOfDialo
Outgoing Transport Type: UDP
Accept out-of-dialog refer**: Checked
Accept unsolicited notification: Checked
Accept replaces header: Checked
Transmit security status: Checked
SIP Profile: Standard SIP Profile <-- Default built-in SIP Profile
//========================
AsteriskNow Config
Trunk Name: CUCM
Outbound CallerID: Blank <-- This allows for inbound calls from the world to show their caller-id
CID Options: Allow Any CID
Dial Number Manipulation Rules
match pattern = XXXX <-- All extensions and trunks on the CUCM side are 4 digits
Outgoing Settings
Trunk Name: CUCM
Peer Details:
type=friend <-- Have used "peer" as well here
qualify=yes
nat=no
insecure=very
host=<IP Address of CUCM>
fromdomain=<IP Address of CUCM>
dtmf=rfc2833
disallow=all
context=from-internal
canreinvite=no
allow=ulaw
Incoming Settings
User Context: <IP Address of CUCM>
User Details:
type=friend <-- Have used "peer" as well here
qualify=yes
nat=no
insecure=very
host=<IP Address of CUCM>
fromdomain=<IP Address of CUCM>
dtmf=rfc2833
disallow=all
context=from-internal
canreinvite=no
allow=ulaw
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Had to research into this quite a bit.
I wasn't able to hit the console of the device and perform those steps. As I would SSH or even log into the VM locally, I was getting returns that the "sip" command wasn't present. Nor any of the "core" commands.
Jumping through forum after forum, your instructions were right on the money, but I didn't have those commands present still. As it turns out, 100% due to my understanding (or lack thereof) - was that this was moved to the administrative gui in the version I'm running. *Might be that way in all instances, but I was expecting that it was on the OS level, as I went with the AsteriskNow distribution, instead of just installing Asterisk over the top of another OS. If that makes sense.
So, long story short - it's entirely my fault for taking as long as I have to reply... but it's all in the nature of learning new technologies, right? :)
For this particular question, after I finally was able to get in and see stuff - it doesn't appear that my CUCM originating calls are ever even making it to the asterisk box at all. I could have swore that I have the Calling Search Spaces configured correctly, but I'm obviously missing something on the Cisco side.
I wasn't able to hit the console of the device and perform those steps. As I would SSH or even log into the VM locally, I was getting returns that the "sip" command wasn't present. Nor any of the "core" commands.
Jumping through forum after forum, your instructions were right on the money, but I didn't have those commands present still. As it turns out, 100% due to my understanding (or lack thereof) - was that this was moved to the administrative gui in the version I'm running. *Might be that way in all instances, but I was expecting that it was on the OS level, as I went with the AsteriskNow distribution, instead of just installing Asterisk over the top of another OS. If that makes sense.
So, long story short - it's entirely my fault for taking as long as I have to reply... but it's all in the nature of learning new technologies, right? :)
For this particular question, after I finally was able to get in and see stuff - it doesn't appear that my CUCM originating calls are ever even making it to the asterisk box at all. I could have swore that I have the Calling Search Spaces configured correctly, but I'm obviously missing something on the Cisco side.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
All,
Sorry for my lack of ExpExch cleanliness. Thanks for chiming in here on all the assistance.
I ultimately tore down both systems and rebuilt them from scratch. Everything now works as intended.
The one change that I did on this rebuild, was NOT separating the CUCM side with any Calling Search Spaces. I believe this was the underlying issue. Even though I had placed them in the same CSS, there most likely was something preventing calls going one way.
My issue has been working now for a while. For anybody having the same issue, please double and triple check all your CSS separation on CUCM.
Thanks.
Sorry for my lack of ExpExch cleanliness. Thanks for chiming in here on all the assistance.
I ultimately tore down both systems and rebuilt them from scratch. Everything now works as intended.
The one change that I did on this rebuild, was NOT separating the CUCM side with any Calling Search Spaces. I believe this was the underlying issue. Even though I had placed them in the same CSS, there most likely was something preventing calls going one way.
My issue has been working now for a while. For anybody having the same issue, please double and triple check all your CSS separation on CUCM.
Thanks.
ASKER
- Been spending what time available to this, on researching how to perform the troubleshooting steps you guys are asking me on the CUCM side.