[asterisk-dev] [Code Review] SIP: Pineapple

Thu Oct 22 04:30:14 CDT 2009

oej

re new types: I like the proposal to have peer types related to the
actual network architecture rather than the barmy type=user/peer/friend
but I find the actual words you have chosen to be confusing. The
relationship that you name "service" is what I regard as a sip trunk and
which I get from my internet telephony service provider. The ITSP is the
party with whom asterisk, acting as a UAC, registers its contact details
so as to receive incoming calls (even behind nat). The relationship that
you name "trunk" seems to be more of a peer-to-peer relationship such as
one would have between two voip carriers. Perhaps it is just me but I
would prefer something like phone/trunk/partner when the other party is
respectively a client, server or equal of asterisk. As an alternative to
the revolutionary approach in pineapple, a similar effect could be
achieved with an extra peer parameter register=yes/no (or even
register=master/slave/none).

re getting rid of pedantic=yes: I hope this is actually a proposal to
get rid of pedantic=no. Surely asterisk should be RFC3261 compliant. The
extra effort of checking multiple lines and decoding escaped characters
such as # is very small.

re forking chan_sip and starting from scratch: As long as the ideal
system architecture is kept in mind I think it is ok to proceed bit by
bit from an existing implementation. Objectives such as making the types
better reflect the network architecture, moving registration from the
general register strings to the peer definitions, making explicit the
security implications of peer matching and authentication are noble aims
but I am not sure that they are worth the extent of disruption that
would be caused by starting from scratch

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Olle E.
Johansson
Sent: 21 October 2009 21:22
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] [Code Review] SIP: peer matching
bycallbackextension

21 okt 2009 kl. 22.10 skrev David Vossel:

>
> ----- "Olle E. Johansson" <oej at edvina.net> wrote:
>>>> On 2009-10-09 06:18:23, Nick_Lewis wrote:
>>>>> I cannot think for the life of me why this config option would
>>>>> ever be left off. There will no doubt be loads of people reporting
>>
>>>>> callback extension matching problems who will have to be told to
>>
>>>>> enable matching in the config. Eventually the asterisk team will
>>
>>>>> get sick of having to inform this never ending stream of people of
>>
>>>>> the config option and will flip or remove it. However if having
>>>>> matching as a disabled option enables a consensus to be reached
>>>>> then I am delighted
>>>
>>> Yeah, it's really just about providing another knob of control while
>>
>>> not changing the default behavior that has existed for quote a
>>> while.  I'm good with this approach.
>>>
>>
>> I strongly insist, as before, that we write a doc about all the
>> changes and review them together instead of patching something that's
>>
>> already broken. We now have at least two changes on the table and  
>> more
>>
>> to come.
>>
>> The whole callback extension code is a broken concept that should not
>>
>> have been there in the way it is from start. It's a bad patch without
>>
>> any architecture thinking behind it. I think we'd better fix that
>> instead of adding new code to fix the broken code.
>>
>>
>>
>> /O
>
> I understand you don't like this change.  You've been very vocal in  
> telling us peer matching needs to change and you probably have one  
> of the best understandings of how this should happen.  I think that  
> if you offer some direction in the form of organizing the changes  
> that need to be made, and proposing at least an outline of how we  
> can begin to address this as a whole, it will definitely help us  
> move forward with the discussion.

Have you read the documents I've been refering to many times? The  
"future" architecture for pineapple (www.codename-pineapple.org), the  
current one that I wrote up after the kill-the-user disaster (caused  
by me, myself and propably I).
Those two combined are a good starting point for writing up a new one.  
Easy to find if we had svn view... ;-) Search the list and you'll find  
plenty of pointers. I'm a bit off-line now and can't find them. Maybe  
tomorrow.

Writing this up will take some time, that I currently don't have  
plenty of and no funding for. That's why I keep pushing you guys to  
start doing it with the starting points I've given you earlier...  
Maybe we can set up a discussion on IRC on this topic or schedule a  
conference call.

Regardless, until someone has stepped forward with an architecture  
that we all can approve, I want to put this patch and my patch on hold.

What it's really time to do, is to fork chan_sip and start from  
scratch with this model *without* a requirement for backwards  
compatibility. Keep the old junk and create a new channel that will  
have a realtime system that people understand and that works, a  
configuration set that people understand and that works and  
documentation that people understand... But where on earth will we get  
the time and resources for that?

Not having that time, and not having the required documentation is not  
a good excuse for integrating patches that have a high risk of  
breaking more than they are solving.

Long rant from a jetlagged mind in a cold country called Sweden :-)
/O

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

______________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
______________________________________________________________________

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre.
_____________________________________________________________________
Disclaimer of Liability
ATL Telecom Ltd shall not be held liable for any improper or incorrect use of the  information described and/or contained herein and assumes no responsibility for anyones use  of the information. In no event shall ATL Telecom Ltd be liable for any direct, indirect,  incidental, special, exemplary, or consequential damages (including, but not limited to,  procurement or substitute goods or services; loss of use, data, or profits; or business  interruption) however caused and on any theory of liability, whether in contract, strict  liability, or tort (including negligence or otherwise) arising in any way out of the use of  this system, even if advised of the possibility of such damage.

Registered Office: ATL Telecom Ltd, Fountain Lane, St. Mellons Cardiff, CF3 0FB
Registered in Wales Number 4335781

All goods and services supplied by ATL Telecom Ltd are supplied subject to ATL Telecom Ltd standard terms and conditions, available upon request.