[Bug 20135] Call fails if codec parameters are too big

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=20135

--- Comment #9 from Mikhail Zabaluev <mikhail.zabaluev at nokia.com> 2011-01-03 04:58:39 PST ---
(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.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.