[asterisk-dev] SIP TCP/TLS, release policy and more (personal opinions included)

[Grey Man]

>  You're digressing into troll bait here. Did this stack implementation you've cited already include a fully state aware session transaction manager? I would hope that it did for your minimal amount of work required to be adequate such that an implementation passes muster at an event like SIPit.
>  The fact of the matter is that chan_sip is what it is and has been and remains to be fully functional for many hundreds of thousands of Asterisk installations it exists today. It's now time for healthy discussion and productive work towards making further improvements on it in the future.

No trolling intended here I am merely an Asterisk end user with an
intense interest in the SIP stack and who has been depending on it
commercially for the last 4 years.

Comparing SIP implementations could be a useful exercise, perhaps
Asterisk could absorb a few concepts from the numerous stacks that are
already running TCP.

In regards to the SIP transaction layer yes the stack I mentioned did
already have it. It actually mystifies me why transactions weren't
used in the initial Asterisk SIP implementation since they are
fundamental for B2BUA and it's not a huge amount of work compared to
oher tasks in the SIP stack like message/header parsing and processing
(a rough estimate from the afore metioned stack is approx 5000 lines
for SIP message processing and 1000 lines for the transaction layer).
The current SIP TCP dilemna is an example of the pain that ommission
has caused.

But as you point out all that is probably water under the bridge at
this stage so my remaining point would be that since SIP is the most
critical channel in Asterisk (based on popularity) half completed work
on it should not be released irrespeective of whether some developers
know it's experimental or not. If Olle, the man who arguably knows as
much about the Asterisk SIP source as anyone, is unhappy enough to
keep posting about the same thing for over a year it's probably worth
actually listening to him.

Regards,

Greyman.