[jitsi-dev] Video Streams and WebRtc


#1

I have run meet.jit.si and run a mixture of Sawbuck, Chrome internals and APP.conference.saveLogs();

My current hypothesis is that I am getting cname, label, msid and mslabel wrong for the video stream. Interestingly it appears that the second video stream (which actually has data in it) arrives in the browser as addStream on the Peer Connection rather than addTrack on the stream.

I wonder what these things are. They are probably something to do with channel IDs, etc etc. However, it is not clear. There are also hyphens in them and I wonder what the parsing rules are for the hyphens.

Does anyone have any hints as to where I might get this information in the REST interface or if it is not in the REST interface what data it is so that I can put it into the information sent to the client.

a=ssrc:628512247 cname:mixed

a=ssrc:628512247 label:mixedlabelvideo0
a=ssrc:628512247 msid:mixedmslabel mixedlabelvideo0
a=ssrc:628512247 mslabel:mixedmslabel
a=ssrc:2966171306 cname:pkByP7AldqW1jlpk
a=ssrc:2966171306 msid:3fb358c0-f120-46ea-948d-b5c8112b742f 917d4802-eb18-40b9-904d-4c27a8933cb6
a=ssrc:2966171306 mslabel:3fb358c0-f120-46ea-948d-b5c8112b742f
a=ssrc:2966171306 label:917d4802-eb18-40b9-904d-4c27a8933cb6

I note the same sort of thing applies to the audio channel (which I have not really looked at yet)

=ssrc:3126877119 cname:mixed
a=ssrc:3126877119 label:mixedlabelaudio0
a=ssrc:3126877119 msid:mixedmslabel mixedlabelaudio0
a=ssrc:3126877119 mslabel:mixedmslabel
a=ssrc:898736117 cname:pkByP7AldqW1jlpk
a=ssrc:898736117 msid:3fb358c0-f120-46ea-948d-b5c8112b742f cfa40ce2-fac0-44bf-a665-e474cc2b85c4
a=ssrc:898736117 mslabel:3fb358c0-f120-46ea-948d-b5c8112b742f
a=ssrc:898736117 label:cfa40ce2-fac0-44bf-a665-e474cc2b85c4


#2

Further to this I think Cname is to be found in RTPSourceInfo which has

SSRCInfo[] ssrc;
SourceDescription cname;

and.

···

On 27/01/2017 09:17, John Hemming wrote:

I have run meet.jit.si and run a mixture of Sawbuck, Chrome internals and APP.conference.saveLogs();

My current hypothesis is that I am getting cname, label, msid and mslabel wrong for the video stream. Interestingly it appears that the second video stream (which actually has data in it) arrives in the browser as addStream on the Peer Connection rather than addTrack on the stream.

I wonder what these things are. They are probably something to do with channel IDs, etc etc. However, it is not clear. There are also hyphens in them and I wonder what the parsing rules are for the hyphens.

Does anyone have any hints as to where I might get this information in the REST interface or if it is not in the REST interface what data it is so that I can put it into the information sent to the client.

a=ssrc:628512247 cname:mixed

a=ssrc:628512247label:mixedlabelvideo0
a=ssrc:628512247 msid:mixedmslabel mixedlabelvideo0
a=ssrc:628512247 mslabel:mixedmslabel
a=ssrc:2966171306 cname:pkByP7AldqW1jlpk
a=ssrc:2966171306 msid:3fb358c0-f120-46ea-948d-b5c8112b742f 917d4802-eb18-40b9-904d-4c27a8933cb6
a=ssrc:2966171306 mslabel:3fb358c0-f120-46ea-948d-b5c8112b742f
a=ssrc:2966171306label:917d4802-eb18-40b9-904d-4c27a8933cb6

I note the same sort of thing applies to the audio channel (which I have not really looked at yet)

=ssrc:3126877119 cname:mixed
a=ssrc:3126877119label:mixedlabelaudio0
a=ssrc:3126877119 msid:mixedmslabel mixedlabelaudio0
a=ssrc:3126877119 mslabel:mixedmslabel
a=ssrc:898736117 cname:pkByP7AldqW1jlpk
a=ssrc:898736117 msid:3fb358c0-f120-46ea-948d-b5c8112b742f cfa40ce2-fac0-44bf-a665-e474cc2b85c4
a=ssrc:898736117 mslabel:3fb358c0-f120-46ea-948d-b5c8112b742f
a=ssrc:898736117label:cfa40ce2-fac0-44bf-a665-e474cc2b85c4

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#3

Further to this I have done some tests:

I deliberately got the SSRC wrong in the SDP. That resulted in the chrome logs complaining that SSRC? was not associated with receiving track. Importantly, however, the stream was still added (which is related to the SDP having a stream in it rather than there being an actual stream). The stream (track) went "muted" after the peerconnection went to connected (again).

I have tried to find out what the CName is. I have used getSendStreams and tried to get it from there. It gives me, however, User@JAMH=I7 (which is the CName from my computer). I have tried that in the SDP, but it still does not seem to connect.

To me it appears that there is a disconnect between what I have put in the SDP and what the Bridge is actually sending. Looking at meet.jit.si it is clear that the CName there is not the same as what I am sending to the bridge. Hence it seems that the CName is wrong.

Which asks the question as to where can I get the CName from?

It does not look like the Endpoint as the endpoint is hexadecimal and the CName is a form of upper/lower case plus numbers.

···

On 27/01/2017 09:39, John Hemming wrote:

Further to this I think Cname is to be found in RTPSourceInfo which has

SSRCInfo[] ssrc;
SourceDescription cname;

and.

On 27/01/2017 09:17, John Hemming wrote:

I have run meet.jit.si and run a mixture of Sawbuck, Chrome internals and APP.conference.saveLogs();

My current hypothesis is that I am getting cname, label, msid and mslabel wrong for the video stream. Interestingly it appears that the second video stream (which actually has data in it) arrives in the browser as addStream on the Peer Connection rather than addTrack on the stream.

I wonder what these things are. They are probably something to do with channel IDs, etc etc. However, it is not clear. There are also hyphens in them and I wonder what the parsing rules are for the hyphens.

Does anyone have any hints as to where I might get this information in the REST interface or if it is not in the REST interface what data it is so that I can put it into the information sent to the client.

a=ssrc:628512247 cname:mixed

a=ssrc:628512247label:mixedlabelvideo0
a=ssrc:628512247 msid:mixedmslabel mixedlabelvideo0
a=ssrc:628512247 mslabel:mixedmslabel
a=ssrc:2966171306 cname:pkByP7AldqW1jlpk
a=ssrc:2966171306 msid:3fb358c0-f120-46ea-948d-b5c8112b742f 917d4802-eb18-40b9-904d-4c27a8933cb6
a=ssrc:2966171306 mslabel:3fb358c0-f120-46ea-948d-b5c8112b742f
a=ssrc:2966171306label:917d4802-eb18-40b9-904d-4c27a8933cb6

I note the same sort of thing applies to the audio channel (which I have not really looked at yet)

=ssrc:3126877119 cname:mixed
a=ssrc:3126877119label:mixedlabelaudio0
a=ssrc:3126877119 msid:mixedmslabel mixedlabelaudio0
a=ssrc:3126877119 mslabel:mixedmslabel
a=ssrc:898736117 cname:pkByP7AldqW1jlpk
a=ssrc:898736117 msid:3fb358c0-f120-46ea-948d-b5c8112b742f cfa40ce2-fac0-44bf-a665-e474cc2b85c4
a=ssrc:898736117 mslabel:3fb358c0-f120-46ea-948d-b5c8112b742f
a=ssrc:898736117label:cfa40ce2-fac0-44bf-a665-e474cc2b85c4

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

I suppose the CName could be the endpoint Base64 encoded. Is it that?

···

On 27/01/2017 11:28, John Hemming wrote:

Further to this I have done some tests:

I deliberately got the SSRC wrong in the SDP. That resulted in the chrome logs complaining that SSRC? was not associated with receiving track. Importantly, however, the stream was still added (which is related to the SDP having a stream in it rather than there being an actual stream). The stream (track) went "muted" after the peerconnection went to connected (again).

I have tried to find out what the CName is. I have used getSendStreams and tried to get it from there. It gives me, however, User@JAMH=I7 (which is the CName from my computer). I have tried that in the SDP, but it still does not seem to connect.

To me it appears that there is a disconnect between what I have put in the SDP and what the Bridge is actually sending. Looking at meet.jit.si it is clear that the CName there is not the same as what I am sending to the bridge. Hence it seems that the CName is wrong.

Which asks the question as to where can I get the CName from?

It does not look like the Endpoint as the endpoint is hexadecimal and the CName is a form of upper/lower case plus numbers.

On 27/01/2017 09:39, John Hemming wrote:

Further to this I think Cname is to be found in RTPSourceInfo which has

SSRCInfo[] ssrc;
SourceDescription cname;

and.

On 27/01/2017 09:17, John Hemming wrote:

I have run meet.jit.si and run a mixture of Sawbuck, Chrome internals and APP.conference.saveLogs();

My current hypothesis is that I am getting cname, label, msid and mslabel wrong for the video stream. Interestingly it appears that the second video stream (which actually has data in it) arrives in the browser as addStream on the Peer Connection rather than addTrack on the stream.

I wonder what these things are. They are probably something to do with channel IDs, etc etc. However, it is not clear. There are also hyphens in them and I wonder what the parsing rules are for the hyphens.

Does anyone have any hints as to where I might get this information in the REST interface or if it is not in the REST interface what data it is so that I can put it into the information sent to the client.

a=ssrc:628512247 cname:mixed

a=ssrc:628512247label:mixedlabelvideo0
a=ssrc:628512247 msid:mixedmslabel mixedlabelvideo0
a=ssrc:628512247 mslabel:mixedmslabel
a=ssrc:2966171306 cname:pkByP7AldqW1jlpk
a=ssrc:2966171306 msid:3fb358c0-f120-46ea-948d-b5c8112b742f 917d4802-eb18-40b9-904d-4c27a8933cb6
a=ssrc:2966171306 mslabel:3fb358c0-f120-46ea-948d-b5c8112b742f
a=ssrc:2966171306label:917d4802-eb18-40b9-904d-4c27a8933cb6

I note the same sort of thing applies to the audio channel (which I have not really looked at yet)

=ssrc:3126877119 cname:mixed
a=ssrc:3126877119label:mixedlabelaudio0
a=ssrc:3126877119 msid:mixedmslabel mixedlabelaudio0
a=ssrc:3126877119 mslabel:mixedmslabel
a=ssrc:898736117 cname:pkByP7AldqW1jlpk
a=ssrc:898736117 msid:3fb358c0-f120-46ea-948d-b5c8112b742f cfa40ce2-fac0-44bf-a665-e474cc2b85c4
a=ssrc:898736117 mslabel:3fb358c0-f120-46ea-948d-b5c8112b742f
a=ssrc:898736117label:cfa40ce2-fac0-44bf-a665-e474cc2b85c4

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

Hi John,

see http://www.freesoft.org/CIE/RFC/1889/24.htm and also https://webrtchacks.com/sdp-anatomy/ for a summary of a typical WebRTC sdp.

Cheers,

Matteo

···

________________________________
From: dev <dev-bounces@jitsi.org> on behalf of John Hemming <john@hemming.email>
Sent: Friday, January 27, 2017 1:53 PM
To: Jitsi Developers
Subject: Re: [jitsi-dev] Video Streams and WebRtc - CName [heur]

I suppose the CName could be the endpoint Base64 encoded. Is it that?

On 27/01/2017 11:28, John Hemming wrote:

Further to this I have done some tests:

I deliberately got the SSRC wrong in the SDP. That resulted in the chrome logs complaining that SSRC? was not associated with receiving track. Importantly, however, the stream was still added (which is related to the SDP having a stream in it rather than there being an actual stream). The stream (track) went "muted" after the peerconnection went to connected (again).

I have tried to find out what the CName is. I have used getSendStreams and tried to get it from there. It gives me, however, User@JAMH=I7 (which is the CName from my computer). I have tried that in the SDP, but it still does not seem to connect.

To me it appears that there is a disconnect between what I have put in the SDP and what the Bridge is actually sending. Looking at meet.jit.si it is clear that the CName there is not the same as what I am sending to the bridge. Hence it seems that the CName is wrong.

Which asks the question as to where can I get the CName from?

It does not look like the Endpoint as the endpoint is hexadecimal and the CName is a form of upper/lower case plus numbers.

On 27/01/2017 09:39, John Hemming wrote:

Further to this I think Cname is to be found in RTPSourceInfo which has

SSRCInfo[] ssrc;
SourceDescription cname;

and.

On 27/01/2017 09:17, John Hemming wrote:

I have run meet.jit.si and run a mixture of Sawbuck, Chrome internals and APP.conference.saveLogs();

My current hypothesis is that I am getting cname, label, msid and mslabel wrong for the video stream. Interestingly it appears that the second video stream (which actually has data in it) arrives in the browser as addStream on the Peer Connection rather than addTrack on the stream.

I wonder what these things are. They are probably something to do with channel IDs, etc etc. However, it is not clear. There are also hyphens in them and I wonder what the parsing rules are for the hyphens.

Does anyone have any hints as to where I might get this information in the REST interface or if it is not in the REST interface what data it is so that I can put it into the information sent to the client.

a=ssrc:628512247 cname:mixed

a=ssrc:628512247 label:mixedlabelvideo0
a=ssrc:628512247 msid:mixedmslabel mixedlabelvideo0
a=ssrc:628512247 mslabel:mixedmslabel
a=ssrc:2966171306 cname:pkByP7AldqW1jlpk
a=ssrc:2966171306 msid:3fb358c0-f120-46ea-948d-b5c8112b742f 917d4802-eb18-40b9-904d-4c27a8933cb6
a=ssrc:2966171306 mslabel:3fb358c0-f120-46ea-948d-b5c8112b742f
a=ssrc:2966171306 label:917d4802-eb18-40b9-904d-4c27a8933cb6

I note the same sort of thing applies to the audio channel (which I have not really looked at yet)

=ssrc:3126877119 cname:mixed
a=ssrc:3126877119 label:mixedlabelaudio0
a=ssrc:3126877119 msid:mixedmslabel mixedlabelaudio0
a=ssrc:3126877119 mslabel:mixedmslabel
a=ssrc:898736117 cname:pkByP7AldqW1jlpk
a=ssrc:898736117 msid:3fb358c0-f120-46ea-948d-b5c8112b742f cfa40ce2-fac0-44bf-a665-e474cc2b85c4
a=ssrc:898736117 mslabel:3fb358c0-f120-46ea-948d-b5c8112b742f
a=ssrc:898736117 label:cfa40ce2-fac0-44bf-a665-e474cc2b85c4

_______________________________________________
dev mailing list
dev@jitsi.org<mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org<mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org<mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#6

I was looking at both of those and also the SDP from meet.jit.si:

a=ssrc:2099006775 cname:3Si4oD2HC2wlwIa
a=ssrc:2099006775 msid:78337958-84e8-47cb-b217-0e178869c62c bffbddf0-76b8-4c1b-b86a-3f4a9658f06b
a=ssrc:2099006775 mslabel:78337958-84e8-47cb-b217-0e178869c62c
a=ssrc:2099006775 label:bffbddf0-76b8-4c1b-b86a-3f4a9658f06b

cname in this is not abce@def.com

It also appears in the SDES Source Description RTCP packet. Hence it would not be surprising that the stream does not link up if it is wrong.

The other labels do not strike me as things which are in the RTCP. Whatever the situation anyway it strikes me that this is the problem.

I have just come back from my lunch and will try to find the part of the bridge software that sends RTCP and see if I can inspect a packet that way. I have tried to work out where XMPP gets this from and have found SourcePacketExtension as a good candidate.

I know someone who previously worked on Rest about 5 months ago was using the SSRC for the cname, but I think that is clearly wrong.

It is an interestingly steep learning curve getting this to work. However, from my point of view it is a good learning experience as I am having to get into the Chrome Logs and various other bitties. Sadly because it is encrypted I have assumed I won't get these answers via webshark.

···

On 27/01/2017 13:03, Matteo Campana wrote:

Hi John,

see http://www.freesoft.org/CIE/RFC/1889/24.htm and also https://webrtchacks.com/sdp-anatomy/ for a summary of a typical WebRTC sdp.

Cheers,

Matteo

------------------------------------------------------------------------
*From:* dev <dev-bounces@jitsi.org> on behalf of John Hemming <john@hemming.email>
*Sent:* Friday, January 27, 2017 1:53 PM
*To:* Jitsi Developers
*Subject:* Re: [jitsi-dev] Video Streams and WebRtc - CName [heur]

I suppose the CName could be the endpoint Base64 encoded. Is it that?

On 27/01/2017 11:28, John Hemming wrote:

Further to this I have done some tests:

I deliberately got the SSRC wrong in the SDP. That resulted in the chrome logs complaining that SSRC? was not associated with receiving track. Importantly, however, the stream was still added (which is related to the SDP having a stream in it rather than there being an actual stream). The stream (track) went "muted" after the peerconnection went to connected (again).

I have tried to find out what the CName is. I have used getSendStreams and tried to get it from there. It gives me, however, User@JAMH=I7 (which is the CName from my computer). I have tried that in the SDP, but it still does not seem to connect.

To me it appears that there is a disconnect between what I have put in the SDP and what the Bridge is actually sending. Looking at meet.jit.si it is clear that the CName there is not the same as what I am sending to the bridge. Hence it seems that the CName is wrong.

Which asks the question as to where can I get the CName from?

It does not look like the Endpoint as the endpoint is hexadecimal and the CName is a form of upper/lower case plus numbers.

On 27/01/2017 09:39, John Hemming wrote:

Further to this I think Cname is to be found in RTPSourceInfo which has

SSRCInfo[] ssrc;
SourceDescription cname;

and.

On 27/01/2017 09:17, John Hemming wrote:

I have run meet.jit.si and run a mixture of Sawbuck, Chrome internals and APP.conference.saveLogs();

My current hypothesis is that I am getting cname, label, msid and mslabel wrong for the video stream. Interestingly it appears that the second video stream (which actually has data in it) arrives in the browser as addStream on the Peer Connection rather than addTrack on the stream.

I wonder what these things are. They are probably something to do with channel IDs, etc etc. However, it is not clear. There are also hyphens in them and I wonder what the parsing rules are for the hyphens.

Does anyone have any hints as to where I might get this information in the REST interface or if it is not in the REST interface what data it is so that I can put it into the information sent to the client.

a=ssrc:628512247 cname:mixed

a=ssrc:628512247label:mixedlabelvideo0
a=ssrc:628512247 msid:mixedmslabel mixedlabelvideo0
a=ssrc:628512247 mslabel:mixedmslabel
a=ssrc:2966171306 cname:pkByP7AldqW1jlpk
a=ssrc:2966171306 msid:3fb358c0-f120-46ea-948d-b5c8112b742f 917d4802-eb18-40b9-904d-4c27a8933cb6
a=ssrc:2966171306 mslabel:3fb358c0-f120-46ea-948d-b5c8112b742f
a=ssrc:2966171306label:917d4802-eb18-40b9-904d-4c27a8933cb6

I note the same sort of thing applies to the audio channel (which I have not really looked at yet)

=ssrc:3126877119 cname:mixed
a=ssrc:3126877119label:mixedlabelaudio0
a=ssrc:3126877119 msid:mixedmslabel mixedlabelaudio0
a=ssrc:3126877119 mslabel:mixedmslabel
a=ssrc:898736117 cname:pkByP7AldqW1jlpk
a=ssrc:898736117 msid:3fb358c0-f120-46ea-948d-b5c8112b742f cfa40ce2-fac0-44bf-a665-e474cc2b85c4
a=ssrc:898736117 mslabel:3fb358c0-f120-46ea-948d-b5c8112b742f
a=ssrc:898736117label:cfa40ce2-fac0-44bf-a665-e474cc2b85c4

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

So I think I have traced the cnames into and out of the bridge to find that they appear to be treated in the same way as the ssrc (which is of course reasonable). I have slotted that back into the SDP for the first conference member when the second joins and the first is told that there is a new stream.

a) It appears that the stream and track entities are created by the application of the SDP as the remote description.

b) The new track appears to be muted between 0.5 and 1.8 seconds after the remote description is created. I have run it a number of times and all were in that range. This looks like a form of timeout.

The muting appears to be entirely a record that arises from the lack of data. However, it is not clear what is happening there. I have run the bridge some another computer and packetsniffed the packets sent to the client and there is quite a bit of traffic, but of course I cannot really tell what it is in it. I think cname is now correct. I have seen the following records appear in the chrome logs at around the same time as the muting happens:

WARNING 11464 9084 10:58:06-578 0 webrtc::ModuleRtpRtcpImpl::Process: Timeout: No RTCP RR received.
WARNING 11464 9084 10:58:06-583 0 webrtc::ModuleRtpRtcpImpl::Process: Timeout: No increase in RTCP RR extended highest sequence number.

For the moment I have decided to see what happens if I try to implement this in Firefox and Edge. I am hoping that they will tell me something that Chrome has not told me.

Any suggestions are welcome.

···

On 27/01/2017 13:58, John Hemming wrote:

I was looking at both of those and also the SDP from meet.jit.si:

a=ssrc:2099006775 cname:3Si4oD2HC2wlwIa
a=ssrc:2099006775 msid:78337958-84e8-47cb-b217-0e178869c62c bffbddf0-76b8-4c1b-b86a-3f4a9658f06b
a=ssrc:2099006775 mslabel:78337958-84e8-47cb-b217-0e178869c62c
a=ssrc:2099006775 label:bffbddf0-76b8-4c1b-b86a-3f4a9658f06b

cname in this is not abce@def.com

It also appears in the SDES Source Description RTCP packet. Hence it would not be surprising that the stream does not link up if it is wrong.

The other labels do not strike me as things which are in the RTCP. Whatever the situation anyway it strikes me that this is the problem.

I have just come back from my lunch and will try to find the part of the bridge software that sends RTCP and see if I can inspect a packet that way. I have tried to work out where XMPP gets this from and have found SourcePacketExtension as a good candidate.

I know someone who previously worked on Rest about 5 months ago was using the SSRC for the cname, but I think that is clearly wrong.

It is an interestingly steep learning curve getting this to work. However, from my point of view it is a good learning experience as I am having to get into the Chrome Logs and various other bitties. Sadly because it is encrypted I have assumed I won't get these answers via webshark.

On 27/01/2017 13:03, Matteo Campana wrote:

Hi John,

see http://www.freesoft.org/CIE/RFC/1889/24.htm and also https://webrtchacks.com/sdp-anatomy/ for a summary of a typical WebRTC sdp.

Cheers,

Matteo

------------------------------------------------------------------------
*From:* dev <dev-bounces@jitsi.org> on behalf of John Hemming <john@hemming.email>
*Sent:* Friday, January 27, 2017 1:53 PM
*To:* Jitsi Developers
*Subject:* Re: [jitsi-dev] Video Streams and WebRtc - CName [heur]

I suppose the CName could be the endpoint Base64 encoded. Is it that?

On 27/01/2017 11:28, John Hemming wrote:

Further to this I have done some tests:

I deliberately got the SSRC wrong in the SDP. That resulted in the chrome logs complaining that SSRC? was not associated with receiving track. Importantly, however, the stream was still added (which is related to the SDP having a stream in it rather than there being an actual stream). The stream (track) went "muted" after the peerconnection went to connected (again).

I have tried to find out what the CName is. I have used getSendStreams and tried to get it from there. It gives me, however, User@JAMH=I7 (which is the CName from my computer). I have tried that in the SDP, but it still does not seem to connect.

To me it appears that there is a disconnect between what I have put in the SDP and what the Bridge is actually sending. Looking at meet.jit.si it is clear that the CName there is not the same as what I am sending to the bridge. Hence it seems that the CName is wrong.

Which asks the question as to where can I get the CName from?

It does not look like the Endpoint as the endpoint is hexadecimal and the CName is a form of upper/lower case plus numbers.

On 27/01/2017 09:39, John Hemming wrote:

Further to this I think Cname is to be found in RTPSourceInfo which has

SSRCInfo[] ssrc;
SourceDescription cname;

and.

On 27/01/2017 09:17, John Hemming wrote:

I have run meet.jit.si and run a mixture of Sawbuck, Chrome internals and APP.conference.saveLogs();

My current hypothesis is that I am getting cname, label, msid and mslabel wrong for the video stream. Interestingly it appears that the second video stream (which actually has data in it) arrives in the browser as addStream on the Peer Connection rather than addTrack on the stream.

I wonder what these things are. They are probably something to do with channel IDs, etc etc. However, it is not clear. There are also hyphens in them and I wonder what the parsing rules are for the hyphens.

Does anyone have any hints as to where I might get this information in the REST interface or if it is not in the REST interface what data it is so that I can put it into the information sent to the client.

a=ssrc:628512247 cname:mixed

a=ssrc:628512247label:mixedlabelvideo0
a=ssrc:628512247 msid:mixedmslabel mixedlabelvideo0
a=ssrc:628512247 mslabel:mixedmslabel
a=ssrc:2966171306 cname:pkByP7AldqW1jlpk
a=ssrc:2966171306 msid:3fb358c0-f120-46ea-948d-b5c8112b742f 917d4802-eb18-40b9-904d-4c27a8933cb6
a=ssrc:2966171306 mslabel:3fb358c0-f120-46ea-948d-b5c8112b742f
a=ssrc:2966171306label:917d4802-eb18-40b9-904d-4c27a8933cb6

I note the same sort of thing applies to the audio channel (which I have not really looked at yet)

=ssrc:3126877119 cname:mixed
a=ssrc:3126877119label:mixedlabelaudio0
a=ssrc:3126877119 msid:mixedmslabel mixedlabelaudio0
a=ssrc:3126877119 mslabel:mixedmslabel
a=ssrc:898736117 cname:pkByP7AldqW1jlpk
a=ssrc:898736117 msid:3fb358c0-f120-46ea-948d-b5c8112b742f cfa40ce2-fac0-44bf-a665-e474cc2b85c4
a=ssrc:898736117 mslabel:3fb358c0-f120-46ea-948d-b5c8112b742f
a=ssrc:898736117label:cfa40ce2-fac0-44bf-a665-e474cc2b85c4

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev