20 Apr
2009
20 Apr
'09
7:03 p.m.
Hi all.
I am doing some test about tcp/udp transport protocols in SIP and IP
fragmentation.
I would like to test this behaviour, as stated in par. 18.1.1 of rfc3261:
If a request is within 200 bytes of the path MTU, or if it is larger
than 1300 bytes and the path MTU is unknown, the request MUST be sent
using an RFC 2914 [43] congestion controlled transport protocol, such
as TCP. If this causes a change in the transport protocol from the
one indicated in the top Via, the value in the top Via MUST be
changed. This prevents fragmentation of messages over UDP and
provides congestion control for larger messages. However,
implementations MUST be able to handle messages up to the maximum
datagram packet size.
To do this, I am running a OpenSer 1.3.2 with a "default" configuration
(and very simple: no accounting, no auth, no DB) and I have two SIP
phones registered on that server (for example, ext. 100 and ext. 101).
When 100 calls 101, the INVITE reaches the OpenSer that appends some
"dummy" headers (I have added some append_hf in the route), just to let
the message be bigger than the MTU.
The INVITE is routed towards 101 with UDP protocol and I have IP
fragmentation.
Do you have some hint to get the OpenSer work as described in the RFC
(i.e. switch automatically to TCP)?
Or is this only possible with UACs and not with proxies?
TIA
--
Ing. Sandro Bordacchini
Dexgate Sr. Tech. Engineer
P.zza Fermi 1 - Fornacette
IT-56012 Calcinaia (Pisa)
Tel. +390587424145 ext 580
20 Apr
20 Apr
7:36 p.m.
On 04/20/2009 06:03 PM, Sandro Bordacchini wrote:
Hi all.
I am doing some test about tcp/udp transport protocols in SIP and IP
fragmentation.
I would like to test this behaviour, as stated in par. 18.1.1 of rfc3261:
If a request is within 200 bytes of the path MTU, or if it is larger
than 1300 bytes and the path MTU is unknown, the request MUST be sent
using an RFC 2914 [43] congestion controlled transport protocol, such
as TCP. If this causes a change in the transport protocol from the
one indicated in the top Via, the value in the top Via MUST be
changed. This prevents fragmentation of messages over UDP and
provides congestion control for larger messages. However,
implementations MUST be able to handle messages up to the maximum
datagram packet size.
To do this, I am running a OpenSer 1.3.2 with a "default" configuration
(and very simple: no accounting, no auth, no DB) and I have two SIP
phones registered on that server (for example, ext. 100 and ext. 101).
When 100 calls 101, the INVITE reaches the OpenSer that appends some
"dummy" headers (I have added some append_hf in the route), just to let
the message be bigger than the MTU.
The INVITE is routed towards 101 with UDP protocol and I have IP
fragmentation.
Do you have some hint to get the OpenSer work as described in the RFC
(i.e. switch automatically to TCP)?
Or is this only possible with UACs and not with proxies?
old openser/kamailio does not do the transport conversion automatically.
You can do it manually by forcing outgoing transport, but is hard to
guess the size of the outgoing message from the config.
However, next release will have it -- sip-router.org core has this
functionality already. See:
http://sip-router.org/wiki/core-cookbook/devel#udp_mtu
http://sip-router.org/wiki/core-cookbook/devel#udp_mtu_try_proto_proto
You can get the Sip-Router code (which includes not kamailio/openser
modules but lacks some core functions and parameters) from GIT:
http://sip-router.org/wiki/git/sip-router-repository
That core cookbook is work in progress, you can see kamailio/openser
version at:
http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:devel
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
7:55 p.m.
New subject: [Kamailio-Users] switch to TCP when UDP message is bigger than MTU
On Mon, Apr 20, 2009 at 6:03 PM, Sandro Bordacchini
<sandro.bordacchini(a)dexgate.com> wrote:
(snip)
Do you have some hint to get the OpenSer work as
described in the RFC
(i.e. switch automatically to TCP)?
I'm not sure about OpenSER, but you could actually do so using sip-router.
Cheers,
--
Victor Pascual Ávila
9:34 p.m.
Hi Sandro!
If you just need it for testing then you could use the approaches
mentioned in the other emails.
But for a production system you usually do not want this feature.
Practically this paragraph from RFC 3261 is non-sense as it brakes
communication with SIP clients.
Residential customers SIP clients are mostly behind NAT and often do not
even support TCP. Thus, automatic switching to TCP will cause problems
as you can not reach the clients anymore.
Usually administrators look how to turn this feature off instead of
turning it on.
regards
Klaus
Sandro Bordacchini schrieb:
Hi all.
I am doing some test about tcp/udp transport protocols in SIP and IP
fragmentation.
I would like to test this behaviour, as stated in par. 18.1.1 of rfc3261:
If a request is within 200 bytes of the path MTU, or if it is larger
than 1300 bytes and the path MTU is unknown, the request MUST be sent
using an RFC 2914 [43] congestion controlled transport protocol, such
as TCP. If this causes a change in the transport protocol from the
one indicated in the top Via, the value in the top Via MUST be
changed. This prevents fragmentation of messages over UDP and
provides congestion control for larger messages. However,
implementations MUST be able to handle messages up to the maximum
datagram packet size.
To do this, I am running a OpenSer 1.3.2 with a "default" configuration
(and very simple: no accounting, no auth, no DB) and I have two SIP
phones registered on that server (for example, ext. 100 and ext. 101).
When 100 calls 101, the INVITE reaches the OpenSer that appends some
"dummy" headers (I have added some append_hf in the route), just to let
the message be bigger than the MTU.
The INVITE is routed towards 101 with UDP protocol and I have IP
fragmentation.
Do you have some hint to get the OpenSer work as described in the RFC
(i.e. switch automatically to TCP)?
Or is this only possible with UACs and not with proxies?
TIA
21 Apr
21 Apr
3:05 p.m.
Hello,
On 04/20/2009 08:34 PM, Klaus Darilion wrote:
Hi Sandro!
If you just need it for testing then you could use the approaches
mentioned in the other emails.
But for a production system you usually do not want this feature.
Practically this paragraph from RFC 3261 is non-sense as it brakes
communication with SIP clients.
Residential customers SIP clients are mostly behind NAT and often do not
even support TCP. Thus, automatic switching to TCP will cause problems
as you can not reach the clients anymore.
Usually administrators look how to turn this feature off instead of
turning it on.
is it supposed to happen even if UA binds location with UDP contact? I
thought is used manly for inter-proxy/scb communication.
Cheers,
Daniel
regards
Klaus
Sandro Bordacchini schrieb:
--
Daniel-Constantin Mierla
http://www.asipto.com/
Hi all.
I am doing some test about tcp/udp transport protocols in SIP and IP
fragmentation.
I would like to test this behaviour, as stated in par. 18.1.1 of rfc3261:
If a request is within 200 bytes of the path MTU, or if it is larger
than 1300 bytes and the path MTU is unknown, the request MUST be sent
using an RFC 2914 [43] congestion controlled transport protocol, such
as TCP. If this causes a change in the transport protocol from the
one indicated in the top Via, the value in the top Via MUST be
changed. This prevents fragmentation of messages over UDP and
provides congestion control for larger messages. However,
implementations MUST be able to handle messages up to the maximum
datagram packet size.
To do this, I am running a OpenSer 1.3.2 with a "default" configuration
(and very simple: no accounting, no auth, no DB) and I have two SIP
phones registered on that server (for example, ext. 100 and ext. 101).
When 100 calls 101, the INVITE reaches the OpenSer that appends some
"dummy" headers (I have added some append_hf in the route), just to let
the message be bigger than the MTU.
The INVITE is routed towards 101 with UDP protocol and I have IP
fragmentation.
Do you have some hint to get the OpenSer work as described in the RFC
(i.e. switch automatically to TCP)?
Or is this only possible with UACs and not with proxies?
TIA
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
4:10 p.m.
Daniel-Constantin Mierla ha scritto:
Hello,
On 04/20/2009 08:34 PM, Klaus Darilion wrote:
Hello Daniel & Klaus,
thanks for your replies.
I'm going to try sip-router.
And, AFAIK, at least one IP pbx works as stated by RFC (automatically
switch to tcp when trying to send big messages) when registered to a sip
proxy.
Thanks a lot.
--
Ing. Sandro Bordacchini
Dexgate Sr. Tech. Engineer
P.zza Fermi 1 - Fornacette
IT-56012 Calcinaia (Pisa)
Tel. +390587424145 ext 580
But for a production system you usually do not want this feature.
Practically this paragraph from RFC 3261 is non-sense as it brakes
communication with SIP clients.
Residential customers SIP clients are mostly behind NAT and often do
not even support TCP. Thus, automatic switching to TCP will cause
problems as you can not reach the clients anymore.
Usually administrators look how to turn this feature off instead of
turning it on.
is it supposed to happen even if UA binds location with UDP contact? I
thought is used manly for inter-proxy/scb communication.
Cheers,
Daniel
25 Apr
25 Apr
3:25 p.m.
Hi Klaus,
Klaus Darilion schrieb:
Hi Sandro!
If you just need it for testing then you could use the approaches
mentioned in the other emails.
But for a production system you usually do not want this feature.
Practically this paragraph from RFC 3261 is non-sense as it brakes
communication with SIP clients.
Residential customers SIP clients are mostly behind NAT and often do not
even support TCP. Thus, automatic switching to TCP will cause problems
as you can not reach the clients anymore.
you are right, but RFC 3261 says also...
18.2.1 Receiving Requests
"For any port and interface that a server listens on for UDP, it MUST
listen on that same port and interface for TCP.
This is because a message may need to be sent using TCP, rather than
UDP, if it is too large."
... so the SIP clients you mentioned are not conform with RFC 3261!
regards,
Andreas
4:51 p.m.
New subject: [Kamailio-Users] switch to TCP when UDP message is bigger than MTU
2009/4/25 Andreas Heise <aheise(a)gmx.de>de>:
Klaus Darilion schrieb:
Even if they do, the NATting node will simply reject the connection.
You will have 50/50 chances that it's the client starting the
connectino (works), and server starting the connection (fails on nat).
It's not a nat-friendly standard, so it's safer to just ignore it.
Also if your udp packet is bigger than MTU, it will simply get
fragmented and transmitted anyways. If you have packets bigger than
max udp size, then that's your main problem ;) If your equipment can't
handle fragmentation, you will get a lot of strange problems one way
or another.
Stan
Practically this paragraph from RFC 3261 is
non-sense as it brakes
communication with SIP clients.
Residential customers SIP clients are mostly behind NAT and often do not
even support TCP. Thus, automatic switching to TCP will cause problems
as you can not reach the clients anymore.
you are right, but RFC 3261 says also...
18.2.1 Receiving Requests
"For any port and interface that a server listens on for UDP, it MUST
listen on that same port and interface for TCP.
This is because a message may need to be sent using TCP, rather than
UDP, if it is too large."
... so the SIP clients you mentioned are not conform with RFC 3261!
26 Apr
26 Apr
11:13 p.m.
Stanisław Pitucha wrote:
2009/4/25 Andreas Heise <aheise(a)gmx.de>de>:
That's correct. Switching from UDP to TCP is correct with the standard
but does not work.
regards
klaus
Klaus Darilion schrieb:
Even if they do, the NATting node will simply reject the connection.
You will have 50/50 chances that it's the client starting the
connectino (works), and server starting the connection (fails on nat).
It's not a nat-friendly standard, so it's safer to just ignore it.
Also if your udp packet is bigger than MTU, it will simply get
fragmented and transmitted anyways. If you have packets bigger than
max udp size, then that's your main problem ;) If your equipment can't
handle fragmentation, you will get a lot of strange problems one way
or another. Practically this paragraph from RFC 3261 is
non-sense as it brakes
communication with SIP clients.
Residential customers SIP clients are mostly behind NAT and often do not
even support TCP. Thus, automatic switching to TCP will cause problems
as you can not reach the clients anymore.
you are right, but RFC 3261 says also...
18.2.1 Receiving Requests
"For any port and interface that a server listens on for UDP, it MUST
listen on that same port and interface for TCP.
This is because a message may need to be sent using TCP, rather than
UDP, if it is too large."
... so the SIP clients you mentioned are not conform with RFC 3261!
5689
days inactive
5695
days old
8 comments
6 participants
participants (6)
-
Andreas Heise -
Daniel-Constantin Mierla -
Klaus Darilion -
Sandro Bordacchini -
Stanisław Pitucha -
Victor Pascual Ávila