[asterisk-dev] [Code Review] SIP Re-invite Glare and 491 Madness...

[Mark Michelson]

Olle E. Johansson wrote:
> While I understand what you're trying to do, the whole situation seems  
> like we're continuing to add bad patches to something with the wrong  
> architecture from start. Suddenly, we have cseq in at least four places:
> 
>   - last invite cseq
>   - last non-invite cseq
>   - glare cseq
>   - the stored packet's (initreq) cseq
> 
> Is this really the proper way to go? While this might be the most  
> light-weight patch for older releases, I suggest that someone spends  
> some time on finding a proper architecture for trunk. The spagetthi  
> code in chan_sip is beginning to look more and more like overcooked  
> lasagna.
> 

I think that is not good to refer to this as a "bad patch" since it gets the job 
done with minimal invasiveness and helps to make the SIP stack better.

I do, however, agree with your comments about the architecture of SIP in 
Asterisk. I pointed out to David while trying to debug this madness that if 
chan_sip had proper transaction support, we wouldn't be having this problem at 
all. In fact, all of those cseq's that we store in a sip_pvt could go away 
completely if we had transaction support.

For now, though, we're just going to push this patch up to trunk since it gets 
the job done. There's more to fix in SIP than just the reINVITE glare problem 
addressed here. I don't think this patch is really the breaking point for 
remodeling the SIP architecture, though.

> David - thank you for analysing the situation. This has really been a  
> hairy problem for a long time.
> 

I completely agree. Thanks for taking the time to get this sorted out.

Mark Michelson

> /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