27 Nov
2023
27 Nov
'23
8:04 a.m.
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
______________________________________________________
27 Nov
27 Nov
8:28 a.m.
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(a)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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
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
______________________________________________________
9:16 a.m.
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
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy and Development Services
Kamailio Advanced Training -- asipto.com
9:42 a.m.
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-
--
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
______________________________________________________
397
days inactive
397
days old
4 comments
3 participants
participants (3)
-
Alex Balashov -
Benoit Panizzon -
Daniel-Constantin Mierla