[SR-Users] Intercepting local reply attributes

Alex Balashov abalashov at evaristesys.com
Sat Oct 6 05:04:17 CEST 2018


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

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/



More information about the sr-users mailing list