Is it possible to get access to the SIP Header on an incoming call in a handler? There is a SIP Header tag that I would like to get access to that is not available via the attributes.

I am actually just starting on this adventure myself. The requirements for my project will be to handle custom headers coming in the SIP invite as well as responding end of call with a response custom header. So I have a similar 2 part problem as yours. 1. Read incoming non-standard headers and collect the values from them to use in my handler. 2. Upon call transfer with the same caller I will need to append 2 custom headers to the SIP invite to transfer back. I am fairly certain I can define the incoming capture of headers within the line definition properties. I will push those into some custom attributes to handle. I think my hangup will be trying to add 2 headers with their respective data on the outgoing transfer. That is where I think my sticking point will be and may need to track down some handler that may handle that. For now I did find a server attribute that needed adding per documents: "Allow Full Custom Headers" value = Yes

I did find: Administrator -> Lines ->LINE NAME -> Headers (left menu) -> Call Attribute Headers If you add the SIP Header Tag name here. It will turn it into a CIC Call Attribute. The format is EicSIPHeader_<Tag Name>

so much thanks for this post, helped alot :)

------------------------------
Vincent Heijmans
BMW Group Munich
------------------------------

Original Message:
Sent: 05-05-2017 14:57
From: Matt Hanna
Subject: Handler read access to SIP Header on incoming call

I did find:
Administrator -> Lines ->LINE NAME -> Headers (left menu) -> Call Attribute Headers

If you add the SIP Header Tag name here. It will turn it into a CIC Call Attribute.

The format is EicSIPHeader_<Tag Name>

It certainly is just as you described. I don't suppose you have tried to find the exposure to outgoing Headers have you. As in the ability to set custom headers and attributes for an outgoing call? I see where I can transfer the headers to another connected line but I am looking for something a bit deeper than that even if I have to go into the handlers.

I have tried to find a way on the outbound call but have not been able to. I also tested the transfer header option and that did not work for me.

It is a bit late for me this evening but after looking around I think my game plan is going to be this: 1. Leverage the User-to-User header 129 bytes. 2. Pack my data in there. 3. Use our SBC header manipulation to parse the User-to-User header and create the custom headers with the respective data. There are a few more things I need to check to insure this will work. However if it does I will be more than happy to detail it out here. To be honest I am not sure what is keeping I3 from exposing outbound head manipulation but I am no full blown software engineer either. :)

Edit 5/14/2017 - Added more information from further testing. Plus I was a bit to excited once I made some headway. BAM! Looks like I was able to get some header injection into a transfer Outbound SIP call. Bear with me because this is going to a bit lengthy. TLDR: Read it anyway. :) Support Response: I opened a support case to inquire about a Tool Step that had a field "CustomHeaders" and also to poll support on the ability to add Full Custom headers to outbound. Really the response back from support was to use Eic_ISDNUUIData call attribute. So below is the summary of work to get me the custom headers. Problem with using Eic_ISDNUUIData: The problem with this attribute in 2017 R4 (I am currently only running R4) is that it is putting the string value in the header as HEX and I need it plain text/ascii. Changing the line configuration to user-to-user encoding ascii or extended ascii did not have any effect. Even change the line defualt in DSedit to ascii hoping that would help, but it did not. So user-to-user encoding is either broke or I am fubaring something. So went in search of another method. Product Management Response: I also received a response from product management in regards to this very topic. Big shout out to Cindy Herrington in product management for the follow up with more info. Copy paste a relevant portion of her response:

You also can customize the System_IntitiateCallRequest.ihd handler to add header/value pairs by setting the variable sCustomHeaders which is used in toolstep81:OutBoundCall. sCustomHeaders should be a pair of valid SIP header value pairs for example; "Remote-Party-ID=<sip:101@10.22.254.26>;privacy=id" will add two headers to the outgoing sip INVITE message. 'Allow Full Custom Headers' will allow adding of non-standard (Custom headers) using above header/value pair method, if not only standard SIP headers will be allowed.

I have not tested their method for an Outbound initiated call as of yet. However I can state that for a transfer this only works if SIP REFER option is turned off on the line configuration as you can see below in the body of work section. ***Warning - I am modifying a system handler with no custom routine. The tool step states that it will fail if used in any other handler. F1 "Help" is no good to you as well since that field is not documented. Body of work: SIP Line Configuration: You have to turn off Enable sending SIP REFER messages on the "Call Putback" tab. This only works for a blind transfer that uses INVITE only. If you turn on SIP REFER the header is not inserted in any SIP message. Target Handler: System_TransferCallRequest Target Tool Step: Complete External Blind Transfer Target Tool Step field: Custom Headers The "Custom Header" field uses the variable CustomHeader which holds a string. This is where I started play. Thanks to the logs I quickly diagnosed my first issue which had to do with the string format. First attempt: string "CustomHeader1 SomeValue" tsserver log: CSIPSystem::TokenizeCustomHeaders : Tokenizing custom headers = CustomHeader1 SomeValue CSIPSystem::TokenizeCustomHeaders : Invalid custom header found, header-value-pair=CustomHeader1 SomeValue CSIPSystem::SendOutboundReq : Aborting outbound req due to invalid custom header CustomHeader1 SomeValue Those 3 trace log entries helped me out. Since this is a string and not a list of strings I had to find the correct string format to get the pair "Tokenized". Second attempt : string "CustomHeader1=SomeValue" (after some string tokenization C# C++ format google searches) The result from this attempt using the above string produced the result I was looking for. A wireshark capture on the CIC server showed an Outbound INVITE message containing the custom header and value that I wanted. YAY!!! One last hurdle. I need the ability to insert multiple headers. Third attempt: string "CustomHeader1=SomeValue;CustomHeader2=SomeMoreValue" To refrain documenting all my attempts the end result was using a semi-colon ";" to separate the header/value pairs. Again a Wireshark capture showed the insertion of both headers. Remaining problems: 1. The TS process does not adhere to the case sensitivity. You headers and values will not maintain any upper case. (Very disappointed) 2. SIP Refer Message does not carry the modified headers. (Would love this ability)

Sorry for high-jacking your thread pdtmatt. For completeness and after much testing/reviewing the solution that I will take to adding full Custom Headers to the transfer outbound is below: This fulfills my needs for both the SIP Diversion and SIP REFER methods. This will be a two part process. Call Attribute: Eic_UserToUserData Snip from the sip developer application notes.

Eic_UserToUserData syntax: [name=value[;name=value]*] Note: name and value can not contain any double quotes. Note: name must start with uu_. Outbound Logic The value in the call attribute Eic_UserToUserData will be put in the ININAttr header in the following SIP messages: • outbound INVITEs • outbound 302 responses (for blind transfers) • outbound REFERs without replaces (for blind transfers)

Part 1 Set the attribute Eic_UserToUserData with your string of header/values. "uu_H1=SomeValue;uu_h2=someMoreValue" As the notes state this will append as: ININAttr: "uu_H1=SomeValue;uu_h2=someMoreValue" Part 2 Since this is an off-premise transfer the messages will have to traverse the SBC. It is at this point we will leverage the SBC to modify the headers to remove the ININAttr header and insert our own headers with the respective values. So in the end we have now presented a REFER message with the appropriate requested headers to the far end. We also maintained strict typing and did not revert all upper case to lower. It does add a level of complexity with us not being able to do it all on the I3 platform. However thankfully it will not be to bad to maintain.

Hi @Nate Bennett!!! please could you provide me some other information that may be needed to be able to send custom information into the UUI?? I follow step by step you mention, and it doesn't work in our case. Thanks in advance!

------------------------------
David Fradejas Tomás
Sabio Ibérica, S.A.
------------------------------

Original Message:
Sent: 05-14-2017 18:46
From: Nate Bennett
Subject: Handler read access to SIP Header on incoming call

Sorry for high-jacking your thread pdtmatt.

For completeness and after much testing/reviewing the solution that I will take to adding full Custom Headers to the transfer outbound is below: This fulfills my needs for both the SIP Diversion and SIP REFER methods.

This will be a two part process.

Call Attribute: Eic_UserToUserData
Snip from the sip developer application notes.

Eic_UserToUserData syntax: [name=value[;name=value]*] Note: name and value can not contain any double quotes. Note: name must start with uu_. Outbound Logic The value in the call attribute Eic_UserToUserData will be put in the ININAttr header in the following SIP messages: • outbound INVITEs • outbound 302 responses (for blind transfers) • outbound REFERs without replaces (for blind transfers)

Part 1
Set the attribute Eic_UserToUserData with your string of header/values. "uu_H1=SomeValue;uu_h2=someMoreValue"
As the notes state this will append as: ININAttr: "uu_H1=SomeValue;uu_h2=someMoreValue"

Part 2
Since this is an off-premise transfer the messages will have to traverse the SBC. It is at this point we will leverage the SBC to modify the headers to remove the ININAttr header and insert our own headers with the respective values.

So in the end we have now presented a REFER message with the appropriate requested headers to the far end. We also maintained strict typing and did not revert all upper case to lower. It does add a level of complexity with us not being able to do it all on the I3 platform. However thankfully it will not be to bad to maintain.