Zibri Posted March 15, 2010 Share Posted March 15, 2010 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. Link to comment Share on other sites More sharing options...
Zibri Posted March 15, 2010 Author Share Posted March 15, 2010 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. Link to comment Share on other sites More sharing options...
Zibri Posted March 17, 2010 Author Share Posted March 17, 2010 Are you (NCH) going to do something about this or should I drop AXON and head to another solution? Link to comment Share on other sites More sharing options...
Zibri Posted July 29, 2010 Author Share Posted July 29, 2010 BUG still present in version 2.16 and 2.17. Please DO SOMETHING. Link to comment Share on other sites More sharing options...
Guest N_C_H_JT Posted July 29, 2010 Share Posted July 29, 2010 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. Link to comment Share on other sites More sharing options...
Zibri Posted October 5, 2010 Author Share Posted October 5, 2010 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) Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now