incoming called-number question

[sschmidt1]

Hello.

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

dial-peer voice 5269 voip
 description Inbound to CUCM SIP
 destination-pattern .
 session protocol sipv2
 session target ipv4:x.x.x.x
 voice-class codec 1
 dtmf-relay rtp-nte

Do I need to specify my DP's to CUCM to include the "+" Or can I use a destination pattern of T or something like that? It just seems a little odd that "incoming-called number ." would strip the +

[William Bell]

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.

-Bill (@ucguerrilla)

[sschmidt1]

So I had done a debug ccsip messages previously and this is what I noticed.

I should note that I modified the output for security reasons.

Nov  5 16:39:28.670 UTC: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:+19526494024;npdi=yes@10.X.X.GW:5060 SIP/2.0
Via: SIP/2.0/UDP 199.X.X.X:5060;branch=z9hG4bK3dtec100bgr1rjolf081.1
From: "SCOTT SCHMIDT  " <sip:+18881231234@199.X.X.X;isup-oli=62;pstn-params=908481808882>;tag=SDvf1s301-gK0e6f9a8a
To: <sip:9526494024@10.X.X.GW>
Call-ID: SDvf1s301-abda68afeab002b494a37ff366f888f2-v3000i1
CSeq: 5299 INVITE
Max-Forwards: 13
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay,  multipart/mixed
Contact: "SCOTT SCHMIDT  " <sip:+18881231234@199.X.X.X:5060;transport=udp>
Remote-Party-ID: "SCOTT SCHMIDT  " <sip:+18881231234@199.X.X.X:5060>;privacy=off
Supported: timer,replaces
Session-Expires: 1800
Min-SE: 90
Content-Length: 239
Content-Disposition: session; handling=required
Content-Type: application/sdp
v=0
o=Sonus_UAC 27674 5817 IN IP4 199.X.X.X
s=SIP Media Capabilities
c=IN IP4 199.X.X.X
t=0 0
m=audio 50016 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=maxptime:20

Nov  5 16:39:28.674 UTC: //789/25239A738328/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 199.X.X.X:5060;branch=z9hG4bK3dtec100bgr1rjolf081.1
From: "SCOTT SCHMIDT  " <sip:+18881231234@199.X.X.X;isup-oli=62;pstn-params=908481808882>;tag=SDvf1s301-gK0e6f9a8a
To: <sip:9526494024@10.X.X.GW>
Date: Wed, 05 Nov 2014 16:39:28 GMT
Call-ID: SDvf1s301-abda68afeab002b494a37ff366f888f2-v3000i1
CSeq: 5299 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.3.3.S1
Content-Length: 0

Nov  5 16:39:28.674 UTC: //790/25239A738328/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:19526494024@10.X.Z.CM:5060 SIP/2.0
Via: SIP/2.0/UDP 10.X.X.GW2:5060;branch=z9hG4bK82C0
Remote-Party-ID: "SCOTT SCHMIDT  " <sip:+18881231234@10.X.X.GW2>;party=calling;screen=no;privacy=off
From: "SCOTT SCHMIDT  " <sip:+18881231234@10.X.X.GW2>;tag=69FBFA8E-229E
To: <sip:19526494024@10.X.Z.CM>
Date: Wed, 05 Nov 2014 16:39:28 GMT
Call-ID: 2524369B-644111E4-FFFFFFFF832E85EF-FFFFFFFF8811D76E@10.X.X.GW2
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 0623090291-1681986020-2200471023-2282870638
User-Agent: Cisco-SIPGateway/IOS-15.3.3.S1
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1415205568
Contact: <sip:+18881231234@10.X.X.GW2:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 12
Session-Expires:  1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 274
v=0
o=CiscoSystemsSIP-GW-UserAgent 9670 7630 IN IP4 10.X.X.GW2
s=SIP Call
c=IN IP4 10.X.X.GW2
t=0 0
m=audio 16426 RTP/AVP 0 101 19
c=IN IP4 10.X.X.GW2
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000
a=ptime:20

Nov  5 16:39:28.680 UTC: //790/25239A738328/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.X.X.GW2:5060;branch=z9hG4bK82C0
From: "SCOTT SCHMIDT  " <sip:+18881231234@10.X.X.GW2>;tag=69FBFA8E-229E
To: <sip:19526494024@10.X.Z.CM>
Date: Wed, 05 Nov 2014 16:39:28 GMT
Call-ID: 2524369B-644111E4-FFFFFFFF832E85EF-FFFFFFFF8811D76E@10.X.X.GW2
CSeq: 101 INVITE
Allow-Events: presence
Content-Length: 0

Nov  5 16:39:28.686 UTC: //790/25239A738328/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 404 Not Found

[sschmidt1]

What I find the most strange is that even with 0 translation rules, the invite starts with the +1 and then when it is sent to CUCM, it's only the 1.

I did not have the detailed traces enabled during this test and this gateway is currently in a "standby" state.. So unfortunately I can't make any more test calls to it at this time.

I also forgot to mention that I do have the gateway configured in CUCM to accept ALL digits as well.

[Hamid ABBOU]

the stripping of + sign by CUBE may be a bug. Did you try to upgrade the IOS? otherwise re-add it via translation rule.
 

[sschmidt1]

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..

[Brandon Pierce]

What IOS are you on out of curiosity?  I could have sworn the old IOS's on the 12 train stripped that + off (bug related I think) but I might be wrong and confusing that with a myriad of other issues.