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.
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?).
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 ?
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.
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.
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.
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.
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.
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.
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?
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.
