UC540W config help needed - Incoming SIP calls failing

[SPYD0R]

Hi.  Am trying to get a client's old UC540W migrated from a working ISDN/BRI config to SIP.  Managed to get the SIP trunk registered successfully but I am having a LOT of difficulty trying to get incoming calls working with a test SIP number.  The client's telco have been far from helpful so I'm hoping I can get expert help here otherwise they may just have to buy a new PABX.  Trying to get incoming calls to work first before I look at outbound calls.  It seems like a configuration issue on the PABX but it is beyond my expertise and I have been working on it for so long I may just be making things worse now.

Phones are using SCCP protocol, which I understand still works internally with the CME before it is translated to SIP when outbound to the ITSP.

The telco said Incoming calls need to be in the following format:

To: header(at)trunk.gotel.com.mt

From: xxxxxxxx(at)trunk.gotel.com.mt

and Outgoing calls like this:

To: xxxxxxxx(at)trunk.gotel.com.mt

From: header(at)trunk.gotel.com.mt

PPI: 356header(at)trunk.gotel.com.mt (cannot include '+' or will fail)

Contact: 356header(at)publicIP

Hope someone can help; UC540 config attached, SIP call trace in PDF format as the filter keeps blocking this as a txt file. Thanks for looking.

[Maren Mahoney]

The first thing that jumps out at me is that the SIP INVITE shows an inbound 10-digit number, but the voice translation-rule 1 (referenced in the SIP_Inbound voice translation-profile) is translating 8-digit inbound numbers to the 3-digit extensions.

Try a 'test voice translation-rule 1 <DID from provider>' and see what it comes up with.

Maren

(It's very difficult to follow the debug with the ending digits sanitized in some places and leading digits in other places. If we continue with this conversation, perhaps you can PM the original config.)

[SPYD0R]

Thanks Maren.

I've not been entirely consistent with 1-to-1 digit obfuscation in the debug trace; crazy long day, I'll probably make them easier to read and re-post the files in the morning.  The unmasked SIP invite number is actually 11 digits.  The local test number is 8 digits and the international is 11 digits.  I had already run the test voice translation-rule 1 that you suggested and it resolves to the desired 112 extension when the local 8 digit test number is called as well as the full 11-digit International test number, so the final part seems to work.

When I was going through the trace, and my limited understanding, it appeared that the incoming calls were being matched to dial-peer 1000 then the errors started shortly after with the sipSPI_ipip_update... messages; I have struggled to find much relating to them however.  Not sure if those errors are important and whether or not they are indicative of problems with other parts of the config.  The part I have been most confused with is the 'request' and 'response' sections under the voice class sip-profiles, as I found numerous examples of very different configurations in these areas and am not all that sure of whether the config I made is current in that section and could be part of the problem.