Subject: RE: Sharing ports between "m=" lines [Was Re: [MMUSIC] Re: Questi on on sdp-new}

From: "Elwell, John" <[email-masked]>
Date: Thu, 19 Jan 2006 17:52:16 +0000

Flemming,

I will just comment on one point:

<snip/> 
> I like the capabilities I get by using the triple <IP address, port 
> number, media type>, but it leaves open some issues, which I 
> think the 
> current sdp-new text was trying to avoid (and which you 
> address below). 
> For example, if I indicate RTP/AVP and RTP/SAVP as alternatives and I 
> now receive a media packet, which profile is it actually 
> encoded under ? 
> Do payload type mappings have to be the same between these 
> alternatives 
> ? In general, once I allow for quite a bit of variability in the 
> parameters included in these alternatives, it becomes potentially 
> problematic to use them not only outside offer/answer, but 
> also within 
> offer/answer if I want to support receiving media prior to 
> receiving the 
> answer.
[JRE] Is this an argument for saying that we need to be able to group media
as equals even if they have diffent addresses?

<snip/>

John

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 19 Jan 2006 12:13:20 -0800

> > I like the capabilities I get by using the triple <IP address,
> > port number, media type>, but it leaves open some issues, which I
> > think the current sdp-new text was trying to avoid (and which you
> > address below).  For example, if I indicate RTP/AVP and RTP/SAVP
> > as alternatives and I now receive a media packet, which profile is
> > it actually encoded under ? Do payload type mappings have to be
> > the same between these alternatives ? In general, once I allow for
> > quite a bit of variability in the parameters included in these
> > alternatives, it becomes potentially problematic to use them not
> > only outside offer/answer, but also within offer/answer if I want
> > to support receiving media prior to receiving the answer.
>
> [JRE] Is this an argument for saying that we need to be able to
> group media as equals even if they have diffent addresses?

RFC4091 does that already -- it groups media lines as equal even 
when those media lines have different addresses.  RFC4091 restricts
itself to grouping IPv4 and IPv6 addresses, though.

-d

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 20 Jan 2006 08:30:34 -0500

>as equals even if they have diffent addresses?
It's certainly a solution (and probably the easiest and most backwards 
compatible one too) to the problem of supporting "incompatible" profiles 
and media before receiving an answer at the same time, and based on all 
the discussions that have been (and still are) going on around avoiding 
preconditions, it seems solving this problem is a real-life requirement.

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 20 Jan 2006 08:34:52 -0500

>itself to grouping IPv4 and IPv6 addresses, though.
Right. More precisely:
<quote>
   The ANAT semantics MUST NOT be used to group media streams whose
   network addresses are of the same type.
</quote>
Thus RFC 4091 does not solve the general case John describes above (e.g. 
two different profiles both using IPv4 addresses).

-- Flemming