Need Help setting up Sip Trunk

[jacobpslagle]

Hello,

I have been spending hours the past few days trying to get my SIP trunk configured for my deployment of CUCME. When I try to make an outbound call all I get is that busy signal and unknown number. When I try to call in all I get is "This number you are trying to reach is not a valid number". I have no idea what's going on I am still new to CME but everything else is working fine. I have attached my error log and router configuration. Hopefully I get this this matter resolved.

Jake

[jacobpslagle]

So I got an update from FlowRoute and it looks like my router is registering with their server and they can't figure out what is going on. The gentleman told me to call Cisco to see if they can do anything and is happy to do a 3-way conference  if need be.

One thing he pointed out was the password in the SIP-UA config. He knows the password is hashed but is concerned about some character's being spaced but I don't think that's the problem. So we are back to my end I guess.

The only other things I can think of are port forwarding, dialpeers, or router config. I am using a different router for my internet so does anything need to be done on that?

[jacobpslagle]

Alright, so I fixed the issue with outbound calling and everything is good. I still can't do inbound calling and I am seeing some weird errors in the log.

[gmgarrian]

Hi Jacob!

Glad to hear outbound is now working. What was the issue?

For inbound, you're hitting dial peer 0 which can cause an issue. Try adding "incoming called-number ." to your provider facing dial peer.

That being said, it's not finding a matching dial peer to route the call on the outbound leg. Can you send the output of "show dial-peer voice summary" to verify the status and destination patterns of your peers?

[jacobpslagle]

Alright, I added the . to my provider facing dial peer and attached if the dial peer summary.

[gmgarrian]

Looks like you have no matching destination pattern in your dial peers.

The invite has 011441519470386 for DNIS:

INVITE sip:011441519470386@10.1.0.5 SIP/2.0

None of your destination will be matched:
14129604388$
1000$
12407506433$
1001$
1[2-9]..[2-9]......T
1[2-9]..[2-9]......

Is this a DID number that should route to an external extension?

(Edited for the ugly paste job)

[jacobpslagle]

Hey @gmgarrian

One of my phones has a phone number of 14129604388. When I call in I want this number routed to the phone that has that number. Same with 12407506433

Jake

[jacobpslagle]

@gmgarrian

I have tried to do some more research on these dialpeers but they can just be a mess. I still can't make an inbound call and I have tried adding destination patterns but still nothing. All I get is a busy signal followed by 'Your call cannot be completed at this time" or "The number you dialed is not a working number" 

ephone 1 has a directory number of 14129604388 When I call this number from the PSTN I want the call routed to this directory number. Same with ephone 2 12407506433. Ephone's 1 and 2 also have directory numbers of 1000 for ephone 1 and 10001 for ephone 2. I am not concerned with inbound calling working for these just my main DIDS.

I will try to keep looking for a solution.

Jake

[gmgarrian]

Can you attach the current "show run" and then these debugs:

debug ccsip message

debug voip ccapi inout

The previous debugs were from when the device was not registered.

Thanks!

[jacobpslagle]

Here are the updated logs

[gmgarrian]

Okay, we need to do a couple things.

First, your ephone-dns are trying to register to your SIP provider.  To fix this, add the following to your config:

ephone-dn 1
number 14129604388 no-reg

ephone-dn 2
number 1000 no-reg

ephone-dn 3
number 17039970903 no-reg

ephone-dn 4
number 1001 no-reg

ephone-dn 5
number 12407506433 no-reg

ephone-dn 6
number 1002 no-reg

This probably isn't causing any issues but it cleans things up.  

Next, your dial peers are set for voice class codec 1 which only offers g711ulaw:

voice class codec 1
codec preference 1 g711ulaw

But, no codec is defined on your ephones so they default to g729 which causes a codec mismatch.  This is why the test call if failing.

Please add the following:

ephone 1
codec g711ulaw

ephone 2
codec g711ulaw

ephone 3
codec g711ulaw

Then, recreate  your cnf files:

telephoney-service

no create cnf

create cnf

Then reset the phone and try again.

I hope that helps.

[jacobpslagle]

Alright, So I made those changes and I am not getting that unauthorized error anymore but I still keep getting that proxy authentication required error. 

*Jun  6 19:32:44.062: //770/36322F108072/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:17174512325@sip.flowroute.com:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.14:5060;branch=z9hG4bK5DF5B1
From: <sip:14129604388@sip.flowroute.com>;tag=E6DF94-1EB5
To: <sip:17174512325@sip.flowroute.com>
Date: Wed, 06 Jun 2018 19:32:44 GMT
Call-ID: 37EDE72A-68F711E8-8077DEBC-7298F095@192.168.0.14
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  900
Cisco-Guid: 0909258512-1761022440-2155011772-1922625685
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M3
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 102 INVITE
Max-Forwards: 70
Timestamp: 1528313564
Contact: <sip:14129604388@192.168.0.14:5060>
Expires: 180
Allow-Events: telephone-event
Proxy-Authorization: Digest username="27574689",realm="sip.flowroute.com",uri="sip:17174512325@sip.flowroute.com:5060",response="115fadb6dc6c121f93ed6415fda09af2",nonce="WxhDelsYQk7AUZX4VfGhI4jMM7SRa1zZ",cnonce="D0625DC2",qop=auth,algorithm=md5,nc=00000001
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 247

v=0
o=CiscoSystemsSIP-GW-UserAgent 9347 6878 IN IP4 192.168.0.14
s=SIP Call
c=IN IP4 192.168.0.14
t=0 0
m=audio 16416 RTP/AVP 0 101
c=IN IP4 192.168.0.14
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

*Jun  6 19:32:44.142: //770/36322F108072/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.0.14:5060;branch=z9hG4bK5DF5B1
From: <sip:14129604388@sip.flowroute.com>;tag=E6DF94-1EB5
To: <sip:17174512325@sip.flowroute.com>
Call-ID: 37EDE72A-68F711E8-8077DEBC-7298F095@192.168.0.14
CSeq: 102 INVITE
Content-Length: 0


*Jun  6 19:32:44.182: //770/36322F108072/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 71.58.129.156:62814;rport=49201;branch=z9hG4bK5DF5B1
From: <sip:14129604388@sip.flowroute.com>;tag=E6DF94-1EB5
To: <sip:17174512325@sip.flowroute.com>;tag=870a5b262384e4f9f82f59836d699db5.adfc
Call-ID: 37EDE72A-68F711E8-8077DEBC-7298F095@192.168.0.14
CSeq: 102 INVITE
Proxy-Authenticate: Digest realm="sip.flowroute.com", nonce="WxhDelsYQk7AUZX4VfGhI4jMM7SRa1zZ", qop="auth"
Content-Length: 0


*Jun  6 19:32:44.186: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:17174512325@sip.flowroute.com:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.14:5060;branch=z9hG4bK5DF5B1
From: <sip:14129604388@sip.flowroute.com>;tag=E6DF94-1EB5
To: <sip:17174512325@sip.flowroute.com>;tag=870a5b262384e4f9f82f59836d699db5.adfc
Date: Wed, 06 Jun 2018 19:32:44 GMT
Call-ID: 37EDE72A-68F711E8-8077DEBC-7298F095@192.168.0.14
Max-Forwards: 70
CSeq: 102 ACK
Allow-Events: telephone-event
Content-Length: 0

[gmgarrian]

You are sending an INVITE with the username/password from your config:

sip-ua
authentication username 27574689 password 7 110C1A35272A2E0A037E0A292E realm sip.flowroute.com

But your provider is still sending a 407.  Verify the password is correct or check with your provider.

We're making progress.

[jacobpslagle]

Password and username are correct. I am in my flowroute control panel and there is a section called Interconnection and when I go to that tab it shows me my current sip registration's. I guess since we put that no reg command on the numbers none of the phones are registering. I really don't know whatever is could be.

[jacobpslagle]

Great news! Calling works but I am still having some troubles with inbound calling. Will keep searching for a solution

[gmgarrian]

Can you get the same debugs as before but for an inbound call?  Also, you can also enable both of those for the same output.