[Home]

Summary:ASTERISK-07684: SIPAddHeader sets last used header only
Reporter:hristo (hristo)Labels:
Date Opened:2006-09-06 15:42:52Date Closed:2006-09-10 12:35:45
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) output.txt
Description:This is a 100% duplicate of bug ASTERISK-6226281. The only difference is that it is for trunk this time. Workaround described in ASTERISK-6226281 also works.

In brief - SIPAddHeader will only set one header, even if used multiple times. The  only header that makes it into the SIP message is the last one that was set.

****** ADDITIONAL INFORMATION ******

I am sorry to report a duplicate, but I'm unable to reopen bug ASTERISK-6226281 and I'd rather report the problem again instead of leaving it unreported...
Comments:By: Serge Vecher (serge-v) 2006-09-06 15:47:50

the proper thing to do is ask a bug-marshall to reopen it for you, not open a duplicate

By: Tilghman Lesher (tilghman) 2006-09-08 11:13:22

Can you show us an example of how this is failing?

By: hristo (hristo) 2006-09-10 10:54:10

Sure, try this:

exten => 1234,1,SIPAddHeader(X-Header-1: test1)
exten => 1234,2,SIPAddHeader(X-Header-2: test2)
exten => 1234,3,NoOp(Header1: ${SIPADDHEADER01} Header2: ${SIPADDHEADER02})
exten => 1234,4,Dial(SIP/1234@peer)
exten => 1234,5,Hangup()

The CLI output is attached. It looks like SIPAddHeader at priority 2 actually overwrites the string set by the same application at priority 1, instead of adding another header. Sip debug confirms that only "X-Header-2: test2" is present in the INVITE that is sent by asterisk.

If ${SIPADDHEADER01} and ${SIPADDHEADER02} are set by other means the INVITE will have both headers (the same workaround is described in note 0039937/bug 6281).

By: Tilghman Lesher (tilghman) 2006-09-10 12:35:45

Fixed in revision 42638.