I currently have a working PRI for PSTN calls, and am testing a SIP trunk. My trunk is registered. I have the following outbound dial peers
dial-peer voice 902 pots
no sip registrar
dial-peer 904 voip
destination-pattern 913(removed, but more explicit than above)
session protocol sipv2
session target X.X.X.X
If i do a show dialplan number with the explcit number, i show matching dial peer 904 first, as expected
however, the calls go out the PRI.
I do not see an Invite message with debug ccsip messages. Am I misisng something here? If i was sending the incorrect number of digits, I would still see an Invite, correct?
Then the binding under dial peers should fix both inbound n outbound dialpeers
the one towards the provider.
Please rate all the useful posts
Thanks for the logs. I checked the logs and can see between CUBE and CUCM H323 is getting used not SIP because it is using dial peer 2004 and 2001 to route the call to CUCM which is configured for H323
Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=2004, Call Count On=FALSE,
You have mentioned when IP phone user answer the call then CUBE is not sending 200 OK to PSTN. When IP phone receiver goes off hook H245 negotiation starts which is used for media. H245 requires a new TCP session to be established for its negotiation. In many netowrks due to some issue H245 TCP hand shake fails due to which both the ends are unable to establish media (it can be confirmed using packet capture but not needed now). When H245 negotiation fails then we can see cause code 47 (Cause No. 47 - resource unavailable, unspecified)
for disconnect same can be seen in your logs
.Jan 20 13:58:13.399: //296998/FE22867482DE/CCAPI/cc_api_call_disconnected:
Cause Value=47, Interface=0x48755A64, Call Id=296998
As in H323 leg media negotiaition is failing so SIP leg between CUBE and service provider does not become aware if IP phone answered the call so CUBE never sends 200 OK to ITSP. I will suggest you two options to resolve the issue:
1. In H323 gateway configuration in CUCM, uncheck "wait for far end TCS" and reset the trunk. Then check the calls.
2. If above option fails then configure dial peer 2004 and 2001 to use SIP using "session protocol sipv2" command and configure a SIP trunk in CUCM for the CUBE if not already configured. Using SIP should fix the issue.