How to send variable information via sip header

I have 3 equipments.
Asterisk
IVR
ALCATEL

Asterisk makes a IVR call, and the IVR prompts you to enter the document number, the IVR returns a REFER to Asterisk stating that this call must be transferred to Alcatel.

What happens is that in REFER sent by the IVR the SIP header is OK, the problem is that the Invite made by Asterisk for Alcatel no longer has the same information.

I’m trying to manipulate via SIPADDHEADER, but I can not seem to find how I get this variable (document number).

Information I need is in the X-Altitude-Data header

Trace REFER IVR

Frame 12191: 625 bytes on wire (5000 bits), 625 bytes captured (5000 bits)
Ethernet II, Src: Alcatel-_a5:53:cc (e8:e7:32:a5:53:cc), Dst: Vmware_15:4f:ac (00:0c:29:15:4f:ac)
Internet Protocol Version 4, Src: 10.7.8.124, Dst: 10.224.30.50
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (REFER)
Request-Line: REFER sip:10.224.30.50;transport=UDP SIP/2.0
Message Header
Max-Forwards: 70
Refer-To: sip:3800@10.224.30.50
Referred-By: sip:32458@10.7.8.124;user=phone
Via: SIP/2.0/UDP 10.7.8.124:5060;branch=z9hG4bK-00de262de2684f7c9d59f88f08f6f226
Contact: “32458” sip:32458@10.7.8.124:5060;transport=UDP
To: “Andr?? Storti” sip:3900@10.224.30.50;tag=9069e8a5-0326-46f8-8c89-90809832fb58
From: sip:32458@10.7.8.124;tag=cb7a8b2a59524a388df04c9c43c096c7
Call-ID: c36d4067-4e47-4b8d-9421-62269fe7f0af
CSeq: 1 REFER
User-Agent: VocaleSIPAgent
Content-Length: 0
X-Altitude-Data: 283XXXXXXXX
[Expert Info (Note/Undecoded): Unrecognised SIP header (x-altitude-data)]
[Unrecognised SIP header (x-altitude-data)]
[Severity level: Note]
[Group: Undecoded]

Trace invite Alcatel

Frame 12398: 966 bytes on wire (7728 bits), 966 bytes captured (7728 bits)
Ethernet II, Src: Vmware_15:4f:ac (00:0c:29:15:4f:ac), Dst: Alcatel-_a5:53:cc (e8:e7:32:a5:53:cc)
Internet Protocol Version 4, Src: 10.224.30.50, Dst: 10.7.9.152
User Datagram Protocol, Src Port: 5160, Dst Port: 5060
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:3800@10.7.9.152 SIP/2.0
Message Header
Via: SIP/2.0/UDP 10.224.30.50:5160;branch=z9hG4bK25f5831a
Max-Forwards: 70
From: “Andr\303\251 Storti” sip:3900@10.224.30.50:5160;tag=as12927498
To: sip:3800@10.7.9.152
Contact: sip:3900@10.224.30.50:5160
Call-ID: 48e63ebc70b27add57c0950e44e1401e@10.224.30.50:5160
CSeq: 102 INVITE
User-Agent: FPBX-13.0.190.19(13.14.0)
Date: Mon, 27 Mar 2017 19:27:46 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
X-Altitude-Data:
Content-Type: application/sdp
Content-Length: 330
Message Body

Thanks

Neither chan_sip or chan_pjsip allow retrieving SIP headers except from the initial INVITE. You would need to make code modifications to support this.

1 Like

Although the old versions of Asterisk I work with don’t allow setting headers (other than Replaces) with REFER, the way your IVR tries to do so is just wrong. If you had a full implementation of REFER, any headers to be generated in the resulting INViTE would need to be in the Refer-To URI. Nothing in the specification of REFER would cause any header, other than Refer-To, to be used on anything but a single session basis.

Also note that you need to mark logs as unformatted text for the forum to reproduce them in a useful way.

Wow, we have been attempting to capture the SIP Headers for weeks and today I find this post.

jcolp, when you say the chan_sip only allows receiving the SIP headers from the initial INVITE, does that mean for inbound AND outbound calls?

If so WHY in the world would it be coded that way? Most of the useful SIP information comes down after the call progresses to the next step. Here we can get (in our case) Twilio Sesssion information and later Twilio Call Recording ID information.

We did make some changes to chan_sip.c and have it working - but that is ugly and has already become an issue with migration to another server (that happens to enforce compile time options).

There must be a cleaner way to collect SIP Header information…

Any suggestions will be greatly appreciated.

I can’t remember for chan_sip what it gets (if anything) for outbound calls. As for why it was written that way - because that is the way the person who wrote it wrote it.

Without further additions to the code to extend it, you can’t get additional SIP header information from subsequent messages.

1 Like

Thanks for the quick reply. While hoping for the best, I was expecting
that answer.

For anyone stuck in a similar situation, wanting access to the SIP
headers, this is how we got it done. Not pretty, but it works until a
better solution can be devised:

in chan_sip.c: (find this section… and insert from /* Fetch Header
*/ to the end.

                     switch (found) {
                     case SIP_REQ_MATCH:
                             sip_pvt_lock(sip_pvt_ptr);
                             if (args.method != SIP_RESPONSE && 

args.authentication_present
&& strcmp(args.fromtag,
sip_pvt_ptr->theirtag)) {
/* If we have a request that
uses athentication and the fromtag is
* different from that in the
original call dialog, update the
* fromtag in the saved call
dialog */
ast_string_field_set(sip_pvt_ptr, theirtag, args.fromtag);
}

/* Fetch Header */
const char *twilio_callid = sip_get_header(req, “X-Twilio-CallSid”);

/* Set Field Name */
const char *target_call = “twil_call_sid”;

/* X-Twilio-CallSid */

/* jkc debug next line only */
// ast_debug(2, “Hello world - we are here!\n”);

if (!ast_strlen_zero(twilio_callid)){
if(sip_pvt_ptr->owner){
ast_verbose("#ACC X-Twilio-CallSid %s\n", twilio_callid);
ast_cdr_setvar(ast_channel_name(sip_pvt_ptr->owner),target_call,twilio_callid);
}
}

1 Like