[asterisk-dev] Custom SIP headers and reinvites

[Olle E Johansson]

18 apr 2007 kl. 05.26 skrev Watkins, Bradley:

>
> From: asterisk-dev-bounces at lists.digium.com on behalf of Kevin P.  
> Fleming
> Sent: Tue 4/17/2007 10:14 PM
> To: Asterisk Developers Mailing List
> Subject: Re: [asterisk-dev] Custom SIP headers and reinvites
>
> Watkins, Bradley wrote:
>
> >> I guess what I'm looking for is some guidance on what the correct
> >> behavior is here.  Obviously, these headers should be available  
> one way
> >> or the other.  The question is whether the reinvite should have the
> >> custom headers or whether they need to have some more persistant  
> storage
> >> at the receiving end.  I'm inclined to say the latter, as it's  
> possible
> >> that you could have this same issue with other B2BUA's in a similar
> >> scenario.
>
> > I would agree in principle that this is the receiving end's
> > responsibility to handle. The first issue will be clearly  
> defining which
> > headers should be preserved throughout the life of the dialog  
> even when
> > subsequent INVITEs have been received. This could be just 'all  
> headers
> > that begin with X-' or it could be more complex than that, but  
> the more
> > complex it is the less likely it will get treated as a 'bug fix'  
> or a
> > simple enhancement :-)
>
> For certain, anything that would go into an already-released  
> version should be as simple as possible.  Personally I think that  
> having all X-headers preserved would be a good balance, and it  
> would definitely solve my problem since that's exactly what I need. :)
>
> Perhaps Olle can chime in, but I couldn't really find any RFC-level  
> guidance for SIP in my cursory glance at some relevant ones.
These are two separate invites. The issue here is the lack of  
transaction support
in the chan_sip implementation... I would define sip_header to a  
function that
gets headers from the INVITE that opened the dialog, not "the latest"  
invite.
The way it currently works is that we rewrite the initial invite and  
the data is lost.
Asterisk chan_sip focuses on the current transaction and have no idea  
about the
previous one and can't handle multiple transactions.

There's unfortunately no simple fix to this, if you want to avoid the  
really
messy ugly ones.

I did not see this particular problem with the transaction handling,  
but I've
seen many other issues coming up due to this.

We desperately need to do a major overhaul of the SIP channel.
Check http://www.codename-pineapple.org

/O