CME 11 Inbound Calls SIP 484 Problem

[JRLDavis1]

Hello Community, and thank you in advance for reading my problem.

I have a lab CME Setup using an old 2901 router with CME Version 11.0.

I have a couple of sip phones, and I have been playing with 2 basic sip trunks.

On one, it works fine.  Inbound and outbound calls.

On the other, I can only get outbound calls, and I can't work out what I'm doing wrong.

The debug is showing SIP2.0 484 Address Incomplete, with a reason of 28. 

From doing a bit of searching, It seems this is something to do with the number length? 

In the debug, the inbound number is showing as country code+area code+local number and if I set this in my config, it doesn't work.  So, I'm stumped.  Eg for the inbound number is showing as 61(Australia) 8(Area Code) 12345678(Local Number).

The relevant parts of my config are here:

voice translation-rule 2
rule 1 /.*/ /61812345678/
!
voice translation-rule 100
rule 5 /61812345678/ /500/
!
!
voice translation-profile sip-outgoing
translate calling 2
!
voice translation-profile sip-incoming
translate called 100

dial-peer voice 10 voip
description --- SIP incoming ---
translation-profile incoming sip-incoming
session protocol sipv2
session target sip-server
incoming called-number .%
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
dtmf-relay rtp-nte
ip qos dscp cs5 media
ip qos dscp cs4 signaling
no vad

[b.winter]

How should someone be able to help you, if you don't provide all the necessary information?
I mean, if you have already done a debug, why don't you add it to your post? And also the full config (without any sensitive data). These are basic infos that everybody needs to troubleshoot.

debug for SIP:
"debug ccsip messages"

debug for dial-peer matching:
"debug voice ccapi inout"
or better, because not so much unnecessary output lines:
"debug voice ccapi ind 1"
"debug voice ccapi ind 2"
"debug voice ccapi ind 74"

debug for translations:
"debug voice translation"

[b.winter]

@JRLDavis1 any update here? Or just a dead post?

[JRLDavis1 · Accepted solution]

Sorry, it was obvious to me you were simply replying to try and put me down, in your aggressive manner. 

So, I didn't bother to reply. 

I worked it out with the help of someone else. I also learned that this community is not really a place to seek help or support. 

[Roger Kallberg]

I don’t know what you mean by that the answer you got was aggressive and not helpful? It is absolutely not unreasonable to ask for the information that was requested. I would say that you’re overreacting slightly on this.

For the good of others who might have the same type of issue as you have it would be courageous of you if you were to share what you did to solve your problem.

[b.winter]

Then you have to answer the question to yourself, how should someone be able to help you, if you don't provide any (more) info?

We (people who are trying to help) don't have access to your setup, and we don't see what you see.
So, it's your job to provide as much info as possible.

And my first post was more "aggressive", because the info I asked for a basic infos of troubleshooting, and I expect them to be in the original post.
And a lot of people here ask for help, but neither providing any helpful description nor posting the basic logs / configs.

[JRLDavis1]

Then you shouldn't be here. 

It is pretty simple. If you aren't able to be respectful, you aren't being helpful, so why do you bother?

Clearly, nobody meets your standards. 

It is not my fault that I am not able to read your mind and know every single thing you want me to provide before I provide it. 

I just am a person trying to learn. 

Being nice costs nothing. 

[b.winter]

And being respectful, by not wasting other people's time, who are doing this voluntarily and in their free time also costs nothing.

Then you've learned, which info is needed to troubleshoot a sip call...

If you've ever worked with Cisco TAC, then you will know, that almost every first reply from them will contain questions about the setup, config, troubleshooting steps done, provide logs and debugs, versions, ... so as much info as possible.

And if you provide this already when opening a TAC ticket or a question in the forum, people who are trying to help, will have the basic info and can start investigating on their, without asking you to provide it and wait again for you to reply.
Which, in turn, helps you already, because there is no time between getting the needed info and getting startet with investigating and therefore quicker possible solutions.