Subject: [MMUSIC] Wisdom sought: Prioritization of codecs

From: Harald Alvestrand <[email-masked]>
Date: Thu, 15 Nov 2012 09:47:28 +0100

I've been searching RFC 4566 (SDP) for this info, but came up blank....

in an M-line, we typically have

m=video blabla 111 112 113
a=rtpmap:111 ....
a=rtpmap:112 ...
a=rtpmap:113 ....

Section 5.14 says this:

       If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt>
       sub-fields contain RTP payload type numbers.  When a list of
       payload type numbers is given, this implies that all of these
       payload formats MAY be used in the session, but the first of these
       formats SHOULD be used as the default format for the session.

Now, the questions...

1) In offer/answer, does this sequence in an offer mean that the offerer 
prefers that the answerer use codec 111, if supported?

2) in offer/answer, does this sequence in an answer mean that the 
answerer prefers that the offerer use codec 111?

3) is there any preference expressed between codec 112 and codec 113?

4) Should the sequence of a=rtpmap: lines be completely ignored, or does 
it matter?

I'm trying to fix a bug, and want to make sure I fix it according to spec.

                Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 15 Nov 2012 09:57:35 +0100

Found some answers in RFC 3264.

On 11/15/2012 09:47 AM, Harald Alvestrand wrote:
> 1) In offer/answer, does this sequence in an offer mean that the 
> offerer prefers that the answerer use codec 111, if supported?

3264 5.1:

    In all cases, the formats in the "m=" line MUST be listed in order of
    preference, with the first format listed being preferred.  In this
    case, preferred means that the recipient of the offer SHOULD use the
    format with the highest preference that is acceptable to it.

> answerer prefers that the offerer use codec 111?
3264 6.1:

   The
    media formats in the "m=" line MUST be listed in order of preference,
    with the first format listed being preferred.  In this case,
    preferred means that the offerer SHOULD use the format with the
    highest preference from the answer.

> 3) is there any preference expressed between codec 112 and codec 113?
Clear from 3264. If we ever update 4566, might want to harmonize those.
>
> 4) Should the sequence of a=rtpmap: lines be completely ignored, or 
> does it matter?

I hope the answer is "completely ignored", have found no evidence to the 
contrary.

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

---

From: "Horvath, Ernst" <[email-masked]>
Date: Thu, 15 Nov 2012 09:05:07 +0000

Harald,

RFC 3264 states that codecs are listed in order of preference, most preferred first, in both offer and answer. When selecting the acceptable codecs from the offered list the answerer should keep the order unless there is good reason not to do so. The offerer must be prepared to receive an answer with codecs arranged in a different order. Although both sides can then use any of the negotiated codecs it is recommended they use the first in the list.

Regards,
Ernst

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: Donnerstag, 15. November 2012 09:47
To: mmusic
Subject: [MMUSIC] Wisdom sought: Prioritization of codecs

Section 5.14 says this:

Now, the questions...

1) In offer/answer, does this sequence in an offer mean that the offerer prefers that the answerer use codec 111, if supported?

2) in offer/answer, does this sequence in an answer mean that the answerer prefers that the offerer use codec 111?

4) Should the sequence of a=rtpmap: lines be completely ignored, or does it matter?

               Harald

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 15 Nov 2012 11:12:57 -0500

> Found some answers in RFC 3264.
That's the right place to look assuming this is all for use in an 
Offer/Answer context.

> Clear from 3264. If we ever update 4566, might want to harmonize those.
4566bis is work-in-progress - do you see a disconnect between 4566 and 
3264 (or are you just looking to repeat the information in 4566) ?

> I hope the answer is "completely ignored", have found no evidence to 
> the contrary.
>
It should not matter, but I don't think we have any text explicitly 
stating that anywhere.

-- Flemming

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Nov 2012 11:57:40 -0500

Harald,

While the specs aren't entirely clear, after some searching and study 
they become *reasonably* clear as you have found. But this is only true 
in the context of a particular usage profile - that the RTP session will 
contain only one RTP stream, and that stream will use only a single codec.

If you move outside of that usage profile then the existing text is 
really deficient. And we are often outside that profile. One example is 
telephone-events. That is a separate "codec" that is never used alone, 
it is always used in conjunction with another codec. You may prefer G711 
for most audio, but still prefer telephone-events for DTMF tones.

The whole notion of codec preference breaks down even more for 
multiplexed streams. You may very explicitly prefer/require different 
streams to use different codecs.

So I don't think we can rely too much on parsing the existing text for 
guidance on how to use SDP to represent multiplexed sessions. (Unless of 
course we use bundle, with a separate m-line for each stream.) AFAIK we 
are breaking new ground here.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Thu, 15 Nov 2012 13:55:01 -0600

On 11/15/12 10:57, Paul Kyzivat wrote:
> guidance on how to use SDP to represent multiplexed sessions. (Unless 
> of course we use bundle, with a separate m-line for each stream.) 
> AFAIK we are breaking new ground here.

This kind of "we fixed this problem once and get to fix it all over 
again" issue is exactly the kind of thing I was speaking to at the 
microphone in MMUSIC in Atlanta. The further we drift from the 
established semantics of SDP, the less applicable previously developed 
mechanisms become. Bundle and similar approaches that maintain one m= 
line per stream allow us to leverage 14 years of extensions and 
clarifications. If we decide to split from that (rather fundamental, 
IMHO) characteristic of SDP, we are effectively forking the protocol, 
and throwing away years of prior work.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Nov 2012 16:32:40 -0500

> and throwing away years of prior work.

I would like to agree with you. But when multiplexing RTP streams it is 
problematic to prearrange every stream in SDP. That requires knowing in 
advance how many there will be, what their SSRCs will be, and what the 
mapping from SSRC to codec will be.

We are still thrashing that out for CLUE. We have some use cases where 
it seems we can't do all of that in advance, and doing an O/A after we 
get packets is too late. Maybe we will find a way around that. Too early 
to tell.

And AFAIK RTCWEB has only been planning to use bundle to give a separate 
m-line for audio and one for video, not necessarily a separate one for 
every media stream. I think there is still an implication that a given 
m-line might be multiplexed, and might use different codecs (among those 
that are negotiated) for the different multiplexed streams.

And even our 14 years of experience on this haven't resulted in a spec 
that fully lines up with what is deployed in the wild. There is an 
assumption in the specs that if you offer multiple codecs and the answer 
accepts multiple codecs, then you can accept packets in any of the 
negotiated codecs, and switch among them, even though we know 
implementations that depend on only one codec being used. (With a 
special case for telephone-events.)

We are now encountering applications that have more complex needs than 
were anticipated over those 14 years. It's nice if we can reuse what we 
have without change to meet those needs. But lets not constrain new 
applications to the sorts of things we had in mind 14 years ago.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Thu, 15 Nov 2012 15:53:19 -0600

On 11/15/12 15:32, Paul Kyzivat wrote:
> I would like to agree with you. But when multiplexing RTP streams it 
> is problematic to prearrange every stream in SDP. That requires 
> knowing in advance how many there will be, what their SSRCs will be, 
> and what the mapping from SSRC to codec will be.
>
> get packets is too late. Maybe we will find a way around that. Too 
> early to tell.

I need to catch up on CLUE before I can talk to that very much. I'd been 
pretty much ignoring CLUE; but in Atlanta, it became clear that CLUE's 
impact was going to seep out into every other working group in RAI.

> And AFAIK RTCWEB has only been planning to use bundle to give a 
> separate m-line for audio and one for video, not necessarily a 
> separate one for every media stream.

I don't think that's a settled question.

> assumption in the specs that if you offer multiple codecs and the 
> answer accepts multiple codecs, then you can accept packets in any of 
> the negotiated codecs, and switch among them, even though we know 

True. It would be good if we could document this set of unstated 
assumptions as a "current practices" document at some point (note the 
lack of "best" before "current practices").

> were anticipated over those 14 years. It's nice if we can reuse what 
> we have without change to meet those needs. But lets not constrain new 

I don't think it's necessary to do so. I've spent some time thinking on 
this problem, and have a half-formed proposal that I plan to bring forth 
once I'm more comfortable that it provides a satisfying user experience.

I just think we're rushing down a path of throwing out a lot of good to 
get rid of a little bit of bad. I'd like to see more discussion around 
less radical changes to SDP to achieve the goals of CLUE and RTCWEB.

/a

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 19 Nov 2012 06:12:52 +0100

On 11/15/2012 08:55 PM, Adam Roach wrote:
>> So I don't think we can rely too much on parsing the existing text 
>> for guidance on how to use SDP to represent multiplexed sessions. 
>> (Unless of course we use bundle, with a separate m-line for each 
>> stream.) AFAIK we are breaking new ground here.
>
actually my caricature of the history of SDP is 4 years of multicast, 
where multiple streams per RTP session was the norm, 10 years of 
telephony, with only one stream of each type that mattered in each 
direction, and 12 months of trying to get multiple streams working again.

While beating down the resistance of the RTP people against having 
different media types in one RTP session, I've been told over and over 
again that having multiple media streams of the *same* media type in one 
RTP session is just fine and dandy "because that's what we designed RTP 
to do", and now we're finally getting explicit about addressing the idea 
of whether we tolerate more than one media stream per <control surface 
unit> - where the only control surface unit that's been used for the 10 
years of telephony is the M-line.

The M-line is problematic because it binds together multiple things:

- A top level media type
- A set of parameters for media transmission *in all directions* (bound 
to payload type)
- Transport information (the "RTP session" data)

SDP M-lines are already problematic as soon as you want different 
parameters in the two directions. It only goes downhill from there when 
one does multiple flows with varying characteristics.

As I said in Atlanta: SDP M-lines have been walking with one foot on the 
"I'm an RTP session" bank of the canal and with the other foot on the 
"I'm a media stream description" bank of the canal.

The canal is growing wider. Fast.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 18 Nov 2012 22:18:58 -0800

Adam Roach said:

"I need to catch up on CLUE before I can talk to that very much. I'd been
pretty much ignoring CLUE; but in Atlanta, it became clear that CLUE's
impact was going to seep out into every other working group in RAI."

[BA] I think it is probably correct to say that the questions asked in CLUE
are relevant to many other working groups in RAI, including RTCWEB.   Today
even a moderately priced computer can support multiple monitors, as well as
multiple cameras, each of which can support a layered codec, and the cost of
business-grade telepresence systems has come down by an order of magnitude
in the last few years.  Given these trends, it is inevitable that WebRTC
will eventually support these scenarios.  Thinking that through now will
avoid a lot of pain later. 

Adam said:

"I just think we're rushing down a path of throwing out a lot of good to get
rid of a little bit of bad. I'd like to see more discussion around less
radical changes to SDP to achieve the goals of CLUE and RTCWEB."

[BA]  It certainly makes sense to ensure that the WebRTC architecture can
handle CLUE scenarios.   In fact, I do believe that some basic CLUE
scenarios (such as support for multiple cameras and monitors) are already
implementable in some WebRTC implementations, without much in the way of SDP
or API changes.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Nov 2012 10:12:16 -0500

> direction, and 12 months of trying to get multiple streams working again.

:-)  :-(

> The canal is growing wider. Fast.

The *in all directions* is itself far from clear.
- there is a bias towards using the same payload number in both
   directions but it is allowed to negotiate a different payload
   number in each direction for the same payload type.
- there seems to be an implicit assumption that the same payload type
   will be used in both directions, but it is still possible to use
   different payload types for the two directions
- you can negotiate asymmetric codec use via sendonly/recvonly sessions,
   but common usage typically doesn't support two one-way sessions as an
   alternative to one two-way session.

This just further illustrates the schizophrenic nature of the existing 
SDP support that you are pointing out.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Mon, 19 Nov 2012 09:38:36 -0600

On 11/18/12 23:12, Harald Alvestrand wrote:
> - A set of parameters for media transmission *in all directions* 
> (bound to payload type)
> parameters in the two directions. It only goes downhill from there 
> when one does multiple flows with varying characteristics.
>
> As I said in Atlanta: SDP M-lines have been walking with one foot on 
> the "I'm an RTP session" bank of the canal and with the other foot on 
> the "I'm a media stream description" bank of the canal.

I agree with your characterization of the situation. I'm a little 
surprised that it doesn't lead you to the same conclusion as I've reached.

There are, at the moment, 176 attributes in the IANA registry that are 
applicable to m= sections:

3GPP-Adaptation-Support 3GPP-Asset-Information 3GPP-QoE-Metrics
3GPP-SRTP-Config 3gpp-videopostdecbufsize FEC FEC-OTI-extension
FEC-declaration SRTPAuthentication SRTPROCTxRate T38FaxFillBitRemoval
T38FaxMaxBuffer T38FaxMaxDatagram T38FaxRateManagement
T38FaxTranscodingJBIG T38FaxTranscodingMMR T38FaxUdpEC T38FaxVersion
T38MaxBitRate T38VendorInfo X-decbyterate X-initpostdecbufperiod
X-initpredecbufperiod X-predecbufsize aal2CPS aal2CPSSDUrate
aal2sscs3661assured aal2sscs3661unassured aal2sscs3662 aal5sscop
aalApp aalType abrParms abrSetup acap accept-types accept-wrapped-types
acfg alt alt-default-id anycast atmQOSparms atmTrfcDesc atmmap bcob
bearerSigIE bearerType cache candidate capability cbrRate cdsc
cfw-id chain channel clkrec cmid codecconfig conf confid connection
content-desc cpar cparmax cparmin cpsSDUsize creq crypto csup curr
dccp-port dccp-service-code depend des dsel ecan ecn-capable-rtp
eecid extmap fec fec-repair-flow fec-source-flow file-date
file-disposition file-icon file-range file-selector file-transfer-id
fingerprint floorctrl floorid flute-ch flute-tsi fmtp framerate
framesize fsel g.3gpp.cat g.3gpp.crs gc h248item ice-mismatch ice-pwd
ice-ufrag ike-setup imageattr inactive isup_usi key-mgmt label lang
lij max-size maxprate maxptime mbms-flowid mbms-mode mbms-repair
mid msrp-cema multicast-rtcp omr-codecs omr-m-att omr-m-bw omr-m-cksum
omr-s-att omr-s-bw omr-s-cksum onewaySel orient path pcfg portmapping-req
profileDesc prtfl psk-fingerprint ptime qos-mech-recv qos-mech-send
qosClass quality rams-updates recvonly remote-candidates repair-window
resource rtcp rtcp-fb rtcp-mux rtcp-rsize rtcp-unicast rtcp-xr
rtpmap rtpred1 rtpred2 sbc sdplang secondary-realm sendonly sendrecv
setup silenceSupp source-filter sqn ssrc ssrc-group stc stkmstream
structure tcap uiLayer1_Prot upcc userid visited-realm vsel zrtp-hash

Some of these are applicable to the RTP session; others only make sense 
as applied to a single media stream.

If we choose to make each m= section represent one media stream, then 
these attributes are applicable as-is. We get to take advantage of the 
work put in place by the 50 to 60 documents that defined the 
corresponding mechanisms with no changes whatsoever to this existing 
corpus of work.

If we choose to make each m= section represent one RTP session, in which 
multiple media streams can be placed, then the use of any of those 176 
attributes that are to be applied on the stream level becomes ambiguous. 
If we want to take advantage of them for RTCWEB (or anything else that 
leverages the work of untangling this mess), then we have to come up 
with an alternate, non-backwards-compatible syntax for conveying each of 
those attributes (cf. draft-lennox-mmusic-sdp-source-selection).

And that's *just* the issues associated with attributes -- the problem 
is even worse once you consider the more subtle (and difficult to 
predict) damage to established mechanisms, like your codec priority 
conundrum.

/a

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 19 Nov 2012 17:04:27 +0100

On 11/19/2012 04:38 PM, Adam Roach wrote:
> Some of these are applicable to the RTP session; others only make 
> sense as applied to a single media stream.
And some make absolutely no sense at all in the RTCWEB context. Just for 
grins, let's take every single attribute defined for ATM bearer 
connection attributes and just remove them from discussion. Up to 35 
attributes down at a single blow.

I have at one point in my life dealt with T-series fax (RFC 2159 is long 
forgotten, I am happy to say). 'Nuff said.

And those were just the 2 first ones I looked at.
> corresponding mechanisms with no changes whatsoever to this existing 
Except that, for instance, ice-pwd becomes ambiguous, and has to be 
dealt with using a bundle mechanism.

>
> If we choose to make each m= section represent one RTP session, in 
> which multiple media streams can be placed, then the use of any of 
> those 176 attributes that are to be applied on the stream level 
> becomes ambiguous. If we want to take advantage of them for RTCWEB (or 
> anything else that leverages the work of untangling this mess), then 
> we have to come up with an alternate, non-backwards-compatible syntax 
> for conveying each of those attributes (cf. 
> draft-lennox-mmusic-sdp-source-selection).
>
That was an easy one.

---

From: Adam Roach <[email-masked]>
Date: Mon, 19 Nov 2012 10:24:53 -0600

On 11/19/12 10:04, Harald Alvestrand wrote:
>> There are, at the moment, 176 attributes in the IANA registry that 
>> are applicable to m= sections:
>> ...
> And some make absolutely no sense at all in the RTCWEB context.

Perhaps not for RTCWEB, but I'm fairly certain that we'd like to see the 
same solutions applies to CLUE as RTCWEB. I concede that some of these 
are applicable only to technologies that are dead or dying; however...

> I have at one point in my life dealt with T-series fax

...T.38 fax isn't one of them. Sadly.

It sure would be nice to discount all of the existing mechanisms, but I 
suspect that they're not as wholly worthless are you're implying. 
Perhaps when I have a bit more time, I'll sit down and do a 
mechanism-by-mechanism evaluation of applicability of each to RTCWEB and 
CLUE. Until then, I expect it's relatively safe to assume that people 
haven't been putting values into that registry by performing utterly 
meaningless work; and, further, that only a fraction of it has been 
overtaken by technological progress.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Nov 2012 11:37:30 -0500

Adam,

I'm open to different approaches for addressing multiple RTP streams. So 
far ISTM there are drawbacks to all the ones I have seen discussed.

The m-line per stream approach has problems if you don't know a priori 
how many, or which, streams you will have need to send over the session.

I think there is also a problem with how RTCP works, and how the 
attributes that affect it apply, in the m-line per session approach. 
(And there are also problems here if you allow multiple streams per m-line.)

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 19 Nov 2012 17:50:43 +0100

On 11/19/2012 05:24 PM, Adam Roach wrote:
> Perhaps not for RTCWEB, but I'm fairly certain that we'd like to see 
> the same solutions applies to CLUE as RTCWEB. I concede that some of 
> these are applicable only to technologies that are dead or dying; 
> however...
>
What's your scenario where T.38 fax over RTP is relevant when file 
transfer over a reliable channel is available between the same 2 devices?
>
> It sure would be nice to discount all of the existing mechanisms, but 
> I suspect that they're not as wholly worthless are you're implying. 
> mechanism-by-mechanism evaluation of applicability of each to RTCWEB 
> and CLUE. Until then, I expect it's relatively safe to assume that 
> people haven't been putting values into that registry by performing 
> utterly meaningless work; and, further, that only a fraction of it has 
> been overtaken by technological progress.
90% is also a fraction. But I agree it's unlikely to be that high.

---

From: Adam Roach <[email-masked]>
Date: Mon, 19 Nov 2012 10:57:22 -0600

> transfer over a reliable channel is available between the same 2 devices?

This is a rat hole that I'm not going to dive too far into, but my 
understanding is that the tenacity of fax as an underlying technology 
has to do with a substantial body of U.S. case law that establishes that 
faxed legal documents are binding, while leaving the issue of 
transmission using a technology known by any other name unsettled.

Is this a mind-numbingly stupid reason for it to hang on? Yeah, maybe. 
Does that change the facts on the ground? No. Not even a little bit.

ObHumor: 
http://www.theonion.com/articles/report-fax-machines-still-pretty-impressive-if-you,21256/

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Nov 2012 11:57:49 -0500

> transfer over a reliable channel is available between the same 2 devices?

Sadly, I gather that the legal world hasn't yet caught up with 
technology. E.g., I think that faxed copies of documents with signatures 
have more legal validity than do pdf files containing signatures. 
Stupid, but it can still drive demand for continued support of fax 
protocols.

[I'm not an expert on this - this comment is mostly based on 2nd hand data.]

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 20 Nov 2012 09:47:41 +0100

On 11/19/2012 05:57 PM, Adam Roach wrote:
> has to do with a substantial body of U.S. case law that establishes 
> that faxed legal documents are binding, while leaving the issue of 
Sympathy. I've read the original judge's opinion in the English court 
case that established telex as legally binding - he explicitly said "I 
have this opinion not because it is technically sound, but because it is 
necessary to keep commerce flowing". We're still there, and the fax 
industry keeps chugging along because of it.

Still, I don't see the compelling use case for T.38 fax over RTP *into 
browsers*.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 20 Nov 2012 11:12:23 -0800

> - A set of parameters for media transmission *in all directions* (bound to payload type)

[BA] RFC 3264 Section 5.1 makes it clear that the parameters need not apply in all directions (though sendrecv is the default): 

   The list of media formats for each media stream conveys two pieces of
   information, namely the set of formats (codecs and any parameters
   associated with the codec, in the case of RTP) that the offerer is
   capable of sending and/or receiving (depending on the direction
   attributes), and, in the case of RTP, the RTP payload type numbers
   used to identify those formats.  If multiple formats are listed, it
   means that the offerer is capable of making use of any of those
   formats during the session.  In other words, the answerer MAY change
   formats in the middle of the session, making use of any of the
   formats listed, without sending a new offer.  For a sendonly stream,
   the offer SHOULD indicate those formats the offerer is willing to
   send for this stream.  For a recvonly stream, the offer SHOULD
   indicate those formats the offerer is willing to receive for this
   stream.  For a sendrecv stream, the offer SHOULD indicate those
   codecs that the offerer is willing to send and receive with.

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 20 Nov 2012 16:39:37 -0500

On 11/20/12 3:47 AM, Harald Alvestrand wrote:
>> Is this a mind-numbingly stupid reason for it to hang on? Yeah, 
>> maybe. Does that change the facts on the ground? No. Not even a 
>> little bit.
> have this opinion not because it is technically sound, but because it 
> is necessary to keep commerce flowing". We're still there, and the fax 

Why not if that's the only client I have ?

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 20 Nov 2012 16:49:45 -0500

On 11/19/12 10:38 AM, Adam Roach wrote:
> these attributes are applicable as-is.
Unfortunately not; some of them are, some of them are not (typically 
because they are attributes related to the "stream" part more than the 
"media format" part). SDES and ICE are examples that require some form 
of selection.

There was an off-line discussion between a few folks in Atlanta about 
taking a look at every single SDP attribute defined today (and the other 
SDP parameters) and determine for each if it would work "as-is" in a 
bundle scenario or whether it would require some sort of special 
treatment and what that would be (e.g "aggregation" or "pick-one"). I'm 
not sure that work has been started yet, but it's probably a good way of 
making progress on this part of the discussion.

Thanks

-- Flemming

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Nov 2012 15:56:08 -0600

> Still, I don't see the compelling use case for T.38 fax over RTP *into 

   +---------+   +------------+   +---------+
   | Web App |---| SIP Server |---|         |
   +---------+   +------------+   |         | +-------------+
        |                         | PSTN GW |--| Fax Machine |
   +---------+      media         |         | +-------------+
   | Browser |--------------------|         |
   +---------+                    +---------+

/a

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 21 Nov 2012 07:39:49 -0800

> SDP support that you are pointing out.

Explaining why the W3C has chosen to use strings containing SDP as the 
API for WEBRTC.

Matthew Kaufman

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 22 Nov 2012 13:27:24 +0100

On 11/20/2012 08:12 PM, Bernard Aboba wrote:
> [BA] RFC 3264 Section 5.1 makes it clear that the parameters need not 
> apply in all directions (though sendrecv is the default):

agreed. What I find more problematic / irritating is that with 
parameters that apply to both directions of a sendrecv stream, there's 
no way to specify one set that applies A->B and another set that 
applies  B->A.
With sendonly / recvonly streams, this is not an issue; with parameters 
that apply only in one direction (such as crypto keys), it is also not 
an issue. But for some parameters, it is an issue.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Nov 2012 12:35:26 +0000

Hi,

>agreed. What I find more problematic / irritating is that with parameters that apply to both directions of a sendrecv stream, there's no way to specify one set that applies A->B and another set that applies  B->A.
>With sendonly / recvonly streams, this is not an issue; with parameters that apply only in one direction (such as crypto keys), it is also not an issue. But for some parameters, it is an issue.

The root to these problems is that fact that, at one point many earth spins ago, the community made a decision that with SIP/SDP you only need to indicate your receiving capabilities...

Regards,

Christer