[asterisk-dev] reset/remove SipAddHeader() headers

Klaus Darilion klaus.mailinglists at pernau.at
Thu Jan 15 03:44:46 CST 2009

John Todd schrieb:
> On Jan 14, 2009, at 8:50 AM, Klaus Darilion wrote:
>> Hi!
>> As far as I saw in chan_sip (at least 1.4.22) once SIP headers are  
>> added
>> with SipAddHeader() there is no way to remove them, which is bad if  
>> the
>> request is rerouted to another SIp destination, e.g:
>> user      Asterisk      GW1        GW2
>> ---INVITE-->
>>          add certain
>>          header for GW1:
>>          SipAddHeader(..)
>>               ---INVITE--->
>>               (contains additional
>>               header)
>>               <--500-------
>>          reroute request
>>          to a different GW
>>              ----------INVITE-------->
>>              this request also contains
>>              the added SIP header
>> Headers added with SipAddHeader are added to the incoming channel as
>> global channel variables SIPADDHEADER01, SIPADDHEADER02, ....
>> Then on outgoing requests chan_sip will traverse the channel variables
>> for SIPADDHEADERxx and add them.
>> Thus, it would be useful to reset the channel variables somehow, e.g.
>> with an application SipAddHeaderReset();
>> I could not find any existing solution, thus what do you think about
>> this new application?
>> thanks
>> klaus
> There be dragons.
> I agree that there probably should be some way to do this, but a way  
> to do this properly does not immediately come to mind.  For instance,  
> in the event that GW2 sends a 302 redirect, how does one execute the  
> SipAddHeaderReset() application or function?  That 302 redirect step  
> never breaks out of Dial() - the redirect just magically happens.  The  
> dialplan (or AGI, or whatever) never has a chance to execute any other  
> commands such as adding headers or removing headers or whatever.  I  
> don't have an answer on how this should be handled elegantly.
> Even in the instance where a 500 is received and somehow the dialplan  
> is re-entered, it seems burdensome to remove ALL headers and start  
> from scratch.  Wouldn't you just want to remove the specific header  
> that is causing problems?  This would imply some sort of indexing, or  
> at the minimum, regexp-style string matching so I could say:
>   exten => _X11.,SipRemoveHeader(X-PSAP-ID)
> which would remove both of these headers:
> X-PSAP-ID: 33-MONTCOPA-BACK-99283122833CD
> Lastly, I wouldn't restrict header removal just to headers that have  
> been added by prior steps in the dialplan of Asterisk.  Why not allow  
> deletion of arbitrary headers?  This would permit more control over  
> messaging.  (Though I will admit a glaring memory hole on my part - I  
> assume Asterisk passes through headers unmodified from UA-to-UA... is  
> that correct?  My first memory impression is "Yes" but the more I  
> think about it the less certain I am, and I don't have time to test  
> right now.)
> Or am I missing your concept?

Of course you are right and the SipAddHeader mechanism could be made 
much more generic - my idea was just to start with an easy and doable 

I submitted a patch which also takes at least some of your ideas - to 
remove selectively too: http://bugs.digium.com/view.php?id=14246

core show application SIPRemoveHeader
   -= Info about application 'SIPRemoveHeader' =-

Remove SIP headers previously added with SIPAddHeader

SIPRemoveHeader() allows you to remove headers which were previously
added with SIPAddHeader(). If no parameter is supplied, all previously
added headers will be removed. If a parameter is supplied, only the matching
headers will be removed.

For example you have added these 2 headers:
   SIPAddHeader(P-Asserted-Identity: sip:foo at bar);
   SIPAddHeader(P-Preferred-Identity: sip:bar at foo);

   // remove all headers

   // remove all P- headers

   // remove one the PAI header (note the : at the end)


More information about the asterisk-dev mailing list