[Home]

Summary:ASTERISK-03701: [patch] Change the matching for incoming calls
Reporter:Olle Johansson (oej)Labels:
Date Opened:2005-03-18 13:25:31.000-0600Date Closed:2011-06-07 14:05:17
Priority:MajorRegression?No
Status:Closed/CompleteComponents:
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) dangerous.txt
Description:Whooa. Watch out.

With this patch, the matching order for incoming calls will be
* User on From: username @<domain skipped>
* Peer on From: username @<domain skipped> **NEW**
* Peer on IP address

Since peers can have all the configuration options that a user has in CVS head, this patch eliminates both USER and FRIEND in cvs head if you want to.
If you still need to separate incoming and outgoing calls you can still use the old-fashioned USER /PEER scenario.

Disclaimer on file

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

This is experimental and needs testing - will this break any scenario? Feedback welcome!!!
Comments:By: Olle Johansson (oej) 2005-03-18 15:23:37.000-0600

What you do to test this:
* Download the patch and apply it to CVS head
* Change type=friend to type=peer in sip.conf
* If something strange happens, tell me!

By: Olle Johansson (oej) 2005-03-25 09:17:19.000-0600

Please test this patch with CVS head, thank you! I want to know all side-effect of doing this.

...or should we just add it to CVS and see what happens? :-)

By: Mark Spencer (markster) 2005-03-25 15:05:02.000-0600

I think that unifying peer and user does not require changing the behavior.  you can simply have a flag (or field) for whether this is user/peer/friend and if it's user, use the user matching logic, if it's a peer, use the peer matching logic, and if both, do both -- no behavior mods at all.

By: Olle Johansson (oej) 2005-03-25 16:01:51.000-0600

We can try this first, then remove the sip_user structure totally and implement that flag.

By: Mark Spencer (markster) 2005-03-26 01:19:07.000-0600

Are there any remaining parameters in user that are not in peer?

By: Olle Johansson (oej) 2005-04-03 15:21:57

--- Will re-open later, when I have time for this discussion ---