27 Nov
2023
27 Nov
'23
8:54 a.m.
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-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________