20 Apr
2009
20 Apr
'09
8: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