1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
|
<?xml version="1.0" ?>
<node name="/Call1_Content_Media_Description"
xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
<tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
<tp:copyright>Copyright © 2009-2010 Nokia Corporation</tp:copyright>
<tp:license xmlns="http://www.w3.org/1999/xhtml">
<p>This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.</p>
<p>This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.</p>
<p>You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301, USA.</p>
</tp:license>
<interface name="im.telepathy.v1.Call1.Content.MediaDescription">
<tp:added version="0.25.2">(as stable API)</tp:added>
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
This object represents a remote Description Offer to which the local
streaming implementation should reply with its local Description.
This is intended as a temporary transactional object for use with <tp:dbus-ref
namespace="imt1.Call1">Content.Interface.Media</tp:dbus-ref>.
There will always be 0 or 1 MediaDescription object per Content.
In most cases, this object will stay alive until you call either
<tp:member-ref>Accept</tp:member-ref> or
<tp:member-ref>Reject</tp:member-ref>, and then disappear.
There are some cases (e.g. an endpoint being removed from the call)
where a MediaDescription object will disappear before you have had a
chance to either Accept or Reject it.
</tp:docstring>
<method name="Accept" tp:name-for-bindings="Accept">
<arg name="Local_Media_Description" direction="in"
type="a{sv}" tp:type="Media_Description_Properties">
<tp:docstring>
The local description to send to the remote contacts and
to use in the <tp:dbus-ref
namespace="imt1.Call1">Content</tp:dbus-ref>.
</tp:docstring>
</arg>
<tp:docstring>
Accepts the updated Description and update the corresponding
local description. If FurtherNegotiationRequired is True,
calling this method will generally cause a network round-trip
and a new MediaDescription to be offered (hopefully with
FurtherNegotiationRequired set to False).
</tp:docstring>
<tp:possible-errors>
<tp:error name="im.telepathy.v1.Error.InvalidArgument">
<tp:docstring>
The description given is invalid in some way.
</tp:docstring>
</tp:error>
</tp:possible-errors>
</method>
<method name="Reject" tp:name-for-bindings="Reject">
<tp:docstring>
Reject the proposed update to the remote description.
</tp:docstring>
<arg name="Reason" type="(uuss)" tp:type="Call_State_Reason"
direction="in">
<tp:docstring>
A structured reason for the rejection.
</tp:docstring>
</arg>
</method>
<property name="Interfaces" tp:name-for-bindings="Interfaces"
type="as" tp:type="DBus_Interface[]" access="read" tp:immutable="yes">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>Extra interfaces provided by this media description. This SHOULD
NOT include the Description interface itself.</p>
</tp:docstring>
</property>
<property name="FurtherNegotiationRequired"
tp:name-for-bindings="Further_Negotiation_Required" type="b"
access="read" tp:immutable="yes">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml" >
<p> If this is set to True by the CM in a MediaDescriptionOffer, it
means "This is an offer under the SDP Offer/Answer model. Whatever
you accept this offer with is what I will send to the other side in
my answer."
If this is set to False by the CM then it means "This is an Answer
under the SDP Offer/Answer model, and if it remains False in the
Accept(), no further codec negotiation needs to happen."
If this is set to True by the streaming implementation (e.g. in an
Accept or UpdateLocalMediaDescription call) then a new SDP
Offer/Answer round-trip will be initiated.
</p>
</tp:docstring>
</property>
<property name="HasRemoteInformation"
tp:name-for-bindings="Has_Remote_Information" type="b"
access="read" tp:immutable="yes">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml" >
<p> True if this offer contains information from the remote side:
If False then the Accept response solely depends on the
capabilities and preferences of the local side.
In most protocols this property will be False for the initial
DescriptionOffer on an outgoing call.
</p>
</tp:docstring>
</property>
<property name="Codecs"
tp:name-for-bindings="Codecs"
type="a(usuuba{ss})" tp:type="Codec[]" access="read"
tp:immutable="yes">
<tp:docstring>
A list of codecs the remote contact supports. When used with
<tp:member-ref>Accept</tp:member-ref>, it means the locally supported
codecs.
</tp:docstring>
</property>
<property name="RemoteContact" tp:name-for-bindings="Remote_Contact"
type="u" tp:type="Contact_Handle" access="read" tp:immutable="yes">
<tp:docstring>
The contact handle that this description applies to.
This property can be used as an opaque identifier, and searched for in
<tp:dbus-ref namespace="imt1.Call1.Stream"
>RemoteMembers</tp:dbus-ref> for each Stream in this Content, to
determine which Stream this MediaDescription applies to. If multiple
MediaDescriptions apply to the same Stream, the
<tp:member-ref>SSRCs</tp:member-ref> property should be used to
separate media before decoding.
If this property is 0, this MediaDescription applies to all streams,
so the above matching method is unneccesary (e.g. in conference calls
with a mixer, media from all participants is mixed into one stream).
When calling Accept or UpdateLocalMediaDescription, this should always
be set to 0, or omitted, because it is assumed that you send the same
MediaDescription to everyone (Encoding a stream separately for each
contact in a call is inefficient, and should be avoided).
</tp:docstring>
</property>
<tp:mapping name="Contact_SSRCs_Map">
<tp:member name="Contact" type="u" tp:type="Handle">
<tp:docstring>
The remote contact these SSRCs belong to or 0.
</tp:docstring>
</tp:member>
<tp:member name="SSRCs" type="au">
<tp:docstring>
The list of Synchronisation Sources.
</tp:docstring>
</tp:member>
</tp:mapping>
<property name="SSRCs" tp:name-for-bindings="SSRCs"
type="a{uau}" tp:type="Contact_SSRCs_Map" access="read" tp:immutable="yes">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>A map from Handle to list of Synchronisation Sources, as defined by
RFC 3550.</p>
<p>Some protocols require the negotiation of SSRC identifiers for RTP
streams. If this is the case, then MediaDescription offers will appear
with this property set. The streaming implementation should then call
<tp:member-ref>Accept</tp:member-ref> with a map from 0 to a
list containing a single SSRC (which does not collide with these,
or any previously seen SSRCs). If a new MediaDescription offer
appears with an SSRC the same as one in <tp:dbus-ref
namespace="imt1.Call1.Content.Interface.Media"
>LocalMediaDescriptions</tp:dbus-ref>, then the streaming
implementation should pick a new SSRC to resolve the collision.</p>
<p>It is expected that this list will normally be at most one element long,
but it is kept as a list for extensibility. The concatenation of all
SSRCs associated with a Stream should contain no duplicate entries. If
there are collisions, then it is the responsibility of the protocol
implementation to resolve them and generate new offers.</p>
<p>If this property is omitted, then the streaming implementation can
assume that there is only one MediaDescription per Stream.</p>
<p>If there is a single multicast Call Stream with multiple
Remote Members, and all members are forced to use the same
MediaDescription, this map can be used by the streaming implementation
to determine which video sources belong to which contacts (e.g. in
order to put a name under each face in the call)</p>
</tp:docstring>
</property>
<tp:mapping name="Media_Description_Properties">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>
A mapping containing all properties that define the information from a
<tp:dbus-ref
namespace="imt1.Call1.Content"
>MediaDescription</tp:dbus-ref> and its interfaces.
</p>
<p>
If <tp:dbus-ref namespace="imt1.Call1.Content.MediaDescription"
>HasRemoteInformation</tp:dbus-ref> is True, then this mapping
will always contains at least
<tp:dbus-ref namespace="imt1.Call1.Content.MediaDescription"
>Codecs</tp:dbus-ref>
</p>
</tp:docstring>
<tp:member name="Media_Description_Property"
type="s" tp:type="DBus_Qualified_Member">
<tp:docstring>
A D-Bus interface name, followed by a dot and a D-Bus property name.
</tp:docstring>
</tp:member>
<tp:member name="Media_Description_Property_Value" type="v">
<tp:docstring>
The value of the property
</tp:docstring>
</tp:member>
</tp:mapping>
</interface>
</node>
<!-- vim:set sw=2 sts=2 et ft=xml: -->
|
