SIP inbound fail to only certain numbers - UK

[SparrowHwk]

Hello,

We have a number of new DNs which we've added to CUCM.  They are all in London so begin 0203 which is new to our company so I updated the Gateway dial-peers to suit. 

We CAN dial out from the test number but are UNABLE to dial IN

PSTN >>> SIP PROVIDER >>> GATEWAY >>> CUCM

debugs collected when dialing in are attached .txt

Can anyone assist me with this issue please?

[R0g22]

Signaling is not complete in the logs. I only see CUCM sending a 200 OK.

[ardugar]

What is the exact issue you face? Like what is the behavior of the call? 

From signalling perspective, it is fine till 200 OK message received on the gateway but nothing after that. 

[SparrowHwk]

Thank you both,

The call in to any 0203 number just hangs with no audible feedback (i.e. like busy or reorder tone)

Its obviously getting to the Gateway but I don't think CUCM receives the call (I've checked using RTMT call logs).

[R0g22]

Like i said, your CUCM does send a 200 OK but the rest of the signaling post that is missing. Increase the buffer on the router and take another set of complete logs.

[SparrowHwk]

Hello,

I've now attached the full debug I collected the other evening (I can only collect out of hours as the gateways are remote to me and debugs would lock me out during the day).

If these aren't suitable I will re-collect over the weekend and update the ticket.

Let me know. Thank you.

[R0g22]

Can you share the calling/called party numbers please ?

[SparrowHwk]

Calling: +447534123456

Called: +442037654321

[R0g22]

Attach your config. A couple of things -
Your ITSP does not wait for a 200 OK from GW and keeps sending INVITE's. These are not reINVITE's. Seems that they either

1. Do not receive our 100 TRYING and 180 or,
2. They don't like what we are sending. I see your 180 having a private IP address in RPID and Contact headers -

Jun 26 21:28:15.282: //287/AB8E45D281F5/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 88.215.63.13:5060;branch=z9hG4bK7d591c6921ef20ec86b81d919529ac39

From: <sip:07534123456@88.215.63.13;user=phone>;tag=3739037295-217118

To: <sip:02037654321@88.215.63.13:5060;user=phone>;tag=172C64-7DA

Date: Tue, 26 Jun 2018 21:28:15 GMT

Call-ID: 275724915-3739037295-217111@MSX82.gammatelecom.com

CSeq: 1 INVITE

Require: 100rel

RSeq: 5713

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Remote-Party-ID: <sip:88880000@192.168.8.19>;party=called;screen=no;privacy=off

Contact: <sip:02037654321@192.168.8.19:5060>

Server: Cisco-SIPGateway/IOS-15.4.3.M3

Content-Length: 0

3. "Require:100rel" is populated in the 180 message but there is no SDP. For the ITSP, our device would play the ringback/audio and they won't generate local ringback but without the SDP your ITSP does not know what IP address and UDP port to listen on or cut through audio for. This could be another reason for them to not accept the 180.

[SparrowHwk]

I've attached the running config from the Gateway which I hope helps you help me further. Thank you for your help.

[R0g22]

I checked your config and it is strange that the CUBE is forcing the Require:100rel header without any configuration since this is NOT the default.
Can you do the following and test ?

voice service voip
sip
rel1xx disable

This is a global command.

[SparrowHwk · Accepted solution]

Hello,

I've reviewed the Gateway config and realised the problem was with the incoming number specified on dial-peer voice 9 

I've now changed to incoming called-number ^0[1-2].........$

Calls into 01...... and 02..... number are now working

Thank you for your help and assistance on this issue.

[R0g22]

Didn't get it. How did changes to incoming called number fixed your ITSP responding to 180 ?

[SparrowHwk]

Compare the following:

!
dial-peer voice 9 voip
description *** Inbound DP from ITSP ***
call-block translation-profile incoming call_block
call-block disconnect-cause incoming call-reject
session protocol sipv2
incoming called-number ^01.........$
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
ip qos dscp cs3 signaling
no vad
!

changed to....

!
dial-peer voice 9 voip
description *** Inbound DP from ITSP ***
call-block translation-profile incoming call_block
call-block disconnect-cause incoming call-reject
session protocol sipv2
incoming called-number ^0[1-2].........$
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
ip qos dscp cs3 signaling
no vad
!

[R0g22]

I got that. My question is how did this affect the fact that your ITSP was not responding to SIP messages earlier ? Were you matching a different dial peer previously ?