Subject: [MMUSIC] What is an m-line?

From: Martin Thomson <[email-masked]>
Date: Mon, 13 May 2013 11:42:32 -0700

We've had a great deal of discussion about plan A and B and the
various interactions of these proposals with bundling.  But I still
don't get a good sense that there is a working consensus on what an
m-line actually represents.

I think that we've each reached our own conclusions, but they
definitely are not consistent.  We need a well-understood semantic for
m-lines if we have any chance of resolving these issues; Plan A/B
being only the first RTCWEB problem to address.

RFC 4566 is helpfully devoid of detail, so we are free to come up with
any interpretation we choose.  Here are the ones that I have seen:

 1. an m-line represents a single RTP session
    (or at least the part of the session that touches the client)
    This appears to be consistent with the Plan B approach

 2. an m-line represents the set of RTP streams that decode into a
single rendering, including layers, simulcast and FEC

 3. an m-line represents a single RTP stream; multiple m-lines might
be required to obtain a single rendering if it uses layers, simulcast,
FEC or FID groupings
    This appears to be consistent with the Plan A approach

In the first instance, an m-line can be multiple "things".  In the
latter two cases, an m-line is consistently one "thing" (or part
thereof).

The first interpretation has a natural advantage in terms of signaling
economy and natural bundling.  The latter interpretations seem to have
advantages in dealing with call transfer and SSRC renumbering.

So, which is correct?

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 May 2013 15:02:35 -0400

>      This appears to be consistent with the Plan B approach

Well, it was my impression that Plan B still intends to allow bundling 
in order to combine audio and video into a single RTP session. So in 
that case neither of the m-lines represents a single RTP session in full.

> single rendering, including layers, simulcast and FEC

Hmm. I was thinking *this* was what Cullen intended by Plan A.
But now that you bring it up, I thing there is some existing SDP syntax 
for simulcast/FEC/FID that might only work with (3). (But I don't have 
the details of that stuff in my head.)

>      This appears to be consistent with the Plan A approach

I offer another try:

4. an m-line represents one or more (zero or more?) 
sources/flows/tracks/captures (pick the name that suits you) that share 
a single RTP session and that all are consistent with the media 
description accompanying the m-line.

IIUC this is what Plan B is trying to achieve.

	Thanks,
	Paul

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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 13 May 2013 12:14:48 -0700

Martin said; 

> FEC or FID groupings. This appears to be consistent with the Plan A approach
> 

[BA] With respect to video, I believe that #1 is closer to what we see in existing implementations of simulcast and layered coding.  For that scenario, approach #3 could generate too many m lines.   Approach #1 is also consistent with the multicast scenarios envisaged in the early days of SDP, where multiple SSRCs could send to the same multicast address and port.    Where the mixer only puts out a single SSRC (e.g. audio or composited video), approach #2 is a degenerate case of #3.

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 13 May 2013 15:38:51 -0400

> that case neither of the m-lines represents a single RTP session in full.

Yes, the idea behind MMT was to preserve this interpretation of an m-line, even as we added a/v mux, rather than forcing descriptions of RTP sessions to be spread across multiple parts of the SDP.

The WG prefers BUNDLE to MMT, though, so I guess we're going to have to cope with description spreading, regardless of which of the current plans on that're on the table are accepted.

--
Jonathan Lennox
[email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 May 2013 13:45:24 -0700

On 13 May 2013 12:02, Paul Kyzivat <[email-masked]> wrote:
> Well, it was my impression that Plan B still intends to allow bundling in
> order to combine audio and video into a single RTP session. So in that case
> neither of the m-lines represents a single RTP session in full.

"In full" ain't gonna happen, ever :)  With RTP you are always the
blind man with his tiny piece of the elephant.  Hence, I think that
your (4) is a clearer description of what I intended to say.

> sources/flows/tracks/captures (pick the name that suits you) that share a
> single RTP session and that all are consistent with the media description
> accompanying the m-line.

> But now that you bring it up, I thing there is some existing SDP syntax for
> simulcast/FEC/FID that might only work with (3). (But I don't have the
> details of that stuff in my head.)

That existing stuff is what nudged this into a (3).  a=depend and a
few other things make it hard to get all the streams onto the one
line.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 May 2013 13:47:14 -0700

On 13 May 2013 12:14, Bernard Aboba <[email-masked]> wrote:
> [...] Approach #1 is also
> consistent with the multicast scenarios envisaged in the early days of SDP,
> where multiple SSRCs could send to the same multicast address and port.

Oops, I meant to try to head this line of reasoning off.  Let's talk
about offer/answer only.

I'd rather not boil two oceans.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 14 May 2013 13:58:48 +0000

People often want to look at this from the point of view of what they wish they can change SDP to mean, but unless we are doing SDPng, we need to look at it from the practical point of view of what has deployed and what SDP was defined as when that equipment deployed. We need to find a way that provided backwards interoperabiliyt while still allowing us to negotiate the things we want now. You can easily define an extension to SDP that means that RTP received on a single m line was meant to be rendered in differnt windows, but the fact of the matter remains that is not how lots of SIP equipment worked so you can't pretend SDP always meant that because it did not.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 May 2013 11:44:31 -0700

On 14 May 2013 06:58, Cullen Jennings (fluffy) <[email-masked]> wrote:
> People often want to look at this from the point of view of what they wish they can change SDP to mean,

That's the point of the question: what *is* an m-line?

Not: what do you want an m-line to be?

I suspect that the reality is an unstable superposition of states and
we will need to pick a winner.

--Martin

---

From: Colin Perkins <[email-masked]>
Date: Wed, 15 May 2013 12:02:59 +0100

>    This appears to be consistent with the Plan B approach

This is closest to my understanding, although an RTP session is defined by a shared SSRC space that can span multiple transport connections, so I don't think it's quite right. Perhaps "an m-line refers to one transport endpoint of a single RTP session"? 

(For example, in a simple two-party voice-only call with RTCP there are distinct m-lines, with different transport endpoints, in the offer and the answer. But, since there is a shared SSRC space across the sending and receiving RTP flows - which there has to be for RTCP to work - you have one RTP session.)

-- 
Colin Perkins
http://csperkins.org/

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 May 2013 12:03:39 -0400

> People often want to look at this from the point of view of what they wish they can change SDP to mean, but unless we are doing SDPng, we need to look at it from the practical point of view of what…

ISTM that there are two questions here:

- what is an m-line *without* bundle

- what is an m-line *within* a bundle

There are necessarily different, though of course our goal is to exploit 
some similarity between them.

My earlier reply with an alternative (4) was intended as an answer to 
what an m-line *within* a bundle is.

We clearly have different ideas of what a "legacy" m-line is.
Colin expressed a preference for (1). I guess that is probably a good 
proxy for what the "real RTP people" intended for it to be. My 
impression is that Fluffy most likely thinks (3) is closer to right, 
based on what is deployed in the sip world. The situation where what is 
deployed is different than what was intended isn't a new one. But its a 
hard one to come to grips with.

But what we most need to agree to is what a m-line will mean *within* a 
bundle.

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Wed, 15 May 2013 19:16:05 +0100

On 15 May 2013, at 17:03, Paul Kyzivat wrote:
> There are necessarily different, though of course our goal is to exploit some similarity between them.
> 
> My earlier reply with an alternative (4) was intended as an answer to what an m-line *within* a bundle is.
> 
> Colin expressed a preference for (1). I guess that is probably a good proxy for what the "real RTP people" intended for it to be. My impression is that Fluffy most likely thinks (3) is closer to right, based on what is deployed in the sip world.

It's not clear to me that the views are all *that* different, given the assumption/constraints of the devices. 

Colin

> The situation where what is deployed is different than what was intended isn't a new one. But its a hard one to come to grips with.
> 
> But what we most need to agree to is what a m-line will mean *within* a bundle.
> 
> 	Thanks,
> 	Paul
> 
>> 

-- 
Colin Perkins
http://csperkins.org/

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 15 May 2013 11:47:00 -0700

Colin said: 
"People often want to look at this from the point of view of what they wish they can change SDP to mean, but unless we are doing SDPng, we need to look at it from the practical point of view of what has deployed and what SDP was defined as when that equipment deployed. We need to find a way that provided backwards interoperability while still allowing us to negotiate the things we want now. You can easily define an extension to SDP that means that RTP received on a single m line was meant to be rendered in different windows, but the fact of the matter remains that is not how lots of SIP equipment worked so you can't pretend SDP always meant that because it did not."
[BA]  The reality is that "SIP equipment" covers an awful lot of ground.  There are implementations that use a single m line for video and can handle and render multiple SSRCs within that RTP session in different windows.   Emil has referred to one of those (Jitsi videobridge).  There are also implementations that use a single m line and support simulcast/layered coding, rendering SSRC groups (e.g. groupings of simulcast and layered sources) in different windows.   Several implementations of H.264/SVC work this way. 
So when people on the say "SIP equipment works this way" or "SDP works this way" or even "RTP works this way" my BS meter goes off.  Usually they mean "the equipment I'm familiar with works this way".   
I'm not sure we can make a definitive statement about what "backwards interoperability" means with respect to video systems today, at least without some work to survey existing implementations.  And this somewhat complicates the "Plan A" vs. "Plan B" discussion in RTCWEB, because the reality is that *neither* of these plans can achieve widespread "backwards interoperability" with respect to SDP, if what you mean by that is "I can take the SDP produced by a WebRTC implementation, throw it over the wire to an existing implementation and expect anything good to happen". 
IMHO, it is unrealistic to expect *any* implementation of the current WebRTC API to deliver that.  Until "comment 22" is resolved, SDP parsing/munging is going to be an unpleasant, time consuming but necessary task for interop with legacy equipment.  So as they said in Dr. Strangelove, "stop worrying and love the bomb". 
What I *would* like is for the RTP/RTCP produced by WebRTC implementations to not require a compute intensive media gateway/transcoder/munger to enable media to be handled by existing systems, at least when the same video codecs are available (and no, that shouldn't necessarily mean "video codec implementations based on the same source code", because the spec should be good enough to enable interoperability of independent implementations).

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 May 2013 11:53:29 -0700

> This is closest to my understanding, although an RTP session is defined by a shared SSRC space that can span multiple transport connections, so I don't think it's quite right. Perhaps "an m-line re…

That's why I said "at least the part of the session that touches the
client", but this is probably more correct given that the same session
can have multiple transport endpoints on the same endpoint, described
in the same SDP as different m-lines.

> (For example, in a simple two-party voice-only call with RTCP there are distinct m-lines, with different transport endpoints, in the offer and the answer. But, since there is a shared SSRC space ac…

This is a good point.  In offer/answer, this can clearly be two things
(as dictated by a=sendrecv).

I'd like to know how well this offer/answer usage scales.  Does this
extend to a three-party RTP session with the same characteristics?

---

From: Colin Perkins <[email-masked]>
Date: Wed, 15 May 2013 19:59:24 +0100

> Colin said: 

For the record, I think it was Cullen said this, although in a message I quoted. 

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 15 May 2013 22:04:44 +0200

On 05/15/2013 08:47 PM, Bernard Aboba wrote:
> <snip>
>
> So when people on the say "SIP equipment works this way" or "SDP works 
> this way" or even "RTP works this way" my BS meter goes off.  Usually 
> they mean "the equipment I'm familiar with works this way".
>
> I'm not sure we can make a definitive statement about what "backwards 
> interoperability" means with respect to video systems today, at least 
> without some work to survey existing implementations.  And this 
> somewhat complicates the "Plan A" vs. "Plan B" discussion in RTCWEB, 
> because the reality is that *neither* of these plans can achieve 
> widespread "backwards interoperability" with respect to SDP, if what 
> you mean by that is "I can take the SDP produced by a WebRTC 
> implementation, throw it over the wire to an existing implementation 
> and expect anything good to happen".

Bravo!

>
> IMHO, it is unrealistic to expect *any* implementation of the current 
> WebRTC API to deliver that.  Until "comment 22" is resolved, SDP 
> parsing/munging is going to be an unpleasant, time consuming but 
> necessary task for interop with legacy equipment.  So as they said in 
> Dr. Strangelove, "stop worrying and love the bomb".

I take a somewhat different approach:
If it's possible to *write an application* that uses the WebRTC 
interface, does not mangle the SDP, and sends that to an existing 
implementation (supporting SRTP and ICE), and has something useful 
happen, I think it's the success we can hope for.

This may mean having the application use content settings to force 
tracks to different m-lines, keep low the number of tracks offered, and 
other tricks that make sense in the context of *that application*.
It's the *application* that needs to interwork, it's not "WebRTC in 
general". WebRTC just needs to make it possible.

I see the idea that *any application* should produce SDP that's useful 
in such a scenario as an illusion, and pursuing that illusion is just 
going to hurt us.

>
> What I *would* like is for the RTP/RTCP produced by WebRTC 
> implementations to not require a compute intensive media 
> gateway/transcoder/munger to enable media to be handled by existing 
> systems, at least when the same video codecs are available (and no, 
> that shouldn't necessarily mean "video codec implementations based on 
> the same source code", because the spec should be good enough to 
> enable interoperability of independent implementations).

I find nothing to disagree with in this paragraph.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 15 May 2013 15:43:51 -0700

Harald said: 

"I take a somewhat different approach:

    If it's possible to *write an application* that uses the WebRTC
    interface, does not mangle the SDP, and sends that to an existing
    implementation (supporting SRTP and ICE), and has something useful
    happen, I think it's the success we can hope for." [BA] Since existing non-WebRTC audio applications typically have to do at least some SDP mangling,  WebRTC would be at parity if the SDP mangling is no worse than what is typically required today.  If we can reach that point with an audio application (which I think is plausible) then the situation would be tolerable, albeit not perfect.  The SDP mangling in the WebRTC sample application is at that level -- not pretty, but not shocking by any means.  For video, the non-WebRTC interop situation is much worse -- both SDP mangling (nastier than for audio) and RTP/RTCP mangling is typically involved, even for implementations of the same codec.  Since RTP/RTCP mangling is the really expensive operation, if this can be avoided, the cost of  interop can be brought way down.  In the non-WebRTC world, we are just reaching the point where this has become feasible, so I would set the WebRTC bar in roughly the same place - we may end up with more SDP mangling than is comfortable, but we need to avoid RTP/RTCP mangling if at all possible.  Harald also said:

    "This may mean having the application use content settings to force
    tracks to different m-lines, keep low the number of tracks offered,
    and other tricks that make sense in the context of *that
    application*.

    It's the *application* that needs to interwork, it's not "WebRTC in
    general". WebRTC just needs to make it possible." [BA] Right.  The reality is that most "applications" (90+ percent of them) won't need to put in this effort, so it just needs to be possible to achieve for those that do.   And as long as it is not necessary to touch every RTP packet in the process, we are just talking about a one-time application development cost that is "just software".  Harald finally said:

    "I see the idea that *any application* should produce SDP that's
    useful in such a scenario as an illusion, and pursuing that illusion
    is just going to hurt us." [BA] Agree. s/illusion/delusion/ :)

      

        What I *would* like is for
            the RTP/RTCP produced by WebRTC implementations to not
            require a compute intensive media gateway/transcoder/munger
            to enable media to be handled by existing systems, at least
            when the same video codecs are available (and no, that
            shouldn't necessarily mean "video codec implementations
            based on the same source code", because the spec should be
            good enough to enable interoperability of independent
            implementations).

---

From: Martin Thomson <[email-masked]>
Date: Thu, 16 May 2013 09:35:59 -0700

On 15 May 2013 15:43, Bernard Aboba <[email-masked]> wrote:
> Harald finally said:
>
> "I see the idea that *any application* should produce SDP that's useful in
> such a scenario as an illusion, and pursuing that illusion is just going to
> hurt us."
>
> [BA] Agree. s/illusion/delusion/ :)

I think that is a perfectly pragmatic conclusion to reach.  However,
it still leaves the issue open.  I'd like to at least reach a point
where there is agreement on just one model for interpreting the SDP
that is output and input to the WebRTC API.

If we have multiple interpretations, then we still need to reach
consensus on which one is the one we want to use.  That's a whole lot
harder if that is not "the one true interpretation", because someone
wont get what they want.

--Martin

p.s., It's been a long time, and I've been suppressing the urge, but I
can't help but think that Comment 22 is appropriate at this moment.

---

From: Emil Ivov <[email-masked]>
Date: Thu, 16 May 2013 19:44:29 +0300

> that is output and input to the WebRTC API.

If we agree that basing design decisions on legacy devices and their
view of what an m= line is (or rather isn't). Then is there any reason
not to accept the RTP-centric description of an m= line that Colin
described?

Emil

-- 
https://jitsi.org

---

From: Martin Thomson <[email-masked]>
Date: Thu, 16 May 2013 10:12:06 -0700

> not to accept the RTP-centric description of an m= line that Colin

Yes, it might be premature.  I'm not sure that we've explored all of
the implications of that statement.  For instance, no one has even
discussed call transfer scenarios yet.  We haven't explored the
consequences of SSRC collision.

We have to agree that the model we use actually fits the sorts of
things that need to fit.

---

From: Emil Ivov <[email-masked]>
Date: Thu, 16 May 2013 20:52:01 +0300

> consequences of SSRC collision.

Could you please be more specific about the sorts of problems you
expect and how they are caused by adhering to the basics of RTP?

> We have to agree that the model we use actually fits the sorts of

I always thought people agreed on that when they chose RTP for these
things, but again, I'd be very interested to hear about the problems
you expect.

Emil

--
https://jitsi.org

---

From: Martin Thomson <[email-masked]>
Date: Thu, 16 May 2013 11:01:06 -0700

> expect and how they are caused by adhering to the basics of RTP?

I'm not a strong proponent of these things, and I expect those
proponents to stand up and say something.  However, it is my
understanding that in a call transfer case, the arrival of a new SSRC
is treated as though the remote source has been switched out, not as
though a new participant has been added to the session.  The same has
to be true when a new SSRC is chosen in the case of a collision.

This is clearer when you talk about video.  Does the video from the
new SSRC go in the same window (/frame/<video> tag) as the existing
SSRC, or does it go in a new window?

---

From: Emil Ivov <[email-masked]>
Date: Thu, 16 May 2013 22:03:08 +0300

On 16.05.13, 21:01, Martin Thomson wrote:
> though a new participant has been added to the session. 

Correct, however this happens after prior signalling which pretty much
destroys the existing RTP session.

> The same has

Indeed and it seems to me the above also applies here since sources that
choose a new identifier would first end their existing session with a BYE.

> SSRC, or does it go in a new window?

Given that in both cases we have one session ending and another
commencing, I'd say that the natural way to handle this would be to have
one video component removed and another added.

Cheers,
Emil

-- 
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 May 2013 17:13:47 -0400

On 5/15/13 2:47 PM, Bernard Aboba wrote:
> Colin said:
>
> "People often want to look at this from the point of view of what they
> wish they can change SDP to mean, but unless we are doing SDPng, we need
> to look at it from the practical point of view of what has deployed and
> what SDP was defined as when that equipment deployed. We need to find a
> way that provided backwards interoperability while still allowing us to
> negotiate the things we want now. You can easily define an extension to
> SDP that means that RTP received on a single m line was meant to be
> rendered in different windows, but the fact of the matter remains that
> is not how lots of SIP equipment worked so you can't pretend SDP always
> meant that because it did not."
>
> [BA]  The reality is that "SIP equipment" covers an awful lot of ground.
>   There are implementations that use a single m line for video and can
> handle and render multiple SSRCs within that RTP session in different
> windows.   Emil has referred to one of those (Jitsi videobridge).  There
> are also implementations that use a single m line and support
> simulcast/layered coding, rendering SSRC groups (e.g. groupings of
> simulcast and layered sources) in different windows.   Several
> implementations of H.264/SVC work this way.
>
> without some work to survey existing implementations.  And this somewhat
> complicates the "Plan A" vs. "Plan B" discussion in RTCWEB, because the
> reality is that *neither* of these plans can achieve widespread
> "backwards interoperability" with respect to SDP, if what you mean by
> that is "I can take the SDP produced by a WebRTC implementation, throw
> it over the wire to an existing implementation and expect anything good
> to happen".

Perhaps the best we can do is acknowledge that the "legacy" use of RTP 
was underspecified, and so up to the application to sort out.

To move forward, maybe we can more carefully define what we want the 
m-line to mean going forward, and add some additional syntax (e.g. an 
attribute) that says this refined definition is being used. In an O/A 
context that would need to be confirmed in the answer.

That is for an unbundled m-line. A bundled m-line clearly has a 
different definition - presumably a subset of what an unbundled one is.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 May 2013 17:33:00 -0400

> SSRC, or does it go in a new window?

This does really get to the essence of the issue doesn't it?
(At least part of it.)

Note that in sip there are two ways to do a transfer:
- REFER, which leads to INVITE/Replaces
- 3pcc, which leads to just a reINVITE.

The INVITE/Replaces is much clearer that a change is required. The 
"Replaces" is a giveaway, and the new SDP should have a different 
session id. (But in cases where there are multiple media streams, mapped 
to distinct windows or devices, it may be hard to decide what to do.)

Its the reinvite case that you are talking about. Its only going to work 
if the handling of new SSRCs by the app is something that makes sense in 
the context of the application. That could be because the app only 
renders to one device, and always renders the most recently received 
SSRC. Or it could be because the app opens a new window for the new SSRC 
and (eventually) closes the old one. Or it could be that extra 
attributes in the SDP tell the application what to do.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 May 2013 17:40:39 -0400

I'd like people to keep one thing in mind:

RTCWEB has an independent mechanism that can be used to declare and/or 
negotiation some sort of consistency of intent between the two ends of a 
session. But native SIP applications don't. SDP is *the* way to agree 
about what is being done, and the semantics of the media that is being 
exchanged. So anything that might be done in a native SIP environment 
must be able to be negotiated without any prior knowledge prior to the 
SDP O/A. And even afterwards unless the application uses SDP to 
establish another means of negotiation. (As clue is doing.)

And to play with those native sip apps, RTCWEB needs to be able to 
generate and consume the same SDP.

	Thanks,
	Paul

On 5/15/13 6:43 PM, Bernard Aboba wrote:
> happen, I think it's the success we can hope for."
> [BA] Since existing non-WebRTC audio applications typically have to do
> at least some SDP mangling,  WebRTC would be at parity if the SDP
> mangling is no worse than what is typically required today.  If we can
> reach that point with an audio application (which I think is plausible)
> then the situation would be tolerable, albeit not perfect.  The SDP
> mangling in the WebRTC sample application is at that level -- not
> pretty, but not shocking by any means.
> For video, the non-WebRTC interop situation is much worse -- both SDP
> mangling (nastier than for audio) and RTP/RTCP mangling is
> typically involved, */even for implementations of the same codec./*
> Since RTP/RTCP mangling is the really expensive operation, if this can
> be avoided, the cost of  interop can be brought way down.  In the
> non-WebRTC world, we are just reaching the point where this has become
> feasible, so I would set the WebRTC bar in roughly the same place - we
> may end up with more SDP mangling than is comfortable, but we need to
> avoid RTP/RTCP mangling if at all possible.
> Harald also said:
>
> general". WebRTC just needs to make it possible."
> [BA] Right.  The reality is that most "applications" (90+ percent of
> them) won't need to put in this effort, so it just needs to be possible
> to achieve for those that do.   And as long as it is not necessary to
> touch every RTP packet in the process, we are just talking about a
> one-time application development cost that is "just software".
> Harald finally said:
>
> "I see the idea that *any application* should produce SDP that's useful
> going to hurt us."
>     that shouldn't necessarily mean "video codec implementations based
>     on the same source code", because the spec should be good enough to
> _______________________________________________ mmusic mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 17 May 2013 08:37:07 +0200

On 05/16/2013 11:40 PM, Paul Kyzivat wrote:
> negotiation some sort of consistency of intent between the two ends of 
> a session. But native SIP applications don't. SDP is *the* way to 
> agree about what is being done, and the semantics of the media that is 
> being exchanged.

Well.... Paul's previous message said:

"Note that in sip there are two ways to do a transfer:
- REFER, which leads to INVITE/Replaces
- 3pcc, which leads to just a reINVITE.

The INVITE/Replaces is much clearer that a change is required. The 
"Replaces" is a giveaway, and the new SDP should have a different 
session id. (But in cases where there are multiple media streams, mapped 
to distinct windows or devices, it may be hard to decide what to do.) "

It seems like in this case, the SIP headers influence the meaning of the 
SDP, so it's not 100% true that all the meaning is in the SDP.
Or did I miss some subtlety here?

> So anything that might be done in a native SIP environment must be 
> able to be negotiated without any prior knowledge prior to the SDP 
> O/A. And even afterwards unless the application uses SDP to establish 
> another means of negotiation. (As clue is doing.)
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 May 2013 11:22:15 -0400

> Or did I miss some subtlety here?

Yes and no.

The INVITE/Replaces is analogous to establishing a new PeerConnection 
and asking it to replace the old one. I guess you could say that the 
'Replaces' augments the SDP by saying 'bind this to the devices used in 
that other call'.

More generally, yes the SIP can influence the SDP interpretation a 
little bit. (E.g. by using SIP Options.) But it is a blunt instrument, 
and usually proposals to do so get argued down as layer violations. 
There certainly is no precision to delve down to influence individual 
m-lines.

	Thanks,
	Paul

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 23 May 2013 02:04:55 -0700

On Mon, May 13, 2013 at 12:02 PM, Paul Kyzivat <[email-masked]>wrote:

> for simulcast/FEC/FID that might only work with (3). (But I don't have the
        I think trying to describe a m=line based on the usage isn't the
right way. Since each approach, either Plan A or Plan B or Plan Z can
choose to add/remove aspects of the description in defining a m=line. In
general all the above can be m=line.

Media description as understood by RFC4566 is a way to describe aspects of
media stream from a sender to a receiver. It should be able to describe
    - underlying transport context
    - media context (encoder/decoder)
   most importantly

How such  description(s) is/are mapped to the underlying RTP session(s)  or
how is it mapped to source and sinks or how  relationships is established
is just a matter of choice as enforced by the usage.

Hence i feel this question turns out to be more philosophical to me :)

./Suhas

>> ______________________________**_________________
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>>
>>
> ______________________________**_________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>