Summary:	ASTERISK-06801: Incoming SIP calls that do not provide auth are lumped into one BIN and screws up data and feature interaction
Reporter:	tracy ing (usatracy)	Labels:
Date Opened:	2006-04-18 02:56:51	Date Closed:	2006-05-10 11:38:00
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/Configuration
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	If two calls come in from the same IP and do NOT provide authentication, like BROADVOICE does, then... 1- There is no way to send these to their particular context. Asterisk will match the context defined for the FIRST number to ring in and all subsequent calls will use THIS context and not the one that has been defined for them. 2- Since asterisk is lumping them all together based on their source IP, a number of features are interacted with incorrectly. For instance, the logs on the incoming call refer to CHECKING CALL LIMITS FOR DEVICE and they refer to the call limits for the first device that rang in from this IP, so you can't place call limitations differently for the different Broadvoice trunks. 3- Data is wrong, CDR reports the number that rang in as the FIRST call that was ever received from the IP, NOT the number that actually rang in. ****** ADDITIONAL INFORMATION ****** I reported this months ago and was quite quickly blown off, unless someone can tell me how to configure a broadvoice trunk that does not auth on incoming to provide for direction to the context(s) I define for them, and to check THEIR individual call limits, and to report THEIR number in the CDR, then this is a BUG. The simplest way to fix this is to add a new option for insecure, insecure=secret If insecure=secret then secret will not be required but username will, the user name will be the number of the registered sip trunk that is ringing in. CDR, check call limits, cdr and other feature interactions will refer to this identifier, contexts would be defined as the NAMED CONTEXT defined for the username (the username is below the named context) In testing, if I set insecure to NO, then all of these feature interactions go away, the CDR is right, it reports the correct context in the logs, and it checks the right device for call limits, of course, we can't accept the call because they must auth first and broadvoice does not. So broadvoice intercepts the call to their voicemail.
Comments:	By: Serge Vecher (serge-v) 2006-04-18 08:55:11 usatracy: I believe Olle has been working on this in his peermatch branch. Please check bug 6612 http://bugs.digium.com/view.php?id=6612 for more information and please test that branch and report back if it helps you. Thanks! P.S. The peermatch branch is also included in the test-this-branch, which contains many other improvements http://svn.digium.com/svn/asterisk/team/oej/test-this-branch/ By: Serge Vecher (serge-v) 2006-05-02 16:32:17 usatracy: any luck with trying Olle's branches? By: Serge Vecher (serge-v) 2006-05-10 11:38:00 Please continue the discussion of this bug in 6612 and test olle's peermatch branch. Thanks.