Re: [OpenSIPS-Users] Drouting relay issue
Hi Bogdan
Yes, TCP stack works as anticipated.
Thanks
Volkan Oransoy
On 17 May 2022 16:02 +0100, Bogdan-Andrei Iancu , wrote:
> 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 , 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 , 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 | 0 | |
> > > > | 0 | 0 | | 5
> > > >
> > > > Here is the INVITE request sent to the destination, which fails as in
> > > > the screenshot.
> > > >
> > > > INVITE sip:905551234...@testgw.bulutfon.net:5060 SIP/2.0
> > > > Record-Route:
> > > > 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: "+90850885"
> > > > ;tag=1jcyr93emrjDQ
> > > > To:
> > > > Call-ID: aefb8c60-426b-123b-8ca8-82a722ba4f75
> > > > CSeq: 51067506 INVITE
> > > > Contact:
> > > > 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: "+90850885"
> > > > ;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 ...
> > > >
> > > >
> > > > --
> > > >
> > > > Volkan Oransoy
> >
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> >
Re: [OpenSIPS-Users] Drouting relay issue
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 , 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 , 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
| 0 | | |
0 | 0 | | 5
Here is the INVITE request sent to the destination, which fails as
in the screenshot.
INVITE sip:905551234...@testgw.bulutfon.net:5060
SIP/2.0
Record-Route:
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: "+90850885" >;tag=1jcyr93emrjDQ
To: >
Call-ID: aefb8c60-426b-123b-8ca8-82a722ba4f75
CSeq: 51067506 INVITE
Contact: >
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: "+90850885"
>;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 ...
--
Volkan Oransoy
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Drouting relay issue
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 , 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 , 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 | 0 | |
> > | 0 | 0 | | 5
> >
> > Here is the INVITE request sent to the destination, which fails as in the
> > screenshot.
> >
> > INVITE sip:905551234...@testgw.bulutfon.net:5060 SIP/2.0
> > Record-Route:
> > 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: "+90850885"
> > ;tag=1jcyr93emrjDQ
> > To:
> > Call-ID: aefb8c60-426b-123b-8ca8-82a722ba4f75
> > CSeq: 51067506 INVITE
> > Contact:
> > 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: "+90850885"
> > ;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 ...
> >
> >
> > --
> >
> > Volkan Oransoy
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Drouting relay issue
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 , 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 | 0 | |
> | 0 | 0 | | 5
>
> Here is the INVITE request sent to the destination, which fails as in the
> screenshot.
>
> INVITE sip:905551234...@testgw.bulutfon.net:5060 SIP/2.0
> Record-Route:
> 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: "+90850885"
> ;tag=1jcyr93emrjDQ
> To:
> Call-ID: aefb8c60-426b-123b-8ca8-82a722ba4f75
> CSeq: 51067506 INVITE
> Contact:
> 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: "+90850885"
> ;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 ...
>
>
> --
>
> Volkan Oransoy
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Drouting relay issue
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 | 0 | | |
0 | 0 | | 5
Here is the INVITE request sent to the destination, which fails as in the
screenshot.
INVITE sip:905551234...@testgw.bulutfon.net:5060 SIP/2.0
Record-Route:
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: "+90850885"
;tag=1jcyr93emrjDQ
To:
Call-ID: aefb8c60-426b-123b-8ca8-82a722ba4f75
CSeq: 51067506 INVITE
Contact:
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: "+90850885"
;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 ...
--
Volkan Oransoy
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
