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

[Olle E. Johansson]

22 okt 2009 kl. 11.30 skrev Nick Lewis:

> 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).
A trunk is indeed a mutual relationship between two sip domains, it's  
not a
service where you register for a specific AOR in the other domain to  
get access
to their services and become part of their SIP domain. The words are  
choosen
from a SIP standpoint, not marketing terms of products people put to
market. Nowadays, anything directed towards the business market is
a "sip trunk" regardless of the actual solution.

Regardless, anything is better than "peer/user". Let's call it "frog",  
"orange" and "carpool". :-)

There has to be documentation that clearly explains the various  
settings and
the impact of choosing one or another.

>
> 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.
The whole pedantic option needs to go away and be the default mode.
Always.
>
> 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

The main problem right now is that we're forced by the current rules
to keep backwards compatibility. Fixing this requires a new set of
matching rules and *removing* the peer/user, even though we
keep a majority of the code. Fixing the current issues and keeping  
backwards
compatibility will lead to a large set of issues that will be very hard
to support. The original callbackexten patch has shown that very,very  
clearly.

/O