This is my first time posting on here so hopefully this goes over well..
I recently turned up a new SIP gateway (4451-X with PVDM4-256 module) and discovered a bit of an odd item in regards to my dial-peers.
The carrier is delivering the number in as E164; so +1-XXX-XXX-XXXX and is being received on the gateway as such. However, when CUBE sends the call to CUCM, it is stripping the "+" and sending 11 digits instead. The only thing I'm doing unique on the gateway is that I'm binding the dial-peers for SIP signaling instead of the Voice Loopback. I should also note that at some of our remote sites, we use the same sort of method but the DP to CUCM includes the +. In this case, I need support a variable length number as we receive international inbound numbers on this trunk.
My inbound DP from the carrier is:
dial-peer voice 1001 voip description SIP Call Leg to CUBE session protocol sipv2 incoming called-number . incoming uri from SIPProvider voice-class codec 1 voice-class sip options-ping disable voice-class sip options-keepalive retry 3 voice-class sip bind control source-interface Loopback2 voice-class sip bind media source-interface Loopback2 dtmf-relay rtp-nte no vad
Then this is an example of the DP used to send to CUCM
VoIP dial-peers shouldn't strip digits on pattern matches. POTS dial-peers will but not on "incoming called-number" commands. IIRC, H323 call setup messages will also strip a "+" in the IE fields.
What have you looked at to confirm that the gateway is stripping called party digits? Have you looked at "debug ccsip message" on the UBE? What are you seeing if you look at the CM traces (Detailed level on SIP stack)? I would just want to confirm that the digit manipulation is happening at the gateway and not on the CUCM side of the integration.
Can you post the full config and the output of a test call with "debug ccsip message" enabled.
The problem with the translation rules is that the incoming digits on the SIP trunk are variable in length and consist of many different country codes (or lack thereof). It is a very daunting task to undertake the variable length in numbers via translation rules in CUBE.
Ultimately, the goal was to send the number in E164 format from CUBE to CUCM. I was hoping to do all the translating at the Gateway but was hoping that I could get away with my dial-peers being the generic "incoming called-number ." I also thought about trying "incoming called-number +T or +." but didn't really know if those would be valid since they seem a bit off..
I'm not able to access my old voice mail messages all of a sudden. The recording says something like 'the message is currently not available'. This has never happened before in all the years I have been using this system. I have t...