Summary: | ASTERISK-18640: ${SIP_HEADER(Subject)} does not get anything | ||
Reporter: | Private Name (falves11) | Labels: | |
Date Opened: | 2011-09-28 19:55:05 | Date Closed: | 2011-09-29 13:35:03 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_sip/Interoperability |
Versions: | SVN | Frequency of Occurrence | |
Related Issues: | |||
Environment: | red hat | Attachments: | |
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. |