BUG: Rejected incoming call - could not find a VoIP line to use for call bridging.

[Zibri]

When a call has no caller id I get this error on AXON PBX (latest version and previous versions).

 

This bug is present also in the latest beta version 2.14

 

Analyzing the SIP trace, it seems that the only difference is a MISSING sip header confusing AXON PBX.

 

Anonymous call log:

 

INVITE sip:MYNUMBER@82.59.190.253:5060 SIP/2.0
Record-Route: <sip:83.211.227.21;ftag=238E7434-245E;lr=on>
Via: SIP/2.0/UDP 83.211.227.21;branch=z9hG4bK5474.d33036b2.0
Via: SIP/2.0/UDP  195.62.226.2:5060;rport=52244;x-route-tag="tgrp:Slot6";branch=z9hG4bK3F6DB7230E
From: <sip:195.62.226.2>;tag=238E7434-245E
To: <sip:MYNUMBER@voip.eutelia.it>
Call-ID: 85C4C452-2EF411DF-93A1A7D3-5E5D74E7@195.62.226.2
User-Agent: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Max-Forwards:  9
Contact: <sip:195.62.226.2:5060>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 419
P-hint: 2 Niente 2

At this point AXON gives the error in the topic of this post.

If the call HAS a caller id, AXON works.

 

Normal call log:

 

INVITE sip:MYNUMBER@82.59.190.253:5060 SIP/2.0
Record-Route: <sip:83.211.227.21;ftag=2397A878-520;lr=on>
Via: SIP/2.0/UDP 83.211.227.21;branch=z9hG4bKa3a1.8cc3e07.0
Via: SIP/2.0/UDP  195.62.226.2:5060;rport=52244;x-route-tag="tgrp:Slot6";branch=z9hG4bK3F6E6AD88
From: <sip:HISNUMBER@195.62.226.2>;tag=2397A878-520
To: <sip:MYNUMBER@voip.eutelia.it>
Call-ID: ED4EF72B-2EF511DF-95F9A7D3-5E5D74E7@195.62.226.2
User-Agent: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Max-Forwards:  9
Remote-Party-ID: <sip:HISNUMBER@195.62.226.2>;party=calling;screen=yes;privacy=off
Contact: <sip:HISNUMBER@195.62.226.2:5060>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 419
P-hint: 2 Niente 2

 

 

Please solve this issue ASAP. Or I'll have to decline AXON for my client.

[Zibri]

I just analyzed AXON code.

The problem seems to be here:

 

Axon expects: <sip:%s@%s>

 

But in this case it should be only <sip:%s>

 

Or maybe it's the missing Remote Party ID string.

[Zibri]

Are you (NCH) going to do something about this or should I drop AXON and head to another solution?

[Zibri]

BUG still present in version 2.16 and 2.17.

 

Please DO SOMETHING.

[Guest N_C_H_JT]

I have reviewed your issue and while I can confirm that this behavior could cause problems it absolutely shouldn't cause the error message you are receiving. It seems to me that your configuration may be the real root cause of the issue. I will walk through some information on how (based on the information I can see in your posting) your Axon PBX should be configured and the process by which Axon will verify the call information and route (or fail to route) a call.

 

My first question: Why are you using line bridging? This feature is used to allow hardware lines to connect to VoIP calls. If you are using a VoIP external line and a VoIP internal extension there is no reason to have line bridging enabled at all. The error message you are receiving basically says that you do not have a VoIP line to dial out a call, which means that a dial rule is being applied (i.e. the destination address starts with a '9') and so the system actually tries to dial out on a VoIP line which is most likely tied up with the incoming call. If you turn off line bridging (or change the prefix for the rule) this error may go away immediately.

 

Expected Configuration:

 

External line

 

ID: MYNUMBER

Server: voip.eutelia.it

Ring On: <your extension>

 

When a call comes in Axon will do the following:

 

a. Extract destination of call. This will be the URI if the user ID is present ("INVITE sip:user_id@server:5060 SIP/2.0" -> "user_id") or the ID from the To: header otherwise ("To: <sip:to_id@server>" -> "to_id").

b. Extract the origination address of the call. This will be the value in the From: header field ("From: <sip:from_id@server>;tag=2397A878-520" -> "from_id").

c. Check for external lines that the call has arrived on. Compare the destination and origination addresses to the user ID for each external line, if one matches then the call will be handled on that line. In your case an external line would need to exist with an ID of "MYNUMBER" for this to work correctly.

d. If no external line was found look for an extension that matches the origination request. For the anonymous request this will never match an extension, but since it is an external line it should not ever match an extension.

e. If no matching lines are found Axon should display an error message like: "Unable to find any lines with the ID "to_id" or extensions with the ID "from_id"."

 

Based on this, I am not sure how the non-anonymous call succeeds unless you have an extension configured for HISNUMBER and the external line somehow authenticates properly to this account to handle the call. That is about all the information I can give without your specific configuration details (i.e. what lines are set up for external, what extensions are set up, complete SIP logs of the conversation - not just the first INVITE, dialing plan information, line bridging configuration details, etc.). Please verify that your configuration conforms to the above model and you should be able to successfully take anonymous calls with any of the version of Axon you have tested. If you still believe your configuration is correct you will need to post more information on how your system is configured in order to provide more accurate information about your problem.

 

Regards,

 

Jason T.

[Zibri]

Thanks for finally replying..

 

1) yes there is a line with ID MYNUMBER.

2) axon works well with ANY uincoming call except the anonymous one. (on the same line)

 

3) I know what it *should* happen.. but I can guarantee you it's not a configuration problem.

 

It worked at first.. then EUTELIA changed something on their side and the headers changed. That caused the problem in AXON (but on on other software packages I am actually testing)