Re: [SR-Users] Advice on handling SIP trunk to a Perimeta SBC - sr-users

16 Feb 2021

Hi again,

I'm using Kamailio 5.3.2 by the way.

Björn Bylander writes:

...
  Hi,

 So I’m tasked with setting up a SIP trunk to a Perimeta SBC
(https://www.metaswitch.com/products/perimeta-sbc).

 Apparently,
  Perimeta hides the topology of networks by
rewriting or removing topology-sensitive information from SIP messages. By default, your
Session Controller will make the following changes to SIP messages.

 The Session Controller generates new dialog identifiers (call-IDs, From tags and To tags)
for each side of the call, so that it does not expose information about your core network
to your access networks.
 The Session Controller strips Record-Route and Route information from the message.
 The Session Controller rewrites Contact and Via headers so that the source IP address is
replaced with the local address of the outbound adjacency.
 The Session Controller replaces the IP addresses in c= lines in SDP with the addresses it
has allocated for media forwarding. For more information on this, see Media addresses and
gates.

 My problem is this: When the Perimeta SBC sends its first INVITE (I can't say
anything about any succeeding INVITEs yet) it's added a Record-Route header with the
"lr" parameter included which, as far as I can see makes Kamailio think it
should use loose routing which is all well I think. But when the SBC sends an ACK for the
"200 OK" from the Kamailio side it doesn't include any Route headers and I
think that makes it hard for Kamailio (at least with the standard script which is
basically what I'm using) to know where to relay the ACK, at least it makes the
t_check_trans() call in WITHINDLG after 'is_method("ACK")' return false
which makes the script ignore the ACK.

 Any thoughts or suggestions on how to handle this?

 Thanks in advance,
 Björn Bylander