Bug 20135 - Call fails if codec parameters are too big
Summary: Call fails if codec parameters are too big
Status: RESOLVED MOVED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: rakia (show other bugs)
Version: unspecified
Hardware: Other All
: low normal
Assignee: Mikhail Zabaluev
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-16 03:19 UTC by Sjoerd Simons
Modified: 2019-12-03 19:36 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Sjoerd Simons 2009-02-16 03:19:07 UTC
Hi,

  Theora has quite a big configuration string, so big that the INVITE 
  message gets truncated and the call fails :(.. A potential short-term fix might be to ignore codecs if the packet would get too big... I don't know enough about SIP to proprose a long-term solution :/
Comment 1 Mikhail Zabaluev 2009-02-16 03:28:43 UTC
I wonder if it's not a Theora codec problem.
Is there any authoritative spec on Theora RTP payload parameters?
Comment 2 Sjoerd Simons 2009-02-16 03:35:34 UTC
http://svn.xiph.org/trunk/theora/doc/draft-ietf-avt-rtp-theora-00.txt

It might be partially a theora issue of having a huge configuration, but having SIP calls fail if the SDP gets to big because of codecs is a bad thing in general imho 
Comment 3 Mikhail Zabaluev 2009-02-16 03:47:17 UTC
(In reply to comment #2)
> http://svn.xiph.org/trunk/theora/doc/draft-ietf-avt-rtp-theora-00.txt

The draft has long expired.
I can think of dropping a codec if the generated SDP lines for it are too big. But as it looks like a fragile change, I'm disinclined to do it for just one nonstandard payload. The approved RTP payload formats either produce fairly compact a=fmtp lines, or at least leave most of the parameters as optional.
Comment 4 Olivier Crête 2009-03-03 08:02:56 UTC
RFC 5215 (the Vorbis one) has the same problem. My idea solution would be to fall back to TCP and if it fails, remove the codecs one by one, starting with the longest until it fits.
Comment 5 Mikhail Zabaluev 2010-09-10 03:28:17 UTC
(In reply to comment #4)
> RFC 5215 (the Vorbis one) has the same problem. My idea solution would be to
> fall back to TCP

That's what the stack does already when the transport is not nailed down.

> and if it fails, remove the codecs one by one, starting with
> the longest until it fits.

I could think of handling the "message too big" responses this way, yes.
Comment 6 David Laban 2010-12-30 01:45:23 UTC
(In reply to comment #4)
> RFC 5215 (the Vorbis one) has the same problem. My idea solution would be to
> fall back to TCP and if it fails,

Falling back to tcp in order to send a jumbo invite turns out to be a bad idea. I think I'm going to deprecate the auto transport option, and set it to udp by default.

> remove the codecs one by one, starting with
> the longest until it fits.

I like this idea. I'll see what I can do. Do you think I should sort by codec id or something, or should I aim to keep the same proportion of the available packet length dedicated to each stream or what?
Comment 7 Mikhail Zabaluev 2010-12-30 04:02:37 UTC
(In reply to comment #6)
> (In reply to comment #4)
> > RFC 5215 (the Vorbis one) has the same problem. My idea solution would be to
> > fall back to TCP and if it fails,
> 
> Falling back to tcp in order to send a jumbo invite turns out to be a bad idea.

It would be a good idea accordingly to the spec... if proxies would actually support it. Many still don't, being effectively transport=udp destinations, but you can't know it without explicit configuration. Perhaps it would be nicer if "auto" tried TCP first with a short timeout and black/graylisted it if it does not work, but this requires some serious work in sofia-sip, not to mention changing the behavior which some sofia-sip clients probably rely on.

Forcing UDP by default will just make other cases fail with "message too big", because the message size exceeds the sanity limit in sofia-sip (1300 by default IIRC). With a properly set up proxy, those would work over the TCP fallback.

> I like this idea. I'll see what I can do. Do you think I should sort by codec
> id or something, or should I aim to keep the same proportion of the available
> packet length dedicated to each stream or what?

I think you should sort by length of the fmtp cruft. This will remove the worst offenders quickly :)
Maybe video streams are less important than audio, so they could start losing codecs first. If we are down to one codec, we could turn to audio, or drop the whole video stream to save even more bytes (you still need to put at least one payload number even for a rejected stream, but you can omit all the attributes).

Some other ideas for the UDP size crunch mode:

- Turn on abbreviated header names (full names are used by default);
- Suppress User-Agent
- Remove display name in From.

See also https://bugs.freedesktop.org/show_bug.cgi?id=30434 . We could shed a lot if only the codec intersection is passed to the answer.

Then, there is SigComp *wicked grin*
Comment 8 Olivier Crête 2010-12-30 09:04:47 UTC
That said, the problem is that with ICE, etc we will get a lot more of those large packets. So removing content is not really the solution.

Why not just send large UDP packets (up to 65536) if TCP fallback fails ? Yes, we will incur fragmentation, but its a lot better than sending truncated packets. Imho, this is a bug in sofiasip.
Comment 9 Mikhail Zabaluev 2011-01-03 04:58:39 UTC
(In reply to comment #8)
> That said, the problem is that with ICE, etc we will get a lot more of those
> large packets. So removing content is not really the solution.

True, though cutting back on unnecessary things (unabbreviated headers, descriptive information) may help even if packets end up fragmented.

> Why not just send large UDP packets (up to 65536) if TCP fallback fails ?

This is what RFC 3261 seems to suggest (as a to-be-deprecated behavior), but only in case when a TCP connection is explicitly rejected either with ICMP or a TCP reset. Many proxies or their gateway routers simply ignore TCP connection requests, resulting in the TCP connection attempt hanging until the SIP transaction times out. I haven't found anything in the specs that would specify TCP connection timeouts, but I think it could be set to something less than the transaction expiration timer.

> Yes,
> we will incur fragmentation, but its a lot better than sending truncated
> packets.

Do messages really get truncated?
I thought the stack just refuses to send them.
Comment 10 Mikhail Zabaluev 2011-01-03 05:00:28 UTC
(In reply to comment #7)
> Some other ideas for the UDP size crunch mode:

- Omit codec descriptions for the non-dynamic payload types defined in RTP/AVP.
Comment 11 Olivier Crête 2011-01-03 10:21:59 UTC
Either way, as a first step, we have no excuse to crop UDP packets under 65535 bytes.
Comment 12 Pekka Pessi 2011-01-10 14:29:35 UTC
(In reply to comment #7)
> It would be a good idea accordingly to the spec... if proxies would actually
> support it. Many still don't, being effectively transport=udp destinations, but
> you can't know it without explicit configuration. Perhaps it would be nicer if
> "auto" tried TCP first with a short timeout and black/graylisted it if it does
> not work, but this requires some serious work in sofia-sip, not to mention
> changing the behavior which some sofia-sip clients probably rely on.

Currently the Sofia-SIP *should* retry over UDP if TCP fails to connect within 5 seconds or so.
Comment 13 Mikhail Zabaluev 2011-01-11 04:43:47 UTC
(In reply to comment #12)
> Currently the Sofia-SIP *should* retry over UDP if TCP fails to connect within
> 5 seconds or so.

Can you point to a commit that has this implemented? Or, erm, make a new sofia-sip release? :)
Comment 14 GitLab Migration User 2019-12-03 19:36:19 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-rakia/issues/2.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.