[Home]

Summary:ASTERISK-04516: [request] Asterisk ignores/caches phone number/username and context for Broadvoice SIP trunks
Reporter:tracy ing (usatracy)Labels:
Date Opened:2005-07-04 12:45:04Date Closed:2011-06-07 14:03:24
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Asterisk is not properly handling inbound calls from Broadvoice. If one has more than one BV SIP trunk, Asterisk will treat ALL inbound calls from BV as having come from the FIRST one that rings in.

****** ADDITIONAL INFORMATION ******

When a user has 14 trunks from BV, as I do, Asterisk caches the username (phone number) and context of the first SIP trunk that rings in. All subsequent calls from other registered BV trunks will use this cached information. This means the CDR is wrong (so we can no onger bill people for their SIP trunks), the current call info is wrong (so we can't investigate problems on a particular SIP trunk as we don't know which one it really is) and the log file are all wrong. Also, the context is cached so we can't use context to provide individual treatment to the SIP trunk.

BEFORE you tell me there is nothing wrong, there IS something wrong.

When Asterisk is rebooted and a BV trunk rings in Asterisk DOES GET the BV trunk's assigned phone number and asterisk DOES USE the context for THAT BV trunk. The PROBLEM is it will no longer execute whatever code it used to GET THAT information when a second BV trunk rings in (it is called caching folks). Instead, it will treat the other lines using the information gleened from the first BV trunk that rings in.

I have rebooted and tested 14 TIMES, each time I used one of my other numbers and EACH time asterisk used the number of the BV TRUNK that rang in first and its context on the other 13 numbers until rebooted.

ASTERISK IS BROKEN

If it DID NOT GET THE NUMBER AND CONTEXT that would be one thing, but IT DOES GET IT AND IT GETS IT CORRECTLY, FOR THE FIRST BV CALL, then all subsequent calls use THAT INCORRECT PHONE NUMBER AND CONTEXT. (CACHING NUMBER AND CONTEXT)

THIS IS NOT A DESIRED BEHAVIOUR, ASTERISK CAN'T BE FIELDED USING BV SIP TRUNKS WITH THIS TYPE OF CALL INTERACTION ON INBOUND. I HAVE TESTED FOR OVER 4 WEEKS AND I AM TELLING YOU THAT ASTERISK IS BROKEN AND NEEDS SOMEONE TO ACTUALLY LOOK AT CHAN SIP C and FIX THE PROBLEM.

It is my understanding that BV does not auth on inbound and that this was a problem in Asterisk and someone wrote a patch that was then incorporated into asterisk, perhaps this patch broke asterisk with BV trunks ?

In any case, the capability to CACHE inbound name and context on a SIP trunk from the same IP should be an OPTION and NOT a requirement.


As long as Asterisk caches the NUMBER AND CONTEXT....

We can't have CDR
We can't have accurate logs
We can't have traffic reports
We can't diagnose problems to a particular SIP trunk
We can't BILL ENDUSERS for their SIP trunk
We can't support multiple customer operations
We can't provide custom call treatment based on context.

Thank You
Comments:By: Michael Jerris (mikej) 2005-07-04 16:19:19

This is a feature request not a bug.  You can get all of the desired functionality by using an extension in the register line and another few little tricks.
By: Michael Jerris (mikej) 2005-07-04 16:21:05

As this has been requested multiple times with no responses I am going to close this out.  If you would really like this behavior changed I would recomend that you place a bounty on the wiki or contract somone to do this work.  For details on how to make this work search for the duplicate bugs in mantis.
By: tracy ing (usatracy) 2005-07-05 11:58:43

So... if you all made a calculator and whenever the user calculated two values it would report the values of the first calculation only and not the values for waht they actually entered, that would be an accepted manner of operation as long as it does so consistently ?

It is a FEATURE request to expect the system to process information consistently and accurately in a repeatable fashion ?

Very novel approach to bug report closure.

Instead of offering a bounty to provide a FEATURE that will allow the system to process CDR accurately, to provide accuracy in fault diagnoses, and to provide for accurate inbound call handling, I instead will summarize the unique support available for the Asterisk product via the open source community, along with its numerous operational shortcomings in my next Information Week column.

This will certainly open the eyes of those that wonder why they pay so much for proprietary systems like Nortel when there are such unique alternatives available in the OS community like Asterisk.

Thanks !
By: Michael Jerris (mikej) 2005-07-05 12:05:42

This is a repeated bug we get.  It is indeed non-intuitive how it works, it is however totally possible to do what you want to do with the system, as it is, however not how you are attempting to configure it.  As I said, please search for the duplicate bugs, there was one not a week or 2 ago that mark commented specifically with how to address these issues.
By: Michael Jerris (mikej) 2005-07-05 12:11:46

I associated 2 other related bugs to this bug.  A more complete description of the problem is in those bugs.  I am sorry you are unhappy with the way this bug was handled, but a simple search through the closed bugs would have yielded you the solution.
By: tracy ing (usatracy) 2005-07-05 12:43:50

Well... You said it is a feature request, but in the last two responses you state "This is a repeated bug we get." and "I associated 2 other related bugs to this bug"

So is this a BUG or a FEATURE REQUEST?

The user consensus is that this is a bug, I am not operating in a vacuum, other users have also worked with me on this problem and I can have them re-report here if you like.

And, closing the bug report out less than 4 hours after I posted it on a major US holiday will ensure that this is not reviewed by others that may have the capability to review it and perhaps come to a determination, as did you, that this indeed is a bug worthy of repair.

One might think that if "This is a repeated bug we get." it might be worthy of inclusion in the bug tracker for remediation.

Thanks
By: Michael Jerris (mikej) 2005-07-05 13:11:15

I am using the term bug as in mantis bug report generically.  It is a feature request to respond to a very non-intuitive way of doing things.  It does not work as expected, but if configured properly, it will do everything you want to do.  The only reason this one was closed out so quickly and over a holiday week is because an exact duplicate bug was left open a week prior as a feature request with no response.  While others have experienced the same frustration as you have, no one has yet followed up and placed a bounty on getting this work done.  I eagerly encourage people to put some money behind this one.
By: Michael Jerris (mikej) 2005-07-12 17:52:58

Closed due to no response to the feature request.  I hope the other bugs helped on this.  If you would like to contribute to a bounty to re-work this to make more sense that would be much appretiated.