Hi,
I have Kamailio in a weird interop/adaptation layer role with the following call flow:
SUBSCRIBE to Kamailio with Expires: 0 ---> <-- immediate 200 OK from Kamailio
[some time passes]
<-- NOTIFY with additional info from Kamailio 200 OK to Kamailio --->
The NOTIFY follows a series of lengthy async HTTP interrogations, so it's constructed at a later point in time with $uac_req(...).
The problem is that the standard which regulates this is extremely eccentric in the following way: despite the immediate expiration of the subscription, the NOTIFY is expected to conform to the format of an in-dialog request as if a dialog existed.
Don't ask. It's as idiotic as it sounds. But it's a Broadsoft "standard".
I can match the To URI / To-tag by capturing it from the incoming From header on the SUBSCRIBE and reproducing it into the outgoing To header on the NOTIFY.
The issue is that my From-tag on the NOTIFY does not match the To-tag on the 200 OK for the SUBSCRIBE. So, from the point of view of the subscriber, the NOTIFY is "From" a different party to the one that "initiated" a "dialog" in response to its subscription.
I'm just sending the "200 OK" for the SUBSCRIBE like this:
--- append_to_reply("Event: $hdr(Event)\r\n"); append_to_reply("Expires: $hdr(Expires)\r\n"); append_to_reply("Contact: sip:$sel(cfg_get.domain.sip_domain):$Rp\r\n");
send_reply("200", "OK"); ---
I am not aware of anything like an onsend_route that I can use to gain access to the To header of this reply. Nor am I aware of any means of removing headers from a reply and injecting my own To header with a self-generated To-tag I can later mimic in the From tag of the NOTIFY.
Any creative workarounds would be appreciated!
-- Alex