In ICE, the Caller is normally in controlling mode (and the cally in controlled). Except if the Caller is doing ICE-Lite, then it's reversed.. We need a way to indicate what is going in the Stream (or possibly the Endpoint?).
http://git.collabora.co.uk/?p=user/danni/telepathy-spec.git;a=shortlog;h=refs/heads/call-31280
I forgot to add, I think we may need a way for tp-fs/libnice to tell the CM that its role has been reversed.. Because the controlling agent must send an updated offer.. if I read RFC 5245 correctly.
A SetLocalControlMode() ?
maybe just writing to the property.. not sure at all. and the property isnt immutable then.. Btw, it should be on Stream.I.Media
(In reply to comment #2) > I forgot to add, I think we may need a way for tp-fs/libnice to tell the CM > that its role has been reversed.. Because the controlling agent must send an > updated offer.. if I read RFC 5245 correctly. Yes, you read it right, it says the controlling agent is responsible for sending the updated offer, and in section 7.1.3.1 (Failure Cases), it talks about the effect of a role reversal : "The change in role will also impact whether the agent is responsible for selecting nominated pairs and generating updated offers upon conclusion of ICE." So a change in role must be sent back from the ICE agent to the signaling handler (CM).
On the Endpoint: Property: Controlling: b Method: SetControlling: b Signal: ControllingChanged: b Endpoint: Property: IsICELite b Maybe some way to set it on the Stream: Property: LocalIsICELite b Method: SetICELite b or use dbus Property modifications !?!?
Decided to make the assumption that the local side is ICE Full, as ocrete recommended in our meeting. http://git.collabora.co.uk/?p=user/alsuren/telepathy-spec.git;a=shortlog;h=refs/heads/controlling I'm not quite sure how SetControlling() will work in the call forking case, so I've left a little "here be dragons" in there, and we can sort it out when we've implemented it.
Endpoint can have different controlling orientations, its fine..
If you need to send "Hi. I'm the controlling side" in the SDP, then in a forked call, you will be sending it to all remote endpoints... but that case won't ever happen if we're the calling side and also ICE Full, right? Is there ever a time when we will want to call SetControlling(False)? I don't think I've quite understood this part of the spec. I'm going to leave this warning in here until someone can prove to me that it's never going to a problem, or I've implemented + tested ICE/SIP forking.
(In reply to comment #9) > If you need to send "Hi. I'm the controlling side" in the SDP, then in a forked > call, you will be sending it to all remote endpoints... but that case won't > ever happen if we're the calling side and also ICE Full, right? > > Is there ever a time when we will want to call SetControlling(False)? I don't > think I've quite understood this part of the spec. I'm going to leave this > warning in here until someone can prove to me that it's never going to a > problem, or I've implemented + tested ICE/SIP forking. I'm actually quite looking forward to getting this reviewed/merged, so I can get a bit closer to implementing it. Should I merge http://git.collabora.co.uk/?p=user/alsuren/telepathy-spec.git;a=shortlog;h=refs/heads/controlling with or without the last commit?
merge/implement it then ! If it doesn't work, we can always change it later
Abusing Assigned to mean "merged in alsuren/call and available at http://people.freedesktop.org/~alsuren/telepathy-spec-call/spec/".
merged to master
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.