summaryrefslogtreecommitdiff
path: root/spec/Call1_Content_Interface_Media.xml
blob: 4b2f30ae652a84a693f36299854d9cf54cc91213 (plain)
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
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
<?xml version="1.0" ?>
<node name="/Call1_Content_Interface_Media"
  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.telepathy1.Call1.Content.Interface.Media">
    <tp:added version="0.25.2">(as stable API)</tp:added>
    <tp:requires interface="im.telepathy1.Call1.Content"/>

    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
      <p>Interface to use by a software implementation of media
        streaming. The reason behind splitting the members of this
        interface out from the main <tp:dbus-ref
        namespace="imt1.Call1">Content</tp:dbus-ref> interface is
        that the software is not necessarily what controls the
        media. An example of this is in GSM phones, where the CM just
        tells the phone to dial a number and it does the audio routing
        in a device specific hardware way and the CM does not need
        to concern itself with codecs.</p>

      <h4>Codec Negotiation</h4>

      <p>When a new <tp:dbus-ref
        namespace="imt1.Channel.Type">Call1</tp:dbus-ref> channel
        appears (whether it was requested or not) a <tp:dbus-ref
        namespace="imt1.Call1.Content">MediaDescription</tp:dbus-ref>
        object will either be waiting in the
        <tp:member-ref>MediaDescriptionOffer</tp:member-ref> property, or will
        appear at some point via the
        <tp:member-ref>NewMediaDescriptionOffer</tp:member-ref> signal.</p>

      <p>If nothing is known about the remote side's Media capabilities
        (e.g. outgoing SIP/XMPP call), this <tp:dbus-ref namespace="imt1.Call1.Content"
        >MediaDescription</tp:dbus-ref> will pop up with {<tp:dbus-ref
        namespace="imt1.Call1.Content.MediaDescription"
          >HasRemoteInformation</tp:dbus-ref> = false, <tp:dbus-ref
        namespace="imt1.Call1.Content.MediaDescription"
          >FurtherNegotiationRequired</tp:dbus-ref> = true}, and the local
        user's streaming implementation SHOULD call 
        <tp:dbus-ref namespace="imt1.Call1.Content.MediaDescription"
        >Accept</tp:dbus-ref>,
        with a description of all supported codecs and other features.
        The CM will then send this information to the remote side (and
        <tp:member-ref>LocalMediaDescriptionChanged</tp:member-ref> will fire
        with details of the description passed into <tp:dbus-ref
          namespace="imt1.Call1.Content.MediaDescription"
          >Accept</tp:dbus-ref> for debugging purposes).
      </p>
      <p>When the remote codecs and other content information are available
        (e.g. Remote user replies to initial offer, or sends a new offer of
        their own, a new <tp:dbus-ref namespace="imt1.Call1.Content"
         >MediaDescription</tp:dbus-ref> will appear, with {<tp:dbus-ref
         namespace="imt1.Call1.Content.MediaDescription"
         >HasRemoteInformation</tp:dbus-ref> = true, <tp:dbus-ref
        namespace="imt1.Call1.Content.MediaDescription"
          >FurtherNegotiationRequired</tp:dbus-ref> = false},
        and the <tp:dbus-ref
        namespace="imt1.Call1.Content.MediaDescription"
          >Codecs</tp:dbus-ref>
        property on the description offer set to the codecs which are
        supported by the remote contact. The local user's streaming
        implementation SHOULD then call Accept, with a description
        that is compatible with the one one in the offer. After the codec
        set is accepted, both
         <tp:member-ref>LocalMediaDescriptionChanged</tp:member-ref> and
         <tp:member-ref>RemoteMediaDescriptionsChanged</tp:member-ref>
        will fire to signal their respective changes, to aid with debugging.
        Note that if <tp:dbus-ref namespace="imt1.Call1.Content.MediaDescription"
        >Accept</tp:dbus-ref> is called, with <tp:dbus-ref
        namespace="imt1.Call1.Content.MediaDescription"
          >FurtherNegotiationRequired</tp:dbus-ref> set to false,
        the CM should be able to rely on the fact that the
        description passed into Accept is compatible with the one in the
        offer, and the description passed into Accept will not be signalled to
        the remote side.
      </p>

      <h4>Changing codecs mid-call</h4>

      <p>To update the codecs in the local (and optionally remote) media
        descriptions mid-call, the
        <tp:member-ref>UpdateLocalMediaDescription</tp:member-ref> method
        should be called with details of the new codec list. If this is
        accepted, then
        <tp:member-ref>LocalMediaDescriptionChanged</tp:member-ref>
        will be emitted with the new codec set.
      </p>
      <p> If parameters requiring negotiation are changed, then the
        <tp:dbus-ref
        namespace="imt1.Call1.Content.MediaDescription"
          >FurtherNegotiationRequired</tp:dbus-ref> property should be set to
        TRUE, and the new media description should
        only be used once they come in a new MediaDescriptionOffer
      </p>

      <p>If the other side decides to update his or her codec list
        during a call, a new <tp:dbus-ref
        namespace="imt1.Call1.Content">MediaDescription</tp:dbus-ref>
        object will appear through
        <tp:member-ref>NewMediaDescriptionOffer</tp:member-ref> which should be
        acted on as documented above.</p>

      <h4>Protocols without negotiation</h4>

      <p>For protocols where the codecs are not negotiable, the initial content's <tp:dbus-ref
        namespace="imt1.Call1.Content">MediaDescription</tp:dbus-ref>
        object will appear with <tp:dbus-ref
        namespace="imt1.Call1.Content.MediaDescription"
          >HasRemoteInformation</tp:dbus-ref>,
        set to true and the known supported codec values in <tp:dbus-ref
        namespace="imt1.Call1.Content.MediaDescription"
          >Codecs</tp:dbus-ref>.
      </p>
    </tp:docstring>

    <tp:struct name="Codec" array-name="Codec_List">
      <tp:docstring>
        A description of a codec.
      </tp:docstring>
      <tp:member name="Identifier" type="u">
        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
          Numeric identifier for the codec. This will be used as the PT in the
          SDP or content description.
        </tp:docstring>
      </tp:member>
      <tp:member name="Name" type="s">
        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
          The name of the codec.
        </tp:docstring>
      </tp:member>
      <tp:member name="Clockrate" type="u">
        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
          The clockrate of the codec.
        </tp:docstring>
      </tp:member>
      <tp:member name="Channels" type="u">
        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
          Number of channels of the codec if applicable, otherwise 0.
        </tp:docstring>
      </tp:member>
      <tp:member name="Updated" type="b">
        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
          This should be set to true in calls to <tp:dbus-ref
              namespace="imt1.Call1.Content.MediaDescription"
          >Accept</tp:dbus-ref> and
          <tp:member-ref>UpdateLocalMediaDescription</tp:member-ref> if this
          codec has changed in a way that needs to be signalled over the
          network. If it is set to false, the CM is allowed ignore any
          differences between the current parameters and the previous ones
          <tp:rationale>
            This mechanism may be used to save bandwidth and avoid the CM
            having to calculate diffs against previous versions of this
            struct, which can lead to false-positives (e.g. redundant ptime
            updates).
          </tp:rationale>
        </tp:docstring>
      </tp:member>
      <tp:member name="Parameters" type="a{ss}" tp:type="String_String_Map">
        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
          Extra parameters for this codec.
        </tp:docstring>
      </tp:member>
    </tp:struct>

    <tp:mapping name="Contact_Codec_Map">
      <tp:docstring>
        A map from contact to the list of codecs he or she supports.
      </tp:docstring>
      <tp:member name="Handle" type="u" tp:type="Contact_Handle">
        <tp:docstring>
          A contact handle.
        </tp:docstring>
      </tp:member>
      <tp:member name="Codecs" type="a(usuuba{ss})" tp:type="Codec[]">
        <tp:docstring>
          The codecs that the contact supports.
        </tp:docstring>
      </tp:member>
    </tp:mapping>

    <tp:mapping name="Contact_Media_Description_Properties_Map">
      <tp:member name="Remote_Contact" type="u" tp:type="Handle">
        <tp:docstring>
          The remote contact this description refers to or 0. This matches the
          <tp:dbus-ref namespace="imt1.Call1.Content.MediaDescription"
            >RemoteContact</tp:dbus-ref> property on
          <tp:dbus-ref namespace="imt1.Call1.Content"
                    >MediaDescription</tp:dbus-ref>
        </tp:docstring>
      </tp:member>
      <tp:member name="Media_Description_Properties" type="a{sv}"
          tp:type="Media_Description_Properties">
        <tp:docstring>
          The properties of the description
        </tp:docstring>
      </tp:member>
    </tp:mapping>

    <tp:struct name="Media_Description_Offer">
      <tp:docstring>
        The remote description offer and its information
      </tp:docstring>
      <tp:member name="Media_Description" type="o">
        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
          The object path to the <tp:dbus-ref namespace="imt1.Call1.Content"
          >MediaDescription</tp:dbus-ref>
        </tp:docstring>
      </tp:member>
      <tp:member name="Properties" type="a{sv}"
           tp:type="Media_Description_Properties">
        <tp:docstring>
          The immutable properties of all interfaces of the codec description.

          <tp:rationale>
          Having all the codec description properties here saves a D-Bus
          round-trip - it shouldn't be necessary to get the properties from the
          MediaDescription object, in practice.
          </tp:rationale>
        </tp:docstring>
      </tp:member>
    </tp:struct>

    <method name="UpdateLocalMediaDescription"
            tp:name-for-bindings="Update_Local_Media_Description">
      <tp:docstring>
        Update the local codec mapping and other interfaces of the
        MediaDescription. This method should only be
        used during an existing call to update the local media description.
        This may trigger a re-negotiation which may result in new
        new MediaDescriptionOffers if the "FurtherNegotiationRequired"
        property is TRUE.
        Otherwise, only parameters which strictly describe the media being sent
        can be changed.
      </tp:docstring>
      <arg name="MediaDescription" direction="in" type="a{sv}"
           tp:type="Media_Description_Properties">
        <tp:docstring>
          The updated media description that the local side wants to use.
        </tp:docstring>
      </arg>
      <tp:possible-errors>
        <tp:error name="im.telepathy1.Error.NotImplemented">
          <tp:docstring>
            The protocol does not support changing the codecs mid-call.
          </tp:docstring>
        </tp:error>
        <tp:error name="im.telepathy1.Error.InvalidArgument">
          <tp:docstring>
            The description given is invalid in some way.
          </tp:docstring>
        </tp:error>
     </tp:possible-errors>
    </method>

    <property name="RemoteMediaDescriptions"
        tp:name-for-bindings="Remote_Media_Descriptions"
        type="a{ua{sv}}"
        tp:type="Contact_Media_Description_Properties_Map" access="read">
      <tp:docstring>
        <p>A map from contact handles to descriptions supported by that
          contact.</p>

        <p>Keys of this map will appear in at most one <tp:dbus-ref
          namespace="imt1.Call1.Stream">RemoteMembers</tp:dbus-ref>.
          See <tp:dbus-ref namespace="imt1.Call1.Content.MediaDescription"
          >RemoteContact</tp:dbus-ref> for more details on how to map between
          MediaDescriptions and Streams.</p>
      </tp:docstring>
    </property>

    <property name="LocalMediaDescriptions"
        tp:name-for-bindings="Local_Media_Descriptions"
        type="a{ua{sv}}"
        tp:type="Contact_Media_Description_Properties_Map" access="read">
      <tp:docstring>
        <p>A map from contact handles to the descriptions the local side
           responsed with.</p> </tp:docstring>
    </property>

    <signal name="NewMediaDescriptionOffer"
        tp:name-for-bindings="New_Media_Description_Offer">
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>Emitted when a new <tp:dbus-ref namespace="imt1.Call1.Content"
          >MediaDescription</tp:dbus-ref> appears. The streaming
          >implementation MUST respond by calling the
          <tp:dbus-ref namespace="imt1.Call1.Content.MediaDescription"
          >Accept</tp:dbus-ref> or <tp:dbus-ref
          namespace="imt1.Call1.Content.MediaDescription"
          >Reject</tp:dbus-ref> method on the description object appeared.</p>

        <p>Emission of this signal indicates that the
          <tp:member-ref>MediaDescriptionOffer</tp:member-ref> property has
          changed to
            <code>(Description, Contact, MediaDescriptionProperties)</code>.</p>

        <p>When the MediaDescriptionOffer has been dealt with then
          <tp:dbus-ref namespace="imt1.Call1.Content.Interface.Media"
            >MediaDescriptionOfferDone</tp:dbus-ref> must be emitted
          before <tp:dbus-ref
            namespace="imt1.Call1.Content.Interface.Media"
              >NewMediaDescriptionOffer</tp:dbus-ref> is emitted again.
        </p>

      </tp:docstring>
      <arg name="Media_Description" type="o">
        <tp:docstring>
          The object path of the new media description. This replaces any
          previous media description.
        </tp:docstring>
      </arg>
      <arg name="Properties" type="a{sv}"
           tp:type="Media_Description_Properties">
        <tp:docstring>
          The immutable properties of the remote media description.

          <tp:rationale>
          Having all the MediaDescription properties here saves a D-Bus
          round-trip - it shouldn't be necessary to get the properties from the
          MediaDescription object, in practice.
          </tp:rationale>
        </tp:docstring>
      </arg>
    </signal>

    <signal name="MediaDescriptionOfferDone"
        tp:name-for-bindings="Media_Description_Offer_Done">
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>Emitted when a <tp:dbus-ref namespace="imt1.Call1.Content"
          >MediaDescription</tp:dbus-ref> has been handled. </p>
        <p>Emission of this signal indicates that the
          <tp:member-ref>MediaDescriptionOffer</tp:member-ref> property has
          changed to
            <code>("/", 0, {})</code>.</p>
      </tp:docstring>
    </signal>


    <signal name="LocalMediaDescriptionChanged"
      tp:name-for-bindings="Local_Media_Description_Changed">

      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>Change notification for
            <tp:dbus-ref namespace="imt1.Call1.Content.Interface.Media"
              >LocalMediaDescriptions</tp:dbus-ref>
        </p>
      </tp:docstring>

      <arg name="Updated_Media_Description" type="a{sv}"
        tp:type="Media_Description_Properties">
        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
          <p>The local content description that was updated</p>
        </tp:docstring>
      </arg>
    </signal>

    <signal name="RemoteMediaDescriptionsChanged"
      tp:name-for-bindings="Remote_Media_Descriptions_Changed">

      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>Change notification for
            <tp:dbus-ref namespace="imt1.Call1.Content.Interface.Media"
              >RemoteMediaDescriptions</tp:dbus-ref>
        </p>
      </tp:docstring>

      <arg name="Updated_Media_Descriptions" type="a{ua{sv}}"
          tp:type="Contact_Media_Description_Properties_Map">
        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
          <p>The remote content descriptions that were updated</p>
        </tp:docstring>
      </arg>
    </signal>

    <signal name="MediaDescriptionsRemoved"
      tp:name-for-bindings="Media_Descriptions_Removed">

      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>Removal notification for
            <tp:dbus-ref namespace="imt1.Call1.Content.Interface.Media"
              >RemoteMediaDescriptions</tp:dbus-ref>
            and
            <tp:dbus-ref namespace="imt1.Call1.Content.Interface.Media"
              >LocalMediaDescriptions</tp:dbus-ref>
        </p>
      </tp:docstring>

      <arg name="Removed_Media_Descriptions" type="au"
          tp:type="Contact_Handle[]">
        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
          <p>The local and remote content descriptions that are no longer part
             of this content</p>
        </tp:docstring>
      </arg>
    </signal>

    <property name="MediaDescriptionOffer"
        tp:name-for-bindings="Media_Description_Offer"
      type="(oa{sv})" tp:type="Media_Description_Offer" access="read">
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>The object path to the current
          <tp:dbus-ref namespace="imt1.Call1.Content"
           >MediaDescription</tp:dbus-ref> object, its
            <tp:dbus-ref namespace="imt1.Call1.Content.MediaDescription"
            >RemoteContact</tp:dbus-ref> and
            a mapping of the MediaDescriptions properties.
            If the object path is "/" then there isn't an outstanding
            content description, and the mapping MUST be empty.</p>

        <tp:rationale>
          Having all <tp:dbus-ref
          namespace="imt1.Call1.Content">MediaDescription</tp:dbus-ref>
          properties here saves a D-Bus round-trip - it shouldn't be
          necessary to get these properties from the Content MediaDescription
          object, in practice.
        </tp:rationale>

        <p>Change notification is via the
          <tp:member-ref>NewMediaDescriptionOffer</tp:member-ref> and
          <tp:member-ref>MediaDescriptionOfferDone</tp:member-ref> signals.
         </p>
      </tp:docstring>
    </property>

    <tp:enum name="Call_Content_Packetization_Type" type="u">
      <tp:added version="0.21.2"/>
      <tp:docstring>
        A packetization method that can be used for a content.
      </tp:docstring>

      <tp:enumvalue suffix="RTP" value="0">
        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
          Real-time Transport Protocol, as documented by RFC 3550.
        </tp:docstring>
      </tp:enumvalue>

      <tp:enumvalue suffix="Raw" value="1">
        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
          Raw media.
        </tp:docstring>
      </tp:enumvalue>

      <tp:enumvalue suffix="MSN_Webcam" value="2">
        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
          MSN webcam. This is the video-only one-way type which was
          used in earlier versions of WLM. Although no longer used,
          modern WLM clients still support the MSN webcam protocol.
        </tp:docstring>
      </tp:enumvalue>
    </tp:enum>

    <property name="Packetization" tp:name-for-bindings="Packetization"
      type="u" tp:type="Call_Content_Packetization_Type" access="read"
      tp:immutable="yes">
      <tp:added version="0.21.2"/>
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>The packetization method in use for this content.</p>
      </tp:docstring>
    </property>

    <signal name="DTMFChangeRequested"
      tp:name-for-bindings="DTMF_Change_Requested">
      <tp:docstring>
        Used by the CM to relay instructions from <tp:dbus-ref
        namespace="imt1">Channel.Interface.DTMF1</tp:dbus-ref> to the streaming
        implementation. If any contact in this call supports the
        telephone-event codec in their MediaDescription, this event should be
        sent as outlined in RFC 4733. Otherwise, it should be sent as an
        audible tone.
      </tp:docstring>
      <arg name="Event" type="y" tp:type="DTMF_Event">
        <tp:docstring>
          The event to send (or stop sending).
        </tp:docstring>
      </arg>
      <arg name="State" type="u" tp:type="Sending_State">
        <tp:docstring>
          Either <tp:value-ref type="Sending_State">Pending_Send</tp:value-ref> or
          <tp:value-ref type="Sending_State">Pending_Stop_Sending</tp:value-ref>.
        </tp:docstring>
      </arg>
    </signal>

    <method name="AcknowledgeDTMFChange"
      tp:name-for-bindings="Acknowledge_DTMF_Change">
      <tp:docstring>
        Called by the streaming implementation in response to
        <tp:member-ref>DTMFChangeRequested</tp:member-ref> to confirm that it
        has started or stopped sending the event in question.
      </tp:docstring>
      <arg name="Event" type="y" tp:type="DTMF_Event" direction="in">
        <tp:docstring>
          The event referred to in the corresponding
          <tp:member-ref>DTMFChangeRequested</tp:member-ref> signal.
        </tp:docstring>
      </arg>
      <arg name="State" type="u" tp:type="Sending_State" direction="in">
        <tp:docstring>
          Either <tp:value-ref type="Sending_State">Sending</tp:value-ref> or
          <tp:value-ref type="Sending_State">None</tp:value-ref>.
        </tp:docstring>
      </arg>
    </method>

    <property name="CurrentDTMFEvent"
      tp:name-for-bindings="Current_DTMF_Event" type="y" tp:type="DTMF_Event"
      access="read">
      <tp:docstring>
        The currently requested DTMF event (for state-recoverability of
        <tp:member-ref>DTMFChangeRequested</tp:member-ref>). Should be ignored
        if <tp:member-ref>CurrentDTMFState</tp:member-ref> is None.
      </tp:docstring>
    </property>

    <property name="CurrentDTMFState"
      tp:name-for-bindings="Current_DTMF_State" type="u" tp:type="Sending_State"
      access="read">
      <tp:docstring>
        The current DTMF state (for state-recoverability of
        <tp:member-ref>DTMFChangeRequested</tp:member-ref>).
      </tp:docstring>
    </property>

    <method name="Fail" tp:name-for-bindings="Fail">
      <tp:docstring>
        Signal an unrecoverable error for this content, and remove it.
      </tp:docstring>
      <arg direction="in" name="Reason" type="(uuss)"
        tp:type="Call_State_Reason">
        <tp:docstring>
          A reason struct describing the error.
        </tp:docstring>
      </arg>
    </method>
  </interface>
</node>
<!-- vim:set sw=2 sts=2 et ft=xml: -->