Hi James
I've two suggestions (three if we count agreeing with Alex's suggestion to consider not supporting that UA).
Unfortunately, at the moment, not an option.
- Get kamailio to manually do the steps that loose_route() would do
anyway. This is messy, because it requires good understanding of loose routing. You might remove the supplied Route header field, then get the transport/host/port from your saved Record-Route header fields, and then set the $du and $fs explicitly (and then get any _other_ Record-Route values and insert them as Route values), all while being aware of "r2" parameters (to know whether to exclude one or two Route values). It might work, but I don't think I'd ever want to even attempt this nonsense.
I started working in this direction and got this working for transport UDP. After that, I noticed that not msg_apply_changes() caused the issue, but that by mistake I was indeed calling rtpengine_manage() twice in some re-invite situations which caused the duplicate SDP.
- Add TOPOS to kamailio. That strips the topology from the message,
and then the faulty UA should never see Route or Record-Route header fields so never wreck them. It requires kamailio to keep state in a database, though, but it should work well.
I found TOPOS not being able to cope with spiralling calls in this situation which is very common:
* Two customer, Alice and Bob, registered on the same Kamailio Registrar running TOPOS. * Kamailio Registrar are not dialog aware and do not route calls. For this there is a central 'core' kamailio instance running dialog, gathering CDR and knowing how to route calls.
So the call flow is:
Alice => Registrar => Core => Registrar => Bob
The same call passes the registrar twice. This, as I observe (it's still possible I did something wrong), breaks topos and header get replaced the wrong way!