Hi Andrew,
On Thu, Mar 19, 2020 at 01:53:53PM +1100, Andrew White wrote:
The substitute and arbitrary position options look useful. In these cases, will Kamailio automatically recalculate the Content-Length, or do I need to manually rewrite this somehow?
The Content-Length pertains to the length of an (optional) encapsulated message body only, and not to the length of the SIP message as such, and therefore does not apply to any of its headers.
Encapsulated bodies are used to transport messages of another protocol inside SIP. In SIP land, the most common encapsulated payload is the SDP payload, e.g.
... Content-Type: application/sdp Content-Length: xxx
[SDP of length xxx goes here]
If an encapsulated body is not present, Content-Length is still mandatory but must be set to 0.
I did read that in researching before emailing, from similar thread you responded to about 5 years ago! In this case, we have a specific upstream provider who reject our Contact header in the normal format we send, and require it to be in a specific format. As such, I can manipulate the header on our PBX or on Kamailio. Given Kamailio is aware of the provider we’re sending to and the PBX is not, it seems simpler to do on Kamailio.
The problem with that philosophy is that Contact is fundamentally a creature of the user agent, not of the proxy, so the proxy shouldn't be manipulating it. Any time you manipulate it, you run the risk that a message reliant on that value will be sent in the other direction (the PBX), and the PBX says, "What?! That's not what I sent!" If that happens, you rapidly descend into an unmanageable hellscape of stateful management of this value so as to fool the PBX into thinking that you didn't change it, and so forth.
This should really be done on the calling UA if at all possible. Ideally you could somehow tweak the PBX to send the value in the desired format to begin with.
Kamailio provides a lot of tools to shoot onesself in the foot with. It makes things technically possible that shouldn't necessarily be done just because they are possible. IMHO. :-)
-- Alex