Benoit, Alex, I appreciate the feedback, confirming my assumptions. Good news is the Vendor finally responded positively and agreed to add in configuration option to route on INVITE R-URI in next SDK release, expected later this year. In the meantime I added 'uac_replace_to' function to my proxy to re-write To: header with R-URI, so far so good.
Thanks. JR -- JR Richardson Engineering for the Masses Chasing the Azeotrope > > The To header is a cosmetic, purely logical commentary on the intended > ultimate destination of the call, and no routing should ever be done on it. > The RURI of the INVITE is the appropriate vehicle for that. > > When dealing with proxies, however, one will encounter from time to time the > grim reality that there are user agents which expect the To URI and the > INVITE RURI to be in alignment. For that scenario, you can use ‘uac’ module’s > stateful rewriting functionally (uac_replace_to()) to modify To with Kamailio > in a way that displays fidelity and esteem for protocol formalities. > > — > Sent from mobile, with due apologies for brevity and errors. > > > On May 21, 2019, at 9:32 AM, JR Richardson <[email protected]> wrote: > > > > Hey Folks, > > > > I could use some feedback to see if my mind is right on this topic.I'm > > in a discussion with a software Vendor (respectfully unnamed) with > > terminal software routing on To: header info. It's my contention any > > modern SIP software should use INVITE header to retrieve DID info and > > route from there. > > > > My reasoning is due to the To: header should contain the original > > intended DID, Extension, Name, AoR or whatever else the original SIP > > transaction wanted to contact, but being in a multi-carrier, > > multi-hop, call forwarding environment, the INVITE header contains the > > hop-to-hop true intention of where the call should route at any given > > transaction. So in the case of terminal software the To: header could > > likely be irrelevant where as the INVITE header is accurate. > > > > My most recent response from the Vendor suggest I put a SIP Proxy in > > front of the terminal software and transform the To: header to > > whatever I need for this application. Although I can do this, I'm > > concerned with breaking RFC for CANCEL and BYE transaction sent back > > from the terminal software that may not be recognized by upstream > > origination carriers. > > > > Plus modifying To: header is widely frowned upon by most folks. > > > > Thanks. > > > > JR _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
