After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 341518 - TCP support for sip
TCP support for sip
Status: RESOLVED WONTFIX
Product: ekiga
Classification: Applications
Component: general
unspecified
Other All
: Normal major
: ---
Assigned To: Ekiga maintainers
Ekiga maintainers
gnome[unmaintained]
: 346874 496369 544209 586104 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-05-12 05:40 UTC by Heikki Paajanen
Modified: 2020-06-06 16:31 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Heikki Paajanen 2006-05-12 05:40:37 UTC
Some servers (for example live communications server 2003) only support TCP for
sip although I have think standard mandates both TCP and UDP. 
I couldn't find anyway to specify protocol to be TCP when registering or calling
with ekiga.
Comment 1 Damien Sandras 2006-05-12 11:29:45 UTC
It is on the TODO.
Comment 2 Jan Schampera 2006-12-26 19:42:07 UTC
*** Bug 346874 has been marked as a duplicate of this bug. ***
Comment 3 Damien Sandras 2008-09-05 07:44:49 UTC
*** Bug 496369 has been marked as a duplicate of this bug. ***
Comment 4 Damien Sandras 2008-09-15 18:16:22 UTC
*** Bug 544209 has been marked as a duplicate of this bug. ***
Comment 5 Eugen Dedu 2009-06-17 11:18:45 UTC
*** Bug 586104 has been marked as a duplicate of this bug. ***
Comment 6 Yannick 2009-07-10 09:05:55 UTC
Hi,

It appears the MTU size can vary along the path, switching to TCP if only UDP size is >1500 wont cover all cases since some hops may have an MTU inferior to 1500.

A simple workaround would be to take a more safer value. It seems 1400 is more safer, but still do not cover all cases.

IMHO a proper fix is to use a discovery mechanism for the MTU:
"Packetization Layer Path MTU Discovery"
   This document describes a robust method for Path MTU Discovery
   (PMTUD) that relies on TCP or some other Packetization Layer to probe
   an Internet path with progressively larger packets.  This method is
   described as an extension to RFC 1191 and RFC 1981, which specify
   ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively.

http://tools.ietf.org/html/rfc4821

Best regards,
Yannick
Comment 7 Eugen Dedu 2009-07-10 10:06:18 UTC
We do not need to worry about packets rejected on routers, because there the IP fragmentation comes into play.  We need only to worry about packets which do not leave the source machine, such as UDP on gnu/linux with higher than 1500 bytes and classical Ethernet.
Comment 8 Yannick 2009-08-07 17:43:54 UTC
Hi,

I made a test with Ekiga 3.2.0 from the latest Ubuntu release (Jaunty 9.04), with all the codecs it offers (only the free ones and not even all as CELT is not available in default packaging). As a result the PDU exceed 1500, still it works for me (I can call 500):

There is people having issue with this; available features can lead to call failure, packaging might be a workaround (codecs enabled by default). Still, simply using available options from the GUI can lead to application breakage for the call feature.

I'm still investigating further the issue...

Relevant part of the debug output:

2009/08/07 19:34:20.020	  0:12.790	  Aggregator:0xb4d81b90	SIP	PDU is too large (1578 bytes) trying compact form.
2009/08/07 19:34:20.023	  0:12.793	  Aggregator:0xb4d81b90	OpalPlugin	to_customised_options: theora
2009/08/07 19:34:20.030	  0:12.801	  Aggregator:0xb4d81b90	OpalPlugin	to_customised_options: H.261
2009/08/07 19:34:20.037	  0:12.807	  Aggregator:0xb4d81b90	SIP	PDU is likely too large (1536 bytes) for UDP datagram.
2009/08/07 19:34:20.037	  0:12.807	  Aggregator:0xb4d81b90	SIP	Sending PDU (1536 bytes) to: rem=udp$86.64.162.35:5060,local=udp$82.239.207.217:5060,if=82.239.207.217%eth0
INVITE sip:500@ekiga.net SIP/2.0

Date: Fri, 07 Aug 2009 17:34:19 GMT

CSeq: 2 INVITE

v: SIP/2.0/UDP 82.239.207.217:5060;branch=z9hG4bK3e19f934-e681-de11-8170-002185488b80;rport

User-Agent: Ekiga/3.2.0

f: "Defais Yannick" <sip:yannick@ekiga.net>;tag=f80e9034-e681-de11-8170-002185488b80

i: cc589034-e681-de11-8170-002185488b80@myrmidon

t: <sip:500@ekiga.net>

m: <sip:yannick@82.239.207.217>

Proxy-Authorization: Digest username="yannick", realm="ekiga.net", nonce="4a7c66c7000002ccac498b1778f8210fa5771574fba5c5cd", uri="sip:500@ekiga.net", algorithm=MD5, response="299a44b07499e11bf69cdbf10cf45200"

Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING

c: application/sdp

l: 801

Max-Forwards: 70



v=0

o=- 1249666459 1249666459 IN IP4 82.239.207.217

s=Opal SIP Session

c=IN IP4 82.239.207.217

t=0 0

m=audio 5062 RTP/AVP 104 9 115 3 0 8 114 103 102 118 101 120

a=sendrecv

a=rtpmap:104 G726-16/8000/1

a=rtpmap:9 G722/8000/1

a=rtpmap:115 Speex/16000/1

a=fmtp:115 sr=16000,mode=any

a=rtpmap:3 gsm/8000/1

a=rtpmap:0 PCMU/8000/1

a=rtpmap:8 PCMA/8000/1

a=rtpmap:114 Speex/8000/1

a=fmtp:114 sr=8000,mode=any

a=rtpmap:103 G726-24/8000/1

a=rtpmap:102 G726-32/8000/1

a=rtpmap:118 G726-40/8000/1

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16,32,36

a=rtpmap:120 NSE/8000

a=fmtp:120 192-193

m=video 5064 RTP/AVP 99 31

a=sendrecv

a=rtpmap:99 theora/90000

a=fmtp:99 delivery-method="in_band";height=576;sampling="YCbCr-4:2:0";width=704

a=rtpmap:31 h261/90000

a=fmtp:31 CIF=1;QCIF=1
Comment 9 Yannick 2009-08-07 17:53:30 UTC
here is my MTU setting:

% ifconfig
eth0      Link encap:Ethernet  HWaddr *****************  
          inet adr:82.239.207.217  Bcast:82.239.207.255  Masque:255.255.255.0
          adr inet6: fe80::221:85ff:fe48:8b80/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
Comment 10 Eugen Dedu 2009-08-07 18:39:43 UTC
There *is* TCP support in OPAL, but it is not yet tested.  http://mail.gnome.org/archives/ekiga-devel-list/2009-July/msg00004.html and the following.  I plan to test it next week, right after the new release.
Comment 11 Yannick 2009-08-07 19:20:57 UTC
Example of a user having this issue with default config from ubuntu:

https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/380091/comments/9

"I wanted to confirm this so I booted from clean live USB memory stick image (Jaunty).
Selected ekiga for installation.
Synaptic informs that the following are required: libgsm1, libopal3.6.1, libpt2.6.1, libpt2.6.1-plugins-alsa, libpt2.6.1-plugins-v4l2. (All of these come from the Main repository).

Once above are installed: Ekiga has the same problem as described above (PDU exceed 1500) and same solution as you describe above also works.

Out-of-the-box Audio codecs: G722, Speex(16kHz), PCMA, PCMU, G726-16, G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz).

Out-of-the-box Video codecs: h261, theora.

So, in answer to your question, only using default packages from Ubuntu is sufficient for PDU to exceed 1500."

It seems, as least for ubuntu, all codecs are enabled by default. I've not investigate yet to check if there is a particular patch related to default codecs enabled in the ubuntu packaging. Still I doubt there is such thing.
Comment 12 Yannick 2009-08-09 09:55:23 UTC
Standard behaviour for TCP use is defined as:
http://tools.ietf.org/html/rfc3261#section-18.1.1
"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. For UDP, this size is 65,535 bytes, including
   IP and UDP headers."

Beside I have a report when someone is using local MTU of 7000, with a PDU of ~1600, and there is a failure. Eugen said IP with do fragmentation but "In a case where a router receives a protocol data unit (PDU) larger than the next hop's MTU, it has two options if the transport is IPv4. Drop the PDU and send an Internet Control Message Protocol (ICMP) message which indicates "Packet too Big", or to fragment the IP packet and send over the link with a smaller MTU."
http://en.wikipedia.org/wiki/IP_fragmentation
Is Ekiga dealing well with ICMP message which indicates "Packet too Big"?
In this case the GUI error message was simply "User Not Available."
Relevant -d 4 for this case:
http://launchpadlibrarian.net/28896426/ekiga-debug5-allcodecs-launchpad.txt

Best regards,
Yannick
Comment 13 Yannick 2009-08-09 12:04:02 UTC
Hi,

About how Ekiga should react to ICMP message indicating "Packet too big", I find this part of the SIP RFC relevant:
http://tools.ietf.org/html/rfc3261
8.1.3.1 Transaction Layer Errors

   In some cases, the response returned by the transaction layer will
   not be a SIP message, but rather a transaction layer error.  When a
   timeout error is received from the transaction layer, it MUST be
   treated as if a 408 (Request Timeout) status code has been received.
   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.

I'm not sure, but it seems Ekiga treats ICMP fatal error as 408 while it should treat them as 503.

Best regards,
Yannick
Comment 14 Yannick 2010-05-20 16:44:45 UTC
*** Bug 591261 has been marked as a duplicate of this bug. ***
Comment 15 Francis Moreau 2015-04-09 10:04:42 UTC
sorry for resurecting this one, but what's its status ?

I'm running ekiga 4.0.1 and I'm hit by this bug and actually can't select another codec to get smaller packets (I got "No common codec" message).

Thanks
Comment 16 Eugen Dedu 2015-04-09 10:17:43 UTC
It is being worked on.

Have you also tried checking off some *video* codecs to reduce packet size?
Comment 17 Francis Moreau 2015-04-10 08:08:43 UTC
wow, the bug had been opened almost 9 years ago ! no offense, but is it going to fixed soon (ETA < 6 months) ?

I disabled all video codecs and that did the trick. I didn't think about it because I don't use video.

Now the joke is that I can receive some calls, it rings here, I get a notification about the incoming call, but I can't answer, there's no 'answering' button anywhere :-/
Comment 18 Eugen Dedu 2015-04-10 08:45:54 UTC
(In reply to Francis Moreau from comment #17)
> wow, the bug had been opened almost 9 years ago ! no offense, but is it
> going to fixed soon (ETA < 6 months) ?

As far as I understand, TCP support is already in, but has some bugs we are currently fixing.  So I think it will be ok in the new development release, hopefully in a few months.

> I disabled all video codecs and that did the trick. I didn't think about it
> because I don't use video.

The solution is to fix TCP, the object of this bug.  

> Now the joke is that I can receive some calls, it rings here, I get a
> notification about the incoming call, but I can't answer, there's no
> 'answering' button anywhere :-/

This is surely because the notification is broken on your machine.  Given that this problem appeared for several people, we finally decided not to use notifications alone anymore.  So in current development code, Ekiga can answer calls without notifications.

The solution is to get a new development release, and hopefully in a few months we will have one.
Comment 19 Francis Moreau 2015-04-10 08:49:40 UTC
FYI, my system is using i3-wm.

Good luck for the next release.
Comment 20 André Klapper 2020-06-06 16:31:16 UTC
Ekiga is not under active development anymore:
https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/273

Ekiga saw its last release 7 years ago. The last code commits were 4 years ago.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (and transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active Ekiga development again in the future.