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 :/
I wonder if it's not a Theora codec problem. Is there any authoritative spec on Theora RTP payload parameters?
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
(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.
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.
(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.
(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?
(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*
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.
(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.
(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.
Either way, as a first step, we have no excuse to crop UDP packets under 65535 bytes.
(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.
(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? :)
-- 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.