Calls not being accepted/directed

#1

Hi!

The yeti softswitch does not route calls. I’ve completely reinstalled it due to the weak setup previous time to exclude such errors. No errors occurred during the installation (https://yeti-switch.org/docs/en/installation/repositories.html) and configuration (https://yeti-switch.org/docs/en/quick_start.html).

When I run TCP dump I can see a trace come in from our PBX, our PBX also keeps resending it. However, yeti-switch does not respond.

Running a routing simulation results in 2 rows; bottom row provides ‘[0.404 - No routes]’ while the top row shows a correct routing (I can post this if needed?).

Interestingly the CDR history also does not record anything, probably because no response is sent (due to it not being detected?). sems has been started on the only interface at port 5060.

What am I missing here?

Thank you!

SIP Trace:
22:11:58.561176 IP (tos 0x0, ttl 115, id 18425, offset 0, flags [none], proto UDP (17), length 978)
source.dns.sip > dest.ip.sip: [udp sum ok] SIP, length: 950
INVITE sip:DESTNR@dest.dns:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.3.2:5060;branch=z9hG4bK-524287-1—a92c23196b330d66;rport
Max-Forwards: 70
Contact: sip:source.ip:5060
To: sip:DESTNR@dest.dns:5060
From: "SOURCENR"sip:dest.dns:5060;tag=4c66731a
Call-ID: fnJaXTI-JebGXi4csAoaQw…
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE
Content-Type: application/sdp
Supported: replaces, timer

#2

Could you share output of netstat -lpn and iptables -L -vn ?
Looks like sems doesn’t receive your requests.

Running a routing simulation results in 2 rows; bottom row provides ‘[0.404 - No routes]’ while the top row shows a correct routing (I can post this if needed?).

This is right behavior.

#3

Is the Sems service started ? I also faced this issue and found out that the SEMS service was not started. Also have you allowed your incoming IP in the firewall ?

try service sems restart

#4

It indeed was something in the iptables.
Though I am not sure why tcpdump would log it if iptables blocks the connection.

On another note, is there a way to manage the contact header?

Yeti correctly forwards the call, I’ve rewritten the ‘To’ header but I’d also need to pass on the contact header.
I’ve enabled on both the incoming gateway and the outbound gateway to pass on the ‘contact’ header.
Unfortunately it does not correctly forward the contact header.

Incoming contact header:
Contact: sip:DID@INCOMINGPBXIP:5060

Outgoing contact header:
Contact: sip:YETIIPADDR:5060;transport=udp

#5

because tcpdump captures traffic before iptables, so it will show incoming packet even if it will be dropped by netfilter subsystem later.

but I’d also need to pass on the contact header.

It is not possible because Yeti is b2bua - legA and legB are different dialogs in SIP protocol terms. If you need to “forward” contact header you should use plain SIP proxy like kamailio/opensips.

Could you explain why you want to pass contact?

#6

because tcpdump captures traffic before iptables, so it will show incoming packet even if it will be dropped by netfilter subsystem later.

Good to know, I was not aware of that behavior. :slight_smile:

Could you explain why you want to pass contact?

Sorry, perhaps I should’ve phrased it better.

I do not neccessarily need to pass/forward the incoming contact header, I just need to provide a different format contact header.

Depending on our provider I need the header to be e.g.:
Contact: sip:FROMDID@YETISWITCHIP:5060
Contact: sip:+FROMDID@YETISWITCHIP:5060
Contact: sip:LOCALAREADID@YETISWITCHIP:5060

Or using the diversion header to call out. However, Yeti Softswitch is only adding the contact header in the following form:
Contact: sip:YETISWITCHIP:5060;transport=udp

So far I have been unable to locate the configuration of the Contact header (per gateway?).

A SIP proxy would be another solution, however, I think a B2BUA would suit our case better and provide more routing/troubleshooting control and insights.

#7

It is not possible to change format of contact header now. Contact header should not be used to pass address information - try to use From/To/PPI/PAI/Diversion instead

   The Contact header field provides a SIP or SIPS URI that can be used
   to contact that specific instance of the UA for subsequent requests.
#8

Do you have some legB gateway that has some logic based on Contact URI username?

#9

I’ve passed the question onto them, since I get a 503 there might be a different cause (on their site).
They’ll get back to me.

Thank you for the help!

#10

There indeed was an issue on their site. :frowning:

Another thing I noted though is the following;
When selecting rewrite rules on the outbound trunk (I’d like a + in front of the numbers) it works as supposed except at the SRC SOURCE.

I’ve added a trace made by Yeti switch. As you can see the from ‘name’ has been rewritten correctly, however, the number remains empty.

Key Value
DIVERSION REWRITE RULE ^(.*)$
DIVERSION REWRITE RESULT +\1
SRC NAME REWRITE RULE ^(.*)$
SRC NAME REWRITE RESULT +\1
SRC REWRITE RULE ^(.*)$
SRC REWRITE RESULT +\1
DST REWRITE RULE ^(.*)$
DST REWRITE RESULT +\1

Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:+DESTNR@DESTTRUNK:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP YETISBC;branch=z9hG4bKg4fQsalK;rport
From: +31401234567 sip:+@YETISBC;tag=8-5A139B78-5C6ADF6F000617F0-B4FB8700
To: sip:+DESTNR@DESTTRUNK:5060
CSeq: 10 INVITE
Call-ID: 8-667251BE-5C6ADF6F000617F2-B4FB8700
Max-Forwards: 70
User-Agent: SBC 1.7.72-9p
Content-Type: application/sdp
Contact: sip:YETISBC:5060;transport=udp
Content-Length: 460
Message Body

#11

Could you show SRC_PREFIX_IN, SRC_PREFIX_ROUTING, SRC_PREFIX_OUT fields of CDR?

#12

Hi Chris,

I have just tried to manipulate the caller ID and it is working fine at my end, Please find the below screenshots for your reference.I had translated the src number on the Gateway itself.

#13

src number may be translated on multiple phases of routing. This is why I asking about SRC_PREFIX_IN, SRC_PREFIX_ROUTING, SRC_PREFIX_OUT fields of CDR - it wil help to understand situation.
In your INVITE example From username is started from +, so where is problem?

#14

Sorry for the late response. It was quite busy.

The issue was that with the same rule the invite and destination were being rewritten while the ‘from’ header only resulted in a + (thus no number behind it).

In the mean time I have recreated the dial peer with the exact same rules. Now it works without any issue.
I’m not sure where it came from though.