a=msid-semantic

[Bryan Donnovan]

What is the purpose of this line? And why does audio fail to play out on the latest canary if it is not present in the offer?

a=msid-semantic: WMS Q4OTdMHHnI9HiBFbWmDjx3VuO72wq3UgticY

[Bryan Donnovan]

According to http://tools.ietf.org/html/draft-alvestrand-rtcweb-msid-02#section-3 this is an optional attribute, so it seems to be a bug that audio fails when it is not present.  video still works fine, btw.

[Vikas Marwaha]

Hi Bryan,

You can file a bug, as i understand the attribute should be optional. 

/Vikas

--
 
 
 

[Justin Uberti]

It is optional if you only have a single audio and video stream (i.e. the legacy case).

--
 
 
 

[Ivan Vučica]

How does this map to Jingle? That is, from what I understand, Jingle (and 'Gingle') sessions could have been mapped to WebRTC's SDP, and session could be established to existing Jingle clients. msid-semantic doesn't remind me of anything in a XEP.

Am I wrong in assuming that WebRTC was interoperable with Jingle/'Gingle' systems in the past? Am I wrong in assuming this is blocking such interoperability?

Regards,

Ivan Vučica

via phone

--
 
 
 

[Philipp Hancke]

Such a mapping needs to be defined (which is just a bunch of standardization work). There is a number of issues in mapping jingle to sdp and vice versa, see the jin...@xmpp.org list.

Codec interoperability is more likely to prevent interop.

[Ivan Vučica]

I found some discussion via quick (and short) googling, but retrofitting Jingle means preventing interoperability with all but latest clients. No Google Talk for Windows, no Psi, as well as any other non-updated client (such as several iOS clients).

It might be good if some consideration could be given for legacy clients that can't or won't be updated.

Regarding codecs -- indeed, but that could be remedied in the future. Embedding into WebRTC spec something that would prevent establishing a connection at all, even if codec is added, might block ever achieving interop with existing clients.

Regards,

Ivan Vučica

via phone

On 18. 1. 2013., at 18:03, Philipp Hancke <philipp...@googlemail.com> wrote:

Such a mapping needs to be defined (which is just a bunch of standardization work). There is a number of issues in mapping jingle to sdp and vice versa, see the jin...@xmpp.org list.

Codec interoperability is more likely to prevent interop.

--
 
 
 

[Bryan Donnovan]

My test where audio failed yesterday with no msid-semantic works unchanged in today's canary, so problem solved.

[Justin Uberti]

As mentioned before, this attribute is optional. It's only needed to say "I support demultiplexing multiple sources in a given m= line or <content/>". Since Jingle doesn't have a XEP-defined way of doing this (yet), it's not a legacy compatibility issue - we just need to incorporate it into any future multiplexing proposal. 

(If someone was interested in helping write up our <streams> approach, that could be one proposal)

--
 
 
 

[Ivan Vučica]

Thanks!

Regards,

Ivan Vučica

via phone

--