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
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
On Mon, Apr 20, 2009 at 6:03 PM, Sandro Bordacchini sandro.bordacchini@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,
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
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:
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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Daniel-Constantin Mierla ha scritto:
Hello,
On 04/20/2009 08:34 PM, Klaus Darilion wrote:
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
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.
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
2009/4/25 Andreas Heise aheise@gmx.de:
Klaus Darilion schrieb:
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!
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
Stanisław Pitucha wrote:
2009/4/25 Andreas Heise aheise@gmx.de:
Klaus Darilion schrieb:
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!
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.
That's correct. Switching from UDP to TCP is correct with the standard but does not work.
regards klaus
-
Andreas Heise -
Daniel-Constantin Mierla -
Klaus Darilion -
Sandro Bordacchini -
Stanisław Pitucha -
Victor Pascual Ávila