8 Apr
2020
8 Apr
'20
4:19 p.m.
I've searched, but I cannot find anything recent about this.
My kamailio 5.0.8 proxy sends an INVITE downstream over UDP and gets
an ICMP port-unreachable response from the UAS.
Apparently ignoring this, it re-transmits the INVITEs and eventually
times out and sends to the next host (from the SRV lookup).
According to RFC 3261 (https://tools.ietf.org/html/rfc3261#section-8.1.3.1),
If a fatal transport error is reported by the transport layer
(generally, due to fatal ICMP errors in UDP or connection failures in
TCP), the condition MUST be treated as a 503 (Service Unavailable)
status code.
Does kamailio support handling ICMP responses to INVITEs (and
therefore either failing over immediately, or sending 503 upstream
immediately)?
I don't know for sure the "correct" behavior because the RFC3261 is so
old and because ICMP responses are limited in size and therefore can't
guarantee to uniquely identify the transactions that caused them.
9 Apr
9 Apr
7:40 p.m.
Kamailio doesn't do any ICMP processing by itself. I noticed that some
recent kernels do that when an app tries to send out via UDP to an
invalid ip/port in the same network and sendto() fails immediately, but
does detect for other target nodes not in the same local network.
You can lower the retransmission timeout to cope better with such case
and fail over to next route faster.
Cheers,
Daniel
On 08.04.20 15:19, James Browne wrote:
I've searched, but I cannot find anything recent
about this.
My kamailio 5.0.8 proxy sends an INVITE downstream over UDP and gets
an ICMP port-unreachable response from the UAS.
Apparently ignoring this, it re-transmits the INVITEs and eventually
times out and sends to the next host (from the SRV lookup).
According to RFC 3261 (https://tools.ietf.org/html/rfc3261#section-8.1.3.1),
If a fatal transport error is reported by the transport layer
(generally, due to fatal ICMP errors in UDP or connection failures in
TCP), the condition MUST be treated as a 503 (Service Unavailable)
status code.
Does kamailio support handling ICMP responses to INVITEs (and
therefore either failing over immediately, or sending 503 upstream
immediately)?
I don't know for sure the "correct" behavior because the RFC3261 is so
old and because ICMP responses are limited in size and therefore can't
guarantee to uniquely identify the transactions that caused them.
_______________________________________________
Kamailio (SER) - Development Mailing List
sr-dev(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
6 May
6 May
9:20 p.m.
Thanks, Daniel
That suits me perfectly.
(I didn't see your response until today.)
James
On Thu, 9 Apr 2020 at 17:40, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
Kamailio doesn't do any ICMP processing by itself. I noticed that some
recent kernels do that when an app tries to send out via UDP to an
invalid ip/port in the same network and sendto() fails immediately, but
does detect for other target nodes not in the same local network.
You can lower the retransmission timeout to cope better with such case
and fail over to next route faster.
Cheers,
Daniel
On 08.04.20 15:19, James Browne wrote:
I've searched, but I cannot find anything
recent about this.
My kamailio 5.0.8 proxy sends an INVITE downstream over UDP and gets
an ICMP port-unreachable response from the UAS.
Apparently ignoring this, it re-transmits the INVITEs and eventually
times out and sends to the next host (from the SRV lookup).
According to RFC 3261 (https://tools.ietf.org/html/rfc3261#section-8.1.3.1),
If a fatal transport error is reported by the transport layer
(generally, due to fatal ICMP errors in UDP or connection failures in
TCP), the condition MUST be treated as a 503 (Service Unavailable)
status code.
Does kamailio support handling ICMP responses to INVITEs (and
therefore either failing over immediately, or sending 503 upstream
immediately)?
I don't know for sure the "correct" behavior because the RFC3261 is so
old and because ICMP responses are limited in size and therefore can't
guarantee to uniquely identify the transactions that caused them.
_______________________________________________
Kamailio (SER) - Development Mailing List
sr-dev(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
1662
days inactive
1690
days old
2 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
James Browne