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 <jmr.richardson(a)gmail.com> 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