cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
946
Views
0
Helpful
6
Replies

Problem with incoming calls on SIP trunk with CME 4.0

k.dimitrovski
Level 1
Level 1

Hi,

I have setup a SIP trunk to my pnone service provider and managed to make calls without problems.

Problem apeared when I tried to call any of the phones ona CME. I get busy signal.

Every phone has its own 3 digit extension number which coresponds to the last 3 digits of the phone service provider number for that phone.

For example if someone dials 6622705 it is routed to my CME and I strip the first 4 digits and get 705 which is my extension number for that phone.

In the dial-peer setup I had only defined translation-profiles for incoming and outgoing numbers.

The incoming called-number .T I have added later but it didn't change nothing.

The errot I got is "No Outgoing Dial-peer Is Matched".

What should I do to fix this, and the call to be sent to the right dial-peer (to have a match).

1 Accepted Solution

Accepted Solutions

Hi,

it seems the problem is with the To: header. router is confused by the string user=friend that is in there after the number, see:

Mar 1 13:46:00.250: Parse Error: url_parse_params: Syntax error at friend

In fact, the reply to SIP server is "malformed header", not "not found".

I've quickly glanced over SIP RFC. From what I understand, the possible values for "user" are "phone", "ip", or a token. In fact all the examples in the RFC have "tag=xxxx" bu never "user=".

So I think the problem is with the SIP server they're using that apparently violates the standard so that the rotuer complains.

View solution in original post

6 Replies 6

paolo bevilacqua
Hall of Fame
Hall of Fame

Hi, T doesn;t do anything for incoming DP.

Make "incoming called-number" to be 6622...

And make sure the translation rule is correct.

Well, I've tried that setup but it didn't worked either. (I used "translation-profile incoming inc" for translation)

Actual numbering is 551700 - 551749, and I've written several translation rules. My provider wants the CME to send the numbers in international format (like 00389xxxxxxxx) and the number 8 is used to dial-out.

Actually this CME is a Cisco Demo Box which I'm configuring for a presentation.

I've tried adding new dial-peer for incoming calls and now I get dial-peer match but the calls are dropped like before. I've also tested the rule used for stripping the first 4 digits and it works fine. The telephone provider sends me called numbers in 5511xxx format. I've also added "translate-outgoing dialed 5511" to the dial-peer, but nothing changed.

I'm attaching the whole configuration and the log I get when receiving call with the new dial-peer added.

Thanks in advance for the help...

Hi,

none of your DP has incoming called-number, you need that. Also the DPs need codec G711u.

To diagnose things, take "debug ccsip message", you will see how the numbers are sent and any authentication failure possibly.

I've tried the setup your recommended (one DP and incoming called-number 5511...) , but nothing changed. I'm still getting “No Outgoing Dial-peer Is Matched” every time I call any of the extensions. Again I'm sending the whole config (I think that now is correct) and two very verbose debug logs. I switched on ccsip message and several other similar debug options, hoping to somehow locate the error causing the busy tone I'm getting. Unfortunately looking at the debug logs I didn't came to any conclusion, so any help will be very welcomed.

P.S. I think that adding a second DP for catching incoming calls is the right solution because at least then I got “List of Matched Outgoing Dial-peer(s): 1: Dial-peer Tag=9” but still didn't managed to direct the call to the extension.

Thanks again for all the help and I'm hoping that the solution is near :-)

Hi,

it seems the problem is with the To: header. router is confused by the string user=friend that is in there after the number, see:

Mar 1 13:46:00.250: Parse Error: url_parse_params: Syntax error at friend

In fact, the reply to SIP server is "malformed header", not "not found".

I've quickly glanced over SIP RFC. From what I understand, the possible values for "user" are "phone", "ip", or a token. In fact all the examples in the RFC have "tag=xxxx" bu never "user=".

So I think the problem is with the SIP server they're using that apparently violates the standard so that the rotuer complains.

Thank you very much p.bevilacqua!!!

That was it. The telco changed that setting, and how everything works.

Just for information, it is set to phone now.

Once angain thanks, this thread helped me a lot.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: