[asterisk-dev] Planning for Asterisk 1.6.1 - chan_sip

[Johansson Olle E]

18 feb 2009 kl. 04.08 skrev Leif Madsen:

>
>
> Jeffrey Ollie wrote:
>> On Tue, Feb 17, 2009 at 4:40 PM, Matthew Nicholson
>> <mnicholson at digium.com> wrote:
>>> Instead of having a bunch of different hard coded types (friend,  
>>> user,
>>> peer, trunk, service), I think we should have a set of options  
>>> that each
>>> type corresponds to.  For example, if I just want to match incoming
>>> calls on ip and port, there should be something like match=ip,port.
>>> Setting type=peer should just implicitly set match=ip,port.   
>>> Otherwise I
>>> fear we will end up with a special type= option for each type of
>>> matching people want to do.
>>>
>>> Basically I think we should enumerate each sip call matching  
>>> strategy a
>>> user may want to use, then create various options that match.
>>
>> That makes a lot more sense to me, as I have never been able to
>> remember the difference between user/peer (if I ever even understood
>> it anyway).
>
> That seems to make a lot of sense to me too. Is there any particular  
> reason this
> isn't possible, or the correct approach?
Let's separate the future from the current. My proposal was about the  
current.

For the future, I have plans to remove user/peer/friend totally as they
make no sense at all in a SIP channel.

My proposal was to go for "Phone", "Service" and "Trunk". With Matthew
proposal, these could very well be aliases for the more complex
matching for advanced users. Btw, this proposal is many years old now
and have been the base for a lot of changes in 1.2, 1.4 and now 1.6.1.

We can not change behaviour in 1.6.1 though and I still need feedback  
on the
document for 1.6.1 so I can go ahead and make the needed changes.

/O