<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Olle E. Johansson wrote:
<blockquote cite="mid:BBBE175A-B69C-4CEA-A691-EF027470C1AB@edvina.net"
type="cite">
<pre wrap="">9 sep 2009 kl. 23.02 skrev Mark Michelson:
</pre>
<blockquote type="cite">
<pre wrap="">David Vossel wrote:
</pre>
<blockquote type="cite">
<pre wrap="">----- "Kevin P. Fleming" <a class="moz-txt-link-rfc2396E" href="mailto:kpfleming@digium.com"><kpfleming@digium.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Mark Michelson wrote:
</pre>
<blockquote type="cite">
<pre wrap="">An even better idea would be to actually answer all streams, making
</pre>
</blockquote>
<pre wrap="">sure to use
</pre>
<blockquote type="cite">
<pre wrap="">a 0 port for any streams of a certain type beyond the first. The
</pre>
</blockquote>
<pre wrap="">trouble with
</pre>
<blockquote type="cite">
<pre wrap="">this is that chan_sip is not written to handle multiple streams of
</pre>
</blockquote>
<pre wrap="">the same type
</pre>
<blockquote type="cite">
<pre wrap="">at all. This means the changes would be far more invasive. With
</pre>
</blockquote>
<pre wrap="">chan_sip being
</pre>
<blockquote type="cite">
<pre wrap="">the house of cards that it is, plus the fact that this isn't
exactly
</pre>
</blockquote>
<pre wrap="">the most
</pre>
<blockquote type="cite">
<pre wrap="">pressing issue I've seen, I'm inclined to go with the reporter's
</pre>
</blockquote>
<pre wrap="">solution unless
</pre>
<blockquote type="cite">
<pre wrap="">there are strong objections.
</pre>
</blockquote>
<pre wrap="">The most serious objection is that this is non-conformant with RFC
3264
(as is our current implementation). If an SDP offer contains 'n' m=
lines, the answer MUST also contain 'n' m= lines. The answerer may
choose to decline any or all of those media stream offers by setting
them to port number 0 (and marking them as 'a=inactive' may not hurt
as
an additional measure), but it must respond to all of them.
Failing to do so leads to exactly the sort of problem being
discussed
here; the offerer cannot conclusively determine which streams the
answerer is accepting.
We do not need to make chan_sip able to actually multiple *active*
streams of the same type, but if our goal is to be RFC compliant, we
should absolutely record the 'm=' line information for each offered
stream and ensure that our answer includes each one, properly marked
as
'declined'. Whether this requires also including all the 'a=' lines
for
each stream I don't really know, but I suspect they would not be
required.
</pre>
</blockquote>
<pre wrap="">I agree, the real fix here is to at least respond to all media
streams regardless if we are accepting them or not. Like OEJ has
mentioned, given our current architecture even simply responding
with rejected media streams is not a simple task. Given that our
current SDP parser is not RFC compliant, and the simple fix of only
responding to the first media stream of each type supported is
proven to give Asterisk a little better interoperability, does this
not sound like a valid change to be made until an architecture
change can be made in the future?
~Vossel
</pre>
</blockquote>
<pre wrap="">Well, the problem is one that I brought up with you earlier. By
responding only
to the first media stream of a given type, the offerer is still not
guaranteed
to parse the reply "correctly." The user agent in the reporter's
example works
appropriately in the situation, but we can't rely on user agents to
all
interpret such a cryptic answer the same way.
Here's an idea for how to approach this. First, don't even touch
1.4, since the
problem there is much different (it will respond with a 488 if an
audio stream
and two video streams are offered). For 1.6.X, I think you could
follow oej's
suggestion regarding having a configuration option which users can
set if they
know that their UA will properly handle only having the first media
stream of a
type answered. For trunk, I would suggest to do the right thing: do
deeper work
to make sure all media streams for a given type at least have an
answer, even if
all but one stream is rejected (though not necessarily the first
stream
offered). I also would recommend waiting until 1.6.3 is branched
before merging
this work into trunk so that there is more time for it to be out
there before
being part of a branch.
Also, on a side note, I checked RFC 4317 like oej suggested, and in
those
examples, the a= lines *are* echoed for rejected media streams.
</pre>
</blockquote>
<pre wrap=""><!---->And, to repeat myself, in order to make sure that we answer everything
properly, including totally to us unknown media streams, we need to
save it in text format.
/O
</pre>
</blockquote>
<br>
I think it would be good occasion to implement better handling of fmtp
attributes for streams<br>
handled in transparent way. I mean that if endpoint A calling
endpoint B has a fmtp attribute in video stream descriptor it should be
fowarded to B by asterisk.<br>
Today it is scrapped.<br>
<br>
<br>
Thanks<br>
Vadim <br>
<br>
</body>
</html>