Hi List
Two Kamailio Nodes situation.
Node A: Routing Instance. Node B: Registrar Instance.
An invite is sent from Node A to B.
Customer registered on B is 'busy' as example.
B initiates Call Forwarding by adding a Diversion Header and sending the Invite back to A with a new R-URI towards the CFB destination.
The Invite sent from B to A still has Node B in it's Record-Route. So all subsequent SIP messages pass via B, which is not needed and cause issue with rtpengine running on B.
I attempted to remove_record_route(); when sending the call back to A, but this causes:
parse_headers(): bad header field [;lr;ftag=3910078620-883101371>
It looks like only the beginning of the RR header is removed leaving back a competely broken line.
What is the propper was to remove a node from RR and Via routing?
Mit freundlichen Grüssen
-Benoît Panizzon-
If you're having to think about how to do things that break basic SIP semantics, it may be time to rethink your design.
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.
-- Alex
On 27 Nov 2023, at 08:04, Benoit Panizzon via sr-users sr-users@lists.kamailio.org wrote:
Hi List
Two Kamailio Nodes situation.
Node A: Routing Instance. Node B: Registrar Instance.
An invite is sent from Node A to B.
Customer registered on B is 'busy' as example.
B initiates Call Forwarding by adding a Diversion Header and sending the Invite back to A with a new R-URI towards the CFB destination.
The Invite sent from B to A still has Node B in it's Record-Route. So all subsequent SIP messages pass via B, which is not needed and cause issue with rtpengine running on B.
I attempted to remove_record_route(); when sending the call back to A, but this causes:
parse_headers(): bad header field [;lr;ftag=3910078620-883101371>
It looks like only the beginning of the RR header is removed leaving back a competely broken line.
What is the propper was to remove a node from RR and Via routing?
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 ______________________________________________________ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
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-
Hello,
On 27.11.23 14:04, Benoit Panizzon via sr-users wrote:
Hi List
Two Kamailio Nodes situation.
Node A: Routing Instance. Node B: Registrar Instance.
An invite is sent from Node A to B.
Customer registered on B is 'busy' as example.
B initiates Call Forwarding by adding a Diversion Header and sending the Invite back to A with a new R-URI towards the CFB destination.
The Invite sent from B to A still has Node B in it's Record-Route. So all subsequent SIP messages pass via B, which is not needed and cause issue with rtpengine running on B.
I attempted to remove_record_route(); when sending the call back to A, but this causes:
parse_headers(): bad header field [;lr;ftag=3910078620-883101371>
It looks like only the beginning of the RR header is removed leaving back a competely broken line.
What is the propper was to remove a node from RR and Via routing?
the B should not do record_route() when forwards back INVITE to A.
Via is for routing back replies, if you remove it, node B does retransmissions because it does not receives any response and will also send a failure code at some point.
Alternative is to send 302 or something else back to A, which does the redirect using script operations to fetch the contact address or uac_redirect module.
Cheers, Daniel
Hi Daniel
the B should not do record_route() when forwards back INVITE to A.
Right, moving record_route() from the beginning of request_route{} to the branch routes requiring this, solved this for the RR header on my registrar node.
Via is for routing back replies, if you remove it, node B does retransmissions because it does not receives any response and will also send a failure code at some point.
Hmm, ok, so that is a problem, as replies with SDP are passed via B. My attempt to set an AVP on cfw to remember we don't want to rtpengine_manage() the reply, looks promising so far.
Alternative is to send 302 or something else back to A, which does the redirect using script operations to fetch the contact address or uac_redirect module.
I would love to handle all call forwarding situations on the registrar, so the core (running the dialog module for CDR and channel count per customer) can rely on getting full call legs from one dispatcher to another.
Mit freundlichen Grüssen
-Benoît Panizzon-
-
Alex Balashov -
Benoit Panizzon -
Daniel-Constantin Mierla