Bug 31276

All the senders in a stream will be represented in the MediaDescriptionMap.

I currently think that should be only a single handle per Stream. The reason to have multiple handles per stream is the following use case: you have a peer that aggregates (but without mixing or transcoding) data from different peers. I don't know of any protocol that works that way. It may be better to have either a separate "connection" for each peer and use plain TURN instead of inventing something theoretical that does not exist.

If there is a single handle per stream, then ContactCodecMap could be split up and just put the RemoteCodec on each stream. They have to be matched up on both sides anyway. And then we can also put the CodecOffer on the Streams too (since it already relates on only one handle)..

And very soon we have something that's pretty damn close to the Farsight2 API.

(In reply to comment #2)
> I currently think that should be only a single handle per Stream. The reason to
> have multiple handles per stream is the following use case: you have a peer
> that aggregates (but without mixing or transcoding) data from different peers.
> I don't know of any protocol that works that way. It may be better to have
> either a separate "connection" for each peer and use plain TURN instead of
> inventing something theoretical that does not exist.

As discussed on IRC, the use case for this is that if you have a server in the sky that can multi-unicast your video without mixing then you've won because you can avoid sending the same data 6 times over your bandwidth-limited upstream link. Doing this over one udp socket lets you avoid all sorts of NAT issues. This requires the ability to have multiple MediaDescriptions per stream, and incoming data to be demuxed by SSRC.
> 
> If there is a single handle per stream, then ContactCodecMap could be split up
> and just put the RemoteCodec on each stream. They have to be matched up on both
> sides anyway. And then we can also put the CodecOffer on the Streams too (since
> it already relates on only one handle)..
> 
Veto'd. We need multiple MediaDescriptions per stream.

Please review
http://git.collabora.co.uk/?p=user/alsuren/telepathy-spec.git;a=shortlog;h=refs/heads/call-contacts which should clarify how to deal with Contacts.

There is also a brief yak-shave to clarify LocalSendingState. Sorry about that.

Only relevant comment is that I think the SSRC property should be of type "au" and be "SSRCs".

That said, the value in Accept() should always be a single SSRC.

(In reply to comment #4)
> Only relevant comment is that I think the SSRC property should be of type "au"
> and be "SSRCs".
> 
> That said, the value in Accept() should always be a single SSRC.

I'm going to keep it as a single u until you can point me to a use-case which isn't covered by either contact=0 or a single MD+SSRC per contact.

If farstream wants to include an optimisation to recognise identical MediaDescriptions and reuse resources, then it's welcome to do so.

Recognizing multiple MDs with the same ssrc is painful.. need to compare every field.. While having multiple SSRCs in a single MD is cheap. Also means you have to duplicate it in the CM and de-duplicate in the client, sounds very wrong.

Now, there is no existing use case, just like for having multiple handles in a Stream..

Pushed the requested change to the end of http://git.collabora.co.uk/?p=user/alsuren/telepathy-spec.git;a=shortlog;h=refs/heads/mute

I think you mean
http://git.collabora.co.uk/?p=user/alsuren/telepathy-spec.git;a=shortlog;h=refs/heads/call-contacts

and its ++

Thanks for bearing with me. Not concentrating very well today.

Abusing Assigned to mean "merged in alsuren/call and available at
http://people.freedesktop.org/~alsuren/telepathy-spec-call/spec/".

merged to master