Thanks on the follow up here. I guess you need to switch to TCP, right ?

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS eBootcamp 23rd May - 3rd June 2022
  https://opensips.org/training/OpenSIPS_eBootcamp_2022/

On 5/17/22 2:10 PM, Volkan Oransoy wrote:
Hi all,

For further reference, the issue is related to UDP fragmentation. Digitalocean droplet network doesn’t route fragmented packets. I can see only the first part of the fragmented packet, not the subsequent one. So the destination fails with “ICMP ip reassembly time exceeded, length 556” at os network.

Cheers

Volkan Oransoy
On 11 May 2022 11:52 +0100, Volkan Oransoy <[email protected]>, wrote:
I think the screenshot has been discarded by the mailman. The sip traffic is as follows. The proxy tries to retransmit and fails after three more attempts.

──────────┬───────── ──────────┬───────── ──────────┬─────────
 10:47:32.603828 │ INVITE (SDP) │ │
 +0.000347 │ ──────────────────────────> │ │
 10:47:32.604175 │ 100 Giving it a try │ │
 +0.001474 │ <────────────────────────── │ │
 10:47:32.605649 │ │ INVITE (SDP) │
 +0.490742 │ │ ──────────────────────────> │
 10:47:33.096391 │ │ INVITE (SDP) │
 +1.001859 │ │ ────────────────────────>>> │
 10:47:34.098250 │ │ INVITE (SDP) │
 +1.953642 │ │ ────────────────────────>>> │
 10:47:36.051892 │ │ INVITE (SDP) │
 +1.603582 │ │ ────────────────────────>>> │
 10:47:37.655474 │ 408 Request Timeout │ │
 +0.001615 │ <────────────────────────── │ │
 10:47:37.657089 │ ACK │ │
 │ ──────────────────────────> │ │

Volkan Oransoy
On 11 May 2022 11:14 +0100, Volkan Oransoy <[email protected]>, wrote:
Hi all,

I have an interesting issue with one of my test setups. I have a simple routing script which gets the gateway id directly from the header originating from a Freeswith box. The system finds and sets the request URL as anticipated. But even if I can see the request on the proxy, I can't see the traffic on the destination. Interestingly, the same proxy can register to the same destination with uac_registrant as a UAC. And I can receive calls from the same destination. Is there anything missing to route this traffic correctly?

Thanks in advance.

route[to_gateway] {
        if ( route_to_gw($hdr(X-GWID)) ) {
 route(relay);
        }
}
route[relay] {
        if (is_method("INVITE")) {
 t_on_branch("per_branch_ops");
 t_on_reply("handle_nat");
 t_on_failure("failure");
        }
        if (!t_relay()) {
 send_reply(500,"Internal Error");
        }
        exit;
}

The database structure is as follows;

opensips=# select * from dr_gateways;
 id | gwid | type |           address        | strip | pri_prefix | attrs | probe_mode | state | socket | description
----+------+------+------------------------------+-------+------------+-------+------------+-------+--------+-------------
  6 | 5    |    2 | sip:testgw.bulutfon.net:5060 <http://testgw.bulutfon.net:5060> |    0 |            |       |          0 |     0 |    | 5

Here is the INVITE request sent to the destination, which fails as in the screenshot.

INVITE sip:[email protected]:5060 <http://sip:[email protected]:5060> SIP/2.0
Record-Route: <sip:2.2.2.2;lr;ftag=1jcyr93emrjDQ>
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bK372.d935ecb2.0
Via: SIP/2.0/UDP 1.1.1.1:6080;received=1.1.1.1;rport=6080;branch=z9hG4bK99mtDaevmN7Nj
Max-Forwards: 67
From: "+908508850000" <sip:[email protected]:5060 <http://sip:[email protected]:5060>>;tag=1jcyr93emrjDQ To: <sip:[email protected]:5060 <http://sip:[email protected]:5060>>
Call-ID: aefb8c60-426b-123b-8ca8-82a722ba4f75
CSeq: 51067506 INVITE
Contact: <sip:[email protected]:6080 <http://sip:[email protected]:6080>> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 621
Remote-Party-ID: "+908508850000" <sip:[email protected]:5060 <http://sip:[email protected]:5060>>;party=calling;screen=yes;privacy=off

v=0
o=FreeSWITCH 1651210438 1651210439 IN IP4 1.1.1.1
s=FreeSWITCH
c=IN IP4 1.1.1.1
t=0 0 ...

<Screen Shot 2022-04-29 at 15.13.21.png>
--

Volkan Oransoy

_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to