[Home]

Summary:ASTERISK-18640: ${SIP_HEADER(Subject)} does not get anything
Reporter:Private Name (falves11)Labels:
Date Opened:2011-09-28 19:55:05Date Closed:2011-09-29 13:35:03
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:SVN Frequency of
Occurrence
Related
Issues:
Environment:red hatAttachments:
Description:I have a Macro that gets executed after I get the 200 OK from the carrier. I can see that he is adding a header, "Subject", but it does not get parsed since the function SIP_HEADER does not report it to me. I think that this is a bug. Every time we get a response from the other side, we need to parser all headers received so they are visible to the dialplan through that function. My entire business model is based on detecting this header for billing purposes. It is the LRN number.
 
[macro-get-callid]
exten => s,1,Verbose(0,SUBJECT= ${SIP_HEADER(Subject)})

This is what I get:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 38.101.23.83:5061;branch=z9hG4bK174f655d
Contact: <sip:9544447408@216.234.77.102:5070>
To: <sip:9544447408@216.234.77.102:5070>;tag=2d816a15-co42665-INS097
From: <sip:5034571033@38.101.23.83:5061>;tag=as654ef5ec
Call-ID: 118aee56199834df08d5c697646afd3c@38.101.23.83:5061
CSeq: 102 INVITE
Subject: rn=9544789899
Session-Expires: 600;refresher=uas
Allow: INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,INFO
Content-Type: application/sdp
User-Agent: ENSR3.2.21.12-IS97-RMRG5078-RG17079-CPI97-CPO6104
Content-Length: 244

v=0
o=- 763456021 763456021 IN IP4 216.234.77.102
s=ENSResip
c=IN IP4 74.120.95.23
t=0 0
m=audio 17808 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:18 annexb=no
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
Comments:By: Private Name (falves11) 2011-09-29 13:02:12.378-0500

I think that this is clearly a bug. The function SIP_HEADER() should work like this.


By: Olle Johansson (oej) 2011-09-29 13:17:43.211-0500

No, this is not a bug. SIP_HEADER *ONLY* reads from the initial invite. You can not read from the 200 OK. At the point you get 200 OK, we're in bridge mode and the dialplan doesn't execute any longer.

SO what you need is a new feature. Feel free to contact me on oej@edvina.net to discuss a possible solution.

By: Leif Madsen (lmadsen) 2011-09-29 13:35:03.987-0500

Documentation was updated in trunk, but not 1.8 or 10. I've updated the documentation to match how the function works. No functionality changed. Issue closed.