Hi Alex
If you're having to think about how to do things that break basic SIP semantics, it may be time to rethink your design.
:-) We went into production far down that rabbit hole now. It would be quite hard to pull out from that far in.
More particularly, passing requests from A to B back to A, when A and B are both proxies, is problematic. It will lead to potential call loops if the request should find itself back at the same UA that originated the call. The usual solution is to create a B-leg by laundering the call through a lightweight, signalling-only B2BUA, such as SEMS.
At the moment, we have a commercial SBC which handles RTP, but that SBC has a lot of limitation and is nearing EOL by the vendor, so we want to get rid of it eventually.
So I'm working on adding rtpengine on the registrars and ran into that issue.
In the meantime, I managed to get rid of the record-route headers by calling record_route() in the branch route towards the customer. So if this fails, I'm back with the original invite I send back to A which does not contain B anymore in the route-set.
But that did not get me rid of the Via header, which I believe is added by the TM module. So it would be nice to also find a way, not to generate the via header on a specific branch (or generate the via header on branch basis).
Well I'll attempt another way. I know when call forward was engaged, so I could add an $avp(cfw) = 1 and not engage rtpengine when this is set. So I would still have signaling via the registrar, but not mess around with rtpengine trying to add itself in the RTP path.
Mit freundlichen Grüssen
-Benoît Panizzon-