[sip-comm-dev] SIP INVITE request - grows quite large


#1

Emil, dear SIP gurus,

during my tests with the latest SER (Kamailio) I put in a statement
to check the message length for SIP messages. I went for 1024 bytes
and this proved to be too small. Looking at a wireshark log I saw
that a current SIP INVITE with authentication, SDP for audio and video
(only 2 codec enabled, plus DTMS, ZRTP, audio-level) has a length
of more than 1200 bytes. My DSL MTU ist 1492, my IPv6 MTU is 1280
(IPv6 tunnel). Thus we are approaching a critical length, maybe for
mobile devices it's already crossed.

Switching off the ZRTP SDP attribute would save 180 bytes, this doesn't
harm ZRTP, only in case somebody has Phil's zfone installed and activated.

Any other ideas how the reduce SIP length (I vaguely remember that there
is a RFC that describes a sort of "SIP compression")?

Regards,
Werner

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hi Emil,

Emil, dear SIP gurus,

during my tests with the latest SER (Kamailio) I put in a statement
to check the message length for SIP messages. I went for 1024 bytes
and this proved to be too small. Looking at a wireshark log I saw

....

I don't think that this would really help in a significant way. Your IP
stack would will also try to help by fragmenting the packets but some
routers drop IP fragments.

We should try to avoid packet fragmenting - I know that in mobile networks
this leads to very slow connections because they are not very good at that
(because if one fragment is disturbed the whole IP packet has to be resent).

And in IPv6 the routers don't even fragment the packets - they raise an
error and the source node has to do it. This could lead to quite some
overhead.

The only real way around the issue is using TCP. Unfortunately many of
the existing deployments out there do not currently handle TCP (or
handle it badly). Reasons for this are historical rather than normative
since 3261 mandates TCP support. Jain-sip would even try to switch to
TCP for long messages but that doesn't help if the server doesn't
listen. SIP outbound also goes for TCP so I hope that the trends are
changing.

So do I. Does Jain SIP provides configuration parameters to set TCP parameters
e.g. packet size to match the MTU restrictions (I don't think Jain SIP performs
a MTU discovery)?

IMHO, neglecting TCP was mainly due to "performance" because many developers
argue that setup of a TCP connection has so much overhead and this would be
harmful to larger SIP servers, it would take too much time to set-up a SIP
call, etc etc.

Regards,
Werner

···

Am 10.06.2010 19:53, schrieb Emil Ivov:

On 10 juin 2010, at 19:09, Werner Dittmann <Werner.Dittmann@t-online.de> > wrote:

Emil

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

На 10.06.10 20:44, Werner Dittmann написа:

We should try to avoid packet fragmenting

Yes, this was also my point.

So do I. Does Jain SIP provides configuration parameters to set TCP parameters

This is generally handled by the TCP stacks. If you meant UDP then you
can try setting the gov.nist.javax.sip.SEND_UDP_BUFFER_SIZE property.

Cheers,
Emil

···

e.g. packet size to match the MTU restrictions (I don't think Jain SIP performs
a MTU discovery)?

IMHO, neglecting TCP was mainly due to "performance" because many developers
argue that setup of a TCP connection has so much overhead and this would be
harmful to larger SIP servers, it would take too much time to set-up a SIP
call, etc etc.

Regards,
Werner

Emil

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi guys,

Couldn't resist, sorry... Let's go IPv6 !

And in IPv6 the routers don't even fragment the packets - they raise an
error and the source node has to do it. This could lead to quite some
overhead.

Yes and no. Of course the node has to do the fragmentation by himself,
but this lightens the burden on routers on the path, and gives you the
extra bonus of being able to reconstruct out-of-sequence data on the
other end of the connection. Unfortunately, the price to pay is pmtu
discovery... Have to weigh this up against TCP overhead. By the way,
this is only valid for IPv6 fragmenting.

Okay, I realize this didn't help the discussion very much, sorry !

Cheers anyway,
jean

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net