Thanks for the reply Mark. We did see the toolstep you mention in System_InitiateCallRequest, but previous dealings with this handler broke the association with the original "Interaction 1" that we pull attributes from to make Interaction 2 (and the subsequent conference call) authenticate through the 3rd party IVR automatically. And as I'm sure you know, the toolstep isn't to be used outside of those system handlers, so that prompted me to look elsewhere.
I did get the ININATTR working after posting yesterday. I was missing a few things to make it work the first time I tried it. We can now populate our attributes as we wish in this header and customize them out in the real SIP world. Hopefully, our 3rd party could pull from this header without too much customization on their end...
But....
We also found that the existing Extended Place Call toolstep (which we were using in the existing handler flow to make Interaction 2, then conference Interaction 1 and 2 together) has an input of "Diversion Name" that we populated with a string value... and as long as we set a diversion reason (currently 11 = Away), the SIP diversion header is included with the initial invite as well, which gives us options if our 3rd party can't pull from the ININATTR header for whatever reason. This diversion is actually very minimal customization on our part, which makes it our number 1 choice if they can pull from the diversion header. At this point we have not had any sort of kick off meeting or anything yet, so this at least gives us options to discuss when that time comes. Our Cisco 4331 gateways would have no problem manipulating them if needed, but I don't even know what sort of connection we will have to them, or if any manipulation on our end will be needed via SBC, or if we'll have direct SIP connectivity through our firewalls/etc/etc/etc...
Thanks again.