[SR-Users] Advice on handling SIP trunk to a Perimeta SBC

Björn Bylander bjorn.bylander at leaddesk.com
Tue Feb 16 10:51:31 CET 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




More information about the sr-users mailing list