Codebase list telepathy-spec / 7250176
Imported Upstream version 0.23.4 Jonny Lamb 12 years ago
30 changed file(s) with 4069 addition(s) and 940 deletion(s). Raw diff Collapse all Expand all
+1589
-0
ChangeLog less more
0 commit c2b50e990e649b0247c3f6b09a5eefb7f3f7a280
1 Author: Xavier Claessens <xclaesse@gmail.com>
2 Date: Thu Sep 29 19:13:44 2011 +0200
3
4 replace UNRELEASED
5
6 commit 3728724a1f0b0f2669a728a0bc15ae053999f035
7 Author: Xavier Claessens <xclaesse@gmail.com>
8 Date: Thu Sep 29 16:00:08 2011 +0200
9
10 Version 0.23.4
11
12 commit 2dc3a3e100b517d50321a0028bdf7a5345a1ae52
13 Author: Xavier Claessens <xclaesse@gmail.com>
14 Date: Thu Sep 29 15:59:11 2011 +0200
15
16 NEWS for 0.23.4
17
18 commit a1d6bb213d7d4668100d8ffb66852788398fcaf1
19 Author: Xavier Claessens <xclaesse@gmail.com>
20 Date: Wed Jun 29 14:29:49 2011 +0200
21
22 Add MemberIdentifiers, SelfContactChanged and HandleOwnersChangedDetailed
23
24 Fixes fd.o#38248
25
26 commit dce867f9306d6f0bcb4d88f96b31a0879396d674
27 Author: Will Thompson <will.thompson@collabora.co.uk>
28 Date: Thu Aug 25 14:33:42 2011 +0100
29
30 AM.CreateAccount: prettify error descriptions
31
32 commit 6e1a35115f6c079dcbcb1caf556897ab5c3e08ba
33 Author: Will Thompson <will.thompson@collabora.co.uk>
34 Date: Thu Aug 25 14:32:49 2011 +0100
35
36 AM.CreateAccount: make error conditions not overlap
37
38 commit f5ea5f1bbfbbae19ca6823c997410820b576a587
39 Author: Olivier Le Thanh Duong <olivier@lethanh.be>
40 Date: Sun Aug 7 16:41:21 2011 +0200
41
42 Fix template for EMITS_CHANGED_NONE
43
44 Remove the errorneous </div> in EMITS_CHANGED_NONE template code
45 in interface.html which prevented Player_Node.html from rendering
46 correctly
47
48 commit 42497377116e555f4243185cfdd9f009906b489e
49 Author: Will Thompson <will.thompson@collabora.co.uk>
50 Date: Mon Jul 25 15:47:24 2011 +0100
51
52 AccountManager: remove stuff about service activation
53
54 MC is service-activatable.
55
56 commit cc7e9cc5429ca7bf9a79ec601f50c8f2efc39e16
57 Merge: 57b56d8 38ef30d
58 Author: David Laban <david.laban@collabora.co.uk>
59 Date: Tue Jul 19 14:44:22 2011 -0400
60
61 Merge branch 'call'
62
63 For full discussion, see bugs.fd.o#38986
64 and the whiteboard string "Call" on bugs.fd.o.
65
66 Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
67 Reviewed-by: Olivier Crête <olivier.crete@collabora.co.uk>
68
69 commit 38ef30d6db78af852bed3ff1ca241e0236be6c63
70 Author: Will Thompson <will.thompson@collabora.co.uk>
71 Date: Fri Jul 15 15:23:26 2011 +0100
72
73 Text: add cross-references to the overview
74
75 Some of these are beautiful new <tp:value-ref/>s I noticed were missing;
76 the others are plain old dbus-refs.
77
78 commit 7e43d82309b74bd4c28d6d015fbe77b6b58b8d52
79 Author: Will Thompson <will.thompson@collabora.co.uk>
80 Date: Fri Jul 15 15:22:12 2011 +0100
81
82 Text: clarify a reference to Handle_Type_Room
83
84 Now that the body of <tp:value-ref/> is always shown unmangled (except
85 to add the link), “Text channels with _Room_” is not very clear. (It was
86 not very clear before.) Now we explicitly reference the TargetHandleType
87 property.
88
89 commit 71051fc92c05a42c237c98cbd1ee9956e34f197b
90 Author: David Laban <david.laban@collabora.co.uk>
91 Date: Thu Jul 14 23:40:44 2011 -0400
92
93 Re-work paragraph describing CallState changes for an outgoing call.
94
95 Thanks to wjt for pointing this out.
96
97 commit 3d64ab3880f0e2f8aa1e79c4f8e9d2fd6908ee26
98 Author: David Laban <david.laban@collabora.co.uk>
99 Date: Thu Jul 14 23:05:32 2011 -0400
100
101 Make tp:value-ref's type attribute optional
102
103 * Also: don't ever rewrite the node's text. This means:
104 * If you want the long-form, use:
105 <tp:value-ref>Type_Name_Value</tp:value-ref>
106 * If you want the short form, use:
107 <tp:value-ref type="Type_Name">Value</tp:value-ref>
108
109 This changes the html output of all current value-refs to use the
110 short form.
111
112 commit cae69cb8245d68493f310c15b20960a943328801
113 Author: David Laban <david.laban@collabora.co.uk>
114 Date: Thu Jul 14 22:25:17 2011 -0400
115
116 Correct <tp:value-ref/>-caught type mismatches.
117
118 commit 56b89ebfdb16bcb932ae416386361f6bf86bdb89
119 Author: David Laban <david.laban@collabora.co.uk>
120 Date: Thu Jul 14 22:04:23 2011 -0400
121
122 Convert <tp:type/>_Value to <tp:value-ref/>
123
124 sed -i 's!<tp:type>\(\w*\)</tp:type>_\(\w*\)\
125 !<tp:value-ref type="\1">\2</tp:value-ref>!' spec/*.xml
126
127 commit 3b8f91b728d59fa717ee5abbd54ca21b523124ac
128 Author: David Laban <david.laban@collabora.co.uk>
129 Date: Thu Jul 14 22:04:19 2011 -0400
130
131 <tp:value-ref> for semantic enumvalues.
132
133 This should ensure that our enum value names don't go out of sync with the
134 references to them.
135
136 Note that the links don't *quite* go to the actual value, but it should be within
137 view once the link is clicked. This is not a regression.
138
139 commit a8b99977a2cd3b722db1e4bbdcdabd9ad588e9d7
140 Author: David Laban <david.laban@collabora.co.uk>
141 Date: Thu Jul 14 20:40:02 2011 -0400
142
143 Clean up the MuteState documentation wording.
144
145 There were some artifacts from when it was a boolean that could only apply
146 to the whole channel.
147
148 commit e5e882661fb83c321f945e530bcb502429a43989
149 Author: David Laban <david.laban@collabora.co.uk>
150 Date: Thu Jul 14 20:33:39 2011 -0400
151
152 Audit all occurrences of "Call1" in the spec
153
154 Seems that /Call[."<]/ was a bit too inclusive as a match rule.
155
156 Also spotted a missing '.' so I thought I should include it.
157
158 commit 3f962ace757d8d323effd5d316c5d5c391c6a698
159 Author: David Laban <david.laban@collabora.co.uk>
160 Date: Thu Jul 14 19:58:56 2011 -0400
161
162 Add Reason arg to MD.Reject()
163
164 commit 57b56d89842798dfb93f996015c4a79cc1cd5afd
165 Author: Will Thompson <will.thompson@collabora.co.uk>
166 Date: Thu Jul 14 17:07:14 2011 +0100
167
168 bump me a nano
169
0170 commit 134752a6e93b0c7d74482d1a0dc1a250c244c7f8
1171 Author: Will Thompson <will.thompson@collabora.co.uk>
2172 Date: Thu Jul 14 16:27:10 2011 +0100
8178 Date: Thu Jul 14 16:26:35 2011 +0100
9179
10180 NEWS for 0.23.3
181
182 commit 087a5e09f8e812caca71117fcccb743aa666e1b3
183 Author: Will Thompson <will.thompson@collabora.co.uk>
184 Date: Thu Jul 14 14:00:09 2011 +0100
185
186 Call: remove stray spaces around attributes' '='
187
188 commit 1be73dc2473830e8d383a9ca2c31635419c70ffb
189 Author: Will Thompson <will.thompson@collabora.co.uk>
190 Date: Thu Jul 14 13:59:56 2011 +0100
191
192 Stream.I.Media: fix typos in preamble
193
194 commit c6f632f7b82f5474fcd75a6e473817d7c3a550d1
195 Author: Will Thompson <will.thompson@collabora.co.uk>
196 Date: Thu Jul 14 13:50:28 2011 +0100
197
198 Contact_SSRCs_Map: refer to SSRCs in value docs
199
200 commit 907db4088fce67e16930b2dd3a2ec1834687f2ff
201 Author: Will Thompson <will.thompson@collabora.co.uk>
202 Date: Thu Jul 14 13:49:35 2011 +0100
203
204 Content.I.Media: add a missing paren
205
206 commit 3886b034fc28b9792aa572bdc3c4c32afe0d096d
207 Author: Will Thompson <will.thompson@collabora.co.uk>
208 Date: Thu Jul 14 13:48:57 2011 +0100
209
210 Endpoint: formatting nitpicks.
211
212 commit 17d74cf238d418488c8abb015ff3e9a8a1e30d83
213 Author: David Laban <david.laban@collabora.co.uk>
214 Date: Wed Jul 13 13:47:42 2011 -0400
215
216 node name=Channel_Type_Call rather than Call1
217
218 Channel_Type_Call1 was making tp-glib expose the version number in function
219 names (not what we want).
220
221 commit fa9e38bff41cb008f8a1ba6c2db065de204c8dcd
222 Author: David Laban <david.laban@collabora.co.uk>
223 Date: Thu Jul 7 15:21:03 2011 -0400
224
225 Rename Call.DRAFT2 to Call1
226
227 Draft interfaces are something that we want to get rid of anyway.
228 See http://telepathy.freedesktop.org/wiki/Roadmap for the
229 discussion of versioned interfaces vs draft ones.
230
231 commit a469f4773eaa625940ec28abdb952c66778c28be
232 Author: David Laban <david.laban@collabora.co.uk>
233 Date: Wed Jul 6 13:00:19 2011 -0400
234
235 Remove all references to Codec_Offer
236
237 commit e203593ec821a01c7504c500e15589284d662429
238 Author: David Laban <david.laban@collabora.co.uk>
239 Date: Tue Jul 5 16:43:16 2011 -0400
240
241 Bump all call interfaces to DRAFT2
242
243 Note that some interfaces never had a DRAFT version merged into master,
244 but I think that having everything as DRAFT2 makes everyone's lives easier.
245
246 commit 36d32e1ac51541458622125ab7ea762d3aa1bc47
247 Merge: 362e755 d76d46c
248 Author: David Laban <david.laban@collabora.co.uk>
249 Date: Tue Jul 5 15:59:48 2011 -0400
250
251 Merge branch 'call-trivia-38852' into call
252
253 Conflicts:
254 spec/Call_Content_Interface_Media.xml
255
256 commit 362e755db444838a3e429fc16688d1c3bca533e4
257 Merge: b1f49aa b9f1b2b
258 Author: David Laban <david.laban@collabora.co.uk>
259 Date: Tue Jul 5 15:56:46 2011 -0400
260
261 Merge branch 'ice-restarts-35012' into call
262
263 commit b1f49aa357b4b64ea0d0f3003bd6d3e047a4f2a3
264 Merge: 51952cb 4180beb
265 Author: David Laban <david.laban@collabora.co.uk>
266 Date: Tue Jul 5 15:53:47 2011 -0400
267
268 Merge branch 'local-descriptions-28718' into call
269
270 commit 51952cbfe182e75e1a24907762ded4e3956c6727
271 Merge: 932a551 019ee87
272 Author: David Laban <david.laban@collabora.co.uk>
273 Date: Tue Jul 5 15:52:14 2011 -0400
274
275 Merge branch 'dtmf-36001' into call
276
277 commit 932a551d1af01810782186e80de5a49a4a2654b5
278 Merge: d0a87d7 f8729c7
279 Author: David Laban <david.laban@collabora.co.uk>
280 Date: Tue Jul 5 15:51:48 2011 -0400
281
282 Merge branch 'per-codec-38126' into call
283
284 commit d76d46c5fd4ca630b13371963f3f86dca6c808d4
285 Author: David Laban <david.laban@collabora.co.uk>
286 Date: Fri Jul 1 20:31:24 2011 -0400
287
288 s/CandidatesPrepared/FinishInitialCandidates/
289
290 It is a method call, and should be named as such, even if
291 it is ignored by most CMs.
292
293 commit b39c2c990b277ea562b85a17ba3243edf6d9de07
294 Author: David Laban <david.laban@collabora.co.uk>
295 Date: Fri Jul 1 20:15:44 2011 -0400
296
297 s/Error/Fail/ to make it sound like a method.
298
299 commit 6653d257af1f41df1a48b61c742e45671e3bfb65
300 Author: David Laban <david.laban@collabora.co.uk>
301 Date: Wed Jun 29 20:09:48 2011 -0400
302
303 Delete duplicate "the"
304
305 commit f92aa64aee9acf22e389019698a38678f0e48fbf
306 Author: David Laban <david.laban@collabora.co.uk>
307 Date: Wed Jun 29 16:11:27 2011 -0400
308
309 Stream.I.Media: fix spelling of candidate
310
311 commit b9f1b2b27782544d518993d5455a38f7a68e3942
312 Author: David Laban <david.laban@collabora.co.uk>
313 Date: Fri Jul 1 19:57:24 2011 -0400
314
315 s/PleaseRestartICE/ICERestartRequested/; add ICERestartPending property
316
317 This makes it sound more like a signal name.
318
319 ICERestartPending provides debugability, and is simpler than clearing the
320 RemoteCredentials property (my previous solution to this problem.
321
322 commit d55f8b67efff559f90f28d0a1653ef362b9fa304
323 Author: David Laban <david.laban@collabora.co.uk>
324 Date: Fri Jul 1 19:54:02 2011 -0400
325
326 Remove confusing opening comment about ICE restarts.
327
328 commit be4cf2adfca0930e2a1db3b34a1b9a5166d891ed
329 Author: David Laban <david.laban@collabora.co.uk>
330 Date: Thu Mar 3 20:00:46 2011 +0000
331
332 PleaseRestartICE => LocalCredentials = ("","")
333
334 (For state-recoverability/debugability)
335
336 commit f8729c7d65a32e07f12263697d767fc06fa4a146
337 Author: David Laban <david.laban@collabora.co.uk>
338 Date: Thu Jun 30 15:33:12 2011 -0400
339
340 Add Boolean to Codecs struct to avoid having to do diffs in the CM
341
342 commit 019ee877ff573351d7ebad6b706f226758a5c6f6
343 Author: David Laban <david.laban@collabora.co.uk>
344 Date: Thu Jun 30 18:00:44 2011 -0400
345
346 Add DTMF state-machine to Content.I.Media
347
348 * Uses a call/response mechanism similar to
349 Call.Stream.I.Media.SendingState, and the Sending_State enum from
350 Call.Stream (since Paused is meaningless for the DTMF use-case).
351 * CurrentDTMF{Event,State} for state recovery.
352
353 commit 26fedec13d4ddaceea05afbb766c83f9c8df5a46
354 Author: David Laban <david.laban@collabora.co.uk>
355 Date: Thu Jun 30 14:57:00 2011 -0400
356
357 Delete unused Codec_Offer.xml
358
359 commit d0a87d7b3ccd62ff3268349b3968ebeb3bf7f60f
360 Merge: 1a28459 adc432d
361 Author: David Laban <david.laban@collabora.co.uk>
362 Date: Thu Jun 30 14:50:04 2011 -0400
363
364 Merge branch 'stream-state-machine-38790' into call
365
366 commit adc432d3a903038e7e4b0be5bf12f140ec631e36
367 Author: David Laban <david.laban@collabora.co.uk>
368 Date: Thu Jun 30 14:42:01 2011 -0400
369
370 Clarify Complete*StateChange state transitions
371
372 The Complete*StateChange doc should make it clear that it can only go from
373 a Pending state to the matching non-pending state.
374
375 commit 9186b7efb1d1e9c4b9b55f0f2313cd9b5f93e2b6
376 Author: David Laban <david.laban@collabora.co.uk>
377 Date: Wed Jun 29 22:20:37 2011 -0400
378
379 Stream.I.Media: Remove Reason from *StateChanged signals
380
381 We now have a Paused state (distinct from Stopped) so we don't need to
382 know whether the flow change was because of mute/hold or direction
383 change.
384
385 commit c31bbdfe7d6bc888294d9c6d08a7ff69e65e945c
386 Author: David Laban <david.laban@collabora.co.uk>
387 Date: Wed Jun 29 22:19:18 2011 -0400
388
389 Simplify Stream flow state machine
390
391 * Rename Flowing/Not_Flowing to Started/Stopped (easier to say, and relates
392 to Pending_Start/Stop more intuitively)
393 * Add Pending_Pause and Paused states.
394 * Use Complete*StateChange for success (rather than big list of methods)
395 * Use Report*Failure for failure, which takes a Call_State_Change_Reason
396 so that it can be passed up the Call hierarchy unmodified by the CM.
397
398 commit 1a28459feae3ac01eae8c1a402d9a54f66746936
399 Merge: 2118199 fdf6731
400 Author: David Laban <david.laban@collabora.co.uk>
401 Date: Wed Jun 29 20:57:48 2011 -0400
402
403 Merge branch 'rtcp-xr-28686' into call
404
405 commit fdf6731812823158d43d5068af430d4ac0f4b99f
406 Author: David Laban <david.laban@collabora.co.uk>
407 Date: Wed Jun 29 20:20:07 2011 -0400
408
409 Document that unknown rtcp-xr formats should be ignored.
410
411 commit 211819946a8736ba7262ad0b58d7a0ee393206d1
412 Merge: 896d38b edb9ae9
413 Author: David Laban <david.laban@collabora.co.uk>
414 Date: Wed Jun 29 17:50:37 2011 -0400
415
416 Merge remote-tracking branch 'ocrete/rtcp-fb-mediadesc-ftfy' into call
417
418 Note that StreamedMedia gained RTCP feedback capabilities
419 while we were bikeshedding about RTCPMinimumInterval,
420 so I have deferred to these types and copied the docstring of
421 RTCPMinimumInterval across.
422
423 RTCP_Feedback_Message_Map is now a{u(ua(sss))} rather than
424 the invalid type a{uua(sss)} (we should probably make the
425 spec parser check for invalid types really)
426
427 Conflicts:
428 spec/all.xml
429
430 commit 4180beb4d19235368dbd9454c7d5ea326419c888
431 Author: David Laban <david.laban@collabora.co.uk>
432 Date: Mon Jun 13 14:52:24 2011 -0400
433
434 LocalMediaDescription*s*
435
436 This needs to be plural to make it easier to support the focus=us case
437 (fd.o #28718).
438
439 UpdateLocalMediaDescription and LocalMediaDescriptionChanged are still
440 singular but now have a Remote_Contact arg.
441
442 commit 896d38bdbc9a3cedbc7972889ab946b855ce8aa5
443 Merge: f089088 b0dc040
444 Author: David Laban <david.laban@collabora.co.uk>
445 Date: Wed Jun 29 16:47:58 2011 -0400
446
447 Merge branch 'ssrcs-29597' into call
448
449 commit b0dc04064df4634f54cd07bc4ec53af9b52a4f00
450 Author: David Laban <david.laban@collabora.co.uk>
451 Date: Fri Jun 10 19:46:16 2011 -0400
452
453 SSRCs probably need to include handles as well.
454
455 commit f08908879493a535613a3f68787d8b598b29d09d
456 Merge: fd8dccc 29d2fe2
457 Author: David Laban <david.laban@collabora.co.uk>
458 Date: Wed Jun 29 16:35:49 2011 -0400
459
460 Merge branch 'states-35128' into call
461
462 Conflicts:
463 spec/Channel_Type_Call.xml
464
465 commit 29d2fe20615b29b0b34058b45e90f10281c0e5b7
466 Author: David Laban <david.laban@collabora.co.uk>
467 Date: Mon Jun 13 20:20:44 2011 -0400
468
469 Add error Media.UnsupportedType.
470
471 This branch should now compile cleanly if merged into alsuren/call.
472
473 commit 6611d8e15175cfc8342b5d700cb436efbb286759
474 Author: Olivier Crête <olivier.crete@collabora.com>
475 Date: Fri Jun 10 21:10:51 2011 -0400
476
477 Add tp:added to media errors
478
479 commit 0734ca58a794eec54ba43a72429314a7fb24545a
480 Author: Olivier Crête <olivier.crete@collabora.com>
481 Date: Fri Jun 10 21:08:23 2011 -0400
482
483 Simplify the Streaming/Media error codes
484
485 commit 6a7f1729ad0b09d7af38669e13cdc8f06ea2e6de
486 Author: Olivier Crête <olivier.crete@collabora.com>
487 Date: Fri Jun 10 21:07:40 2011 -0400
488
489 InsufficientFunds -> InsufficientBalance to match newer spec
490
491 commit 191f4a9c7ff432e53c8a5594f19f10950eb0d9c0
492 Author: Olivier Crête <olivier.crete@collabora.com>
493 Date: Fri Jun 10 20:28:28 2011 -0400
494
495 Alerting -> Ringing
496
497 commit b27cac457214815a00621ef09030be805491f0f5
498 Author: Olivier Crête <olivier.crete@collabora.com>
499 Date: Fri Jun 10 20:23:54 2011 -0400
500
501 Use tp:error-ref instead of tp:error where appropriate
502
503 commit 89818f54b1f9da9b6873e7920a848461e150891d
504 Author: David Laban <david.laban@collabora.co.uk>
505 Date: Thu Apr 21 16:48:47 2011 +0100
506
507 Delete confusing table of states/reasons
508
509 This table has gotten out-of-sync repeatedly in the past. Now that we have
510 enough entries in the Call_State_Reason enum, we can cross-reference from
511 there rather than repeating ourselves.
512
513 * Note that I have made PickedUpElsewhere correspond to No_Answer rather
514 than User_Requested, because that is more specific IMO.
515
516 commit 1a82ff017032d740d3ae875e6c9e2be71338a7d9
517 Author: David Laban <david.laban@collabora.co.uk>
518 Date: Thu Apr 21 16:38:03 2011 +0100
519
520 Fix up CallFlags again
521
522 * Document that Locally_Held and Locally_Muted are redundant but helpful.
523 * Add Locally_Ringing and Locally_Queued flags again (and add SetQueued
524 method, so that it's possible to get Locally_Queued set)
525 * Add Clearing flag again.
11526
12527 commit e9fa42cd452d504013cb9164e4624b33477ed271
13528 Author: João Paulo Rechi Vita <jprvita@gmail.com>
41556 WebKit was ignoring the CSS to adjust the position of anchors for the fixed
42557 title bar. The fix is to make the anchor a block element.
43558
559 commit fd8dccc3085141f844f0f06f0a19efa51010f06c
560 Merge: 9d1040e 187fc72
561 Author: David Laban <david.laban@collabora.co.uk>
562 Date: Mon Jun 13 19:18:58 2011 -0400
563
564 Merge remote-tracking branch 'origin/master' into call
565
566 commit 9d1040e787c8f0aa01919055456292aa73b3691b
567 Merge: 133ad81 3de1829
568 Author: David Laban <david.laban@collabora.co.uk>
569 Date: Mon Jun 13 18:47:28 2011 -0400
570
571 Merge branch 'relayinfo-26643' into call
572
573 commit 8c021b1853a95e58750813cf57c5b84a0f81a937
574 Author: David Laban <david.laban@collabora.co.uk>
575 Date: Thu Apr 21 16:02:38 2011 +0100
576
577 Settle on (hopefully final) set of call states.
578
579 See fd.o#35128
580
581 commit 2342f021f3cbc7b7d9a9b972272e750b61cea92e
582 Author: David Laban <david.laban@collabora.co.uk>
583 Date: Thu Apr 21 12:17:59 2011 +0100
584
585 Add more Call_State_Reasons
586
587 Also make sure that there is a corresponding dbus error for the failure
588 cases.
589
44590 commit b68efdb1af6bccd466fed919c64190bad3677f47
45591 Author: Danielle Madeley <danielle.madeley@collabora.co.uk>
46592 Date: Mon Jun 13 15:32:13 2011 +0100
48594 Add ChannelRequest hint ofdT.ChannelRequest.DelegateToPreferredHandler
49595
50596 Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=38240
597
598 commit edb9ae9bbc0bacfbc0b66570207ef26bc953eb07
599 Author: Olivier Crête <olivier.crete@collabora.com>
600 Date: Fri Jun 10 18:53:34 2011 -0400
601
602 Call.C.MD.I.RTCP_Feedback: Force the CM to know about the profiles
603
604 The CM has to know about profiles, so forget having a default value.
51605
52606 commit 187fc7231eaa871db81466f70a99edfbdb95eed8
53607 Author: Xavier Claessens <xclaesse@gmail.com>
377931
378932 Properties on Protocol.Interface.Avatars should be immutables
379933
934 commit 133ad818a520a140202ce57d8ffbbba9548e085c
935 Author: David Laban <david.laban@collabora.co.uk>
936 Date: Fri Apr 8 17:38:47 2011 +0100
937
938 EndpointState: s/a(uu)/a{uu}/
939
940 This is really a mapping type. Let's make it one.
941
942 commit 581755afc677bdfb42ef1aba903b8b83034fd627
943 Merge: 1ce51fb eae8065
944 Author: David Laban <david.laban@collabora.co.uk>
945 Date: Thu Apr 7 12:33:13 2011 +0100
946
947 Merge branch 'mute' into call
948
949 commit ed730d32e890eb81bf66f76d04cadbca6b3ba1dc
950 Author: David Laban <david.laban@collabora.co.uk>
951 Date: Wed Apr 6 17:50:49 2011 +0100
952
953 Remove Call_State_Pending_Receiver
954
955 (It is covered by its "substates". I also realised that the concept of
956 substates is bullshit and confusing in an enum)
957
958 I have specified that Ringing should be set immediately on protocols that
959 don't signal Ringing as a state. This may be slightly controversial, since
960 it's a loss of information, but I think this reflects what a UI should do
961 in this case.
962
963 * Grep for Pending_Receiver and fix all instances
964 * Update the enum's numbers, and remove all references to "sub-state"
965 * Remove "makes sense on calls in state..." from Call_Flags, because
966 they all kinda make sense in all states apart from Ended.
967
968 commit 7b6d9761efac2aaf7c0abe37b298811762d9b2ff
969 Author: David Laban <david.laban@collabora.co.uk>
970 Date: Wed Apr 6 15:52:03 2011 +0100
971
972 Clarify the purpose of Call_State_Ringing
973
974 * Fix typo in SetRinging docstring.
975 * Separate the incoming and outgoing use-cases for clarity.
976 * State what to do in multi-party calls.
977
978 commit eae8065fb24ea294876a18cccdbff8ebdfce0835
979 Author: David Laban <david.laban@collabora.co.uk>
980 Date: Wed Apr 6 14:56:33 2011 +0100
981
982 Re-order Call_Member_Flags to group Muted with Held
983
984 commit 04008916ae5fc3db0bfdb872c300f12161219dac
985 Author: David Laban <david.laban@collabora.co.uk>
986 Date: Wed Apr 6 14:17:01 2011 +0100
987
988 Call_Member_Flags_Muted := 8 to avoid collision
989
990 Note that we may want to re-order and make Conference_Host = 8 if we care about grouping
991
992 commit 96cc83a860e2a7d422e88807fad3d116e1db4bd8
993 Author: David Laban <david.laban@collabora.co.uk>
994 Date: Tue Mar 29 13:58:44 2011 +0100
995
996 Update Call docstrings to represent new States
997
998 commit c35e0f9eee3d13d9bac34df55c6fe2563d199a08
999 Author: David Laban <david.laban@collabora.co.uk>
1000 Date: Tue Mar 29 11:54:26 2011 +0100
1001
1002 Update list of valid state transitions for Call
1003
1004 commit 8521e1fd7368f1658b3572fc0c5de25099f010e4
1005 Author: David Laban <david.laban@collabora.co.uk>
1006 Date: Tue Mar 22 20:21:47 2011 +0000
1007
1008 Move mutually exlusive Call_Flags to Call_State
1009
1010 From fd.o#35128:
1011 add Setup_In_Progress, Queued, Ringing, Active and Clearing to CallState
1012 (in addition to Unknown, Pending_Initiator, Pending_Receiver, Accepted, and
1013 Ended). CallFlags will only contain Forwarded, Locally_Muted, and Locally_Held.
1014
1015 commit f8ff599577cd325cde1339df4f9d99d2a56174e5
1016 Author: David Laban <david.laban@collabora.co.uk>
1017 Date: Wed Mar 30 12:05:25 2011 +0100
1018
1019 Muted => sending silence or no media at all
1020
1021 Also note that dignity is a valid use-case for mute.
1022
1023 commit 40ba870b0653339844c18f330ff00869d92ffcbd
1024 Author: David Laban <david.laban@collabora.co.uk>
1025 Date: Tue Mar 29 17:29:42 2011 +0100
1026
1027 Add a Muted CallMemberFlag.
1028
1029 From b.fd.o#28707:
1030
1031 "I realise this is just copy pasted from another file, but the MutedState
1032 variable on the content should refer to the local mute state. So it only
1033 changes if you call SetMuted().. If its a mute from a remote content, it
1034 should be a separate notification/variable."
1035
1036 commit 242a534394876d956674f20956fe961d0a936447
1037 Author: David Laban <david.laban@collabora.co.uk>
1038 Date: Tue Mar 29 17:23:49 2011 +0100
1039
1040 s/SetMuted/RequestMuted/ to be more like Hold.
1041
1042 commit 6ec9fd106241970c2d037140c5c37a54ce42b605
1043 Author: David Laban <david.laban@collabora.co.uk>
1044 Date: Tue Mar 29 17:17:49 2011 +0100
1045
1046 Make Hold Interface more recursive.
1047
1048 Also, fix copy-paste typo from 2008.
1049
1050 commit b28cea5d6c725de713dd9c7d00bdf50ae92942f7
1051 Author: David Laban <david.laban@collabora.co.uk>
1052 Date: Tue Mar 29 17:15:39 2011 +0100
1053
1054 Make the Mute interface look a bit more like Hold.
1055
1056 Since the CM is now responsible for telling the Streaming Implementation
1057 what to do regarding Mute, it actually looks quite a lot like Hold, so...
1058
1059 enum: Local_Mute_State similar to Local_Hold_State
1060
1061 commit 93282d97acaeb05f23b9b982eb4d5bad45115c74
1062 Author: David Laban <david.laban@collabora.co.uk>
1063 Date: Tue Mar 29 16:08:49 2011 +0100
1064
1065 Rename Call.Content.I.Mute to Call.I.Mute and require it in various places
1066
1067 Mute is required on the Contents, and also allowed on Call Channels and
1068 Streams.
1069
1070 commit 968cf1b329f11692dc4c599bc02440ec6c167886
1071 Author: David Laban <david.laban@collabora.co.uk>
1072 Date: Tue Mar 29 16:04:59 2011 +0100
1073
1074 Move Call_Content_Interface_Mute.xml to Call_Interface_Mute.xml
1075
1076 commit 4b5c5007fd442376454eda4cdfa69b094d349f91
1077 Author: David Laban <david.laban@collabora.co.uk>
1078 Date: Tue Mar 29 14:42:39 2011 +0100
1079
1080 Revert "Merge Content.Iface.Mute into Content."
1081
1082 This reverts commit 71d7927cc2085940de5f47a87e62e541f90fc544.
1083
1084 commit 3de18298c0e863c9d37f303b8649d5786c9c84ef
1085 Author: David Laban <david.laban@collabora.co.uk>
1086 Date: Wed Apr 6 13:55:35 2011 +0100
1087
1088 RelayInfo: clarify wording in line with review comments
1089
1090 * All map keys are optional, but these are well-known.
1091
1092 * Use priority or type to determine preference.
1093
1094 commit 1ce51fb799f2e2fef20e443d1296e3806a2a90f6
1095 Merge: 85941a6 8528486
1096 Author: David Laban <david.laban@collabora.co.uk>
1097 Date: Wed Apr 6 12:42:57 2011 +0100
1098
1099 Merge branch 'endpoint-state' into call
1100
3801101 commit 14345ebf68847d66b09c693472650c7ff3f5872c
3811102 Author: Danielle Madeley <danielle.madeley@collabora.co.uk>
3821103 Date: Wed Apr 6 12:25:15 2011 +1000
3831104
3841105 Add method GetSMSLength() to allow SMS message chunking to be shown to the user
3851106
1107 commit fb58cfe43dc22c8d8084588f803ca168b61b5c8f
1108 Author: David Laban <david.laban@collabora.co.uk>
1109 Date: Mon Apr 4 18:15:55 2011 +0100
1110
1111 RelayInfo unique-id and priority
1112
1113 as discussed in fd.o#26643
1114
1115 commit 85941a671e98a2a1787ba4ca975f99c65206177d
1116 Merge: ef0c43e b2710e0
1117 Author: David Laban <david.laban@collabora.co.uk>
1118 Date: Mon Apr 4 11:28:55 2011 +0100
1119
1120 Merge branch 'remove-reason' into call
1121
1122 commit b2710e056a823a6d11d6a2ce758b6b639c04f083
1123 Author: David Laban <david.laban@collabora.co.uk>
1124 Date: Mon Apr 4 11:20:55 2011 +0100
1125
1126 s/_Fault/_Error/ (to match the rest of the spec)
1127
1128 As suggested in b.fd.o#35573 comment 3
1129
3861130 commit 5feaec96b1cd2a13d09b8250cb29c9ac70d1eb82
3871131 Author: Danielle Madeley <danielle.madeley@collabora.co.uk>
3881132 Date: Mon Apr 4 15:30:20 2011 +1000
3941138 Date: Mon Apr 4 15:08:18 2011 +1000
3951139
3961140 Clarify ofdT.Error.InsufficientBalance can be used in message delivery reports
1141
1142 commit 8528486a9c674f2317f4b93ca2059c420678fb6b
1143 Author: David Laban <david.laban@collabora.co.uk>
1144 Date: Fri Apr 1 19:58:16 2011 +0100
1145
1146 Update docs to reflect Accept/Reject mechanism
1147
1148 commit fb16f3ab568a397c9889a87a17d648b3cf568226
1149 Author: David Laban <david.laban@collabora.co.uk>
1150 Date: Fri Apr 1 20:10:36 2011 +0100
1151
1152 Endpoint.Accept/RejectSelectedCandidatePair
1153
1154 This avoids a race which can occur if the Controlling (remote) side
1155 proposes a new selected candidate pair before connectivity checks fail on
1156 the currently selected candidate pair.
1157
1158 SetEndpointState is still used for all other state changes.
1159
1160 commit 525a162ddfcb1b831c33ff665cfec9fd958b4272
1161 Author: David Laban <david.laban@collabora.co.uk>
1162 Date: Fri Apr 1 19:40:23 2011 +0100
1163
1164 Note that Peer reflexive candidates may appear on the Endpoint
1165
1166 commit 1447dc64508aba8e316b43ee8396bb6bcbb6ef17
1167 Author: David Laban <david.laban@collabora.co.uk>
1168 Date: Fri Mar 11 15:16:05 2011 +0000
1169
1170 Expand on how the controlled side should respond to CandidatePairSelected
1171
1172 (by calling SetEndpointState)
1173
1174 commit 81c0bb134f20701a167281eb1275801920e4b2ae
1175 Author: David Laban <david.laban@collabora.co.uk>
1176 Date: Fri Mar 11 14:46:51 2011 +0000
1177
1178 EndpointState should be more detailed, and per component.
1179
1180 The property EndpointState is now an array of (Component, State)
1181
1182 Discussion is on fd.o #34189.
1183
1184 commit 5a270d143d53ab9a58c7a9d86a51fd20537ea1eb
1185 Author: David Laban <david.laban@collabora.co.uk>
1186 Date: Thu Mar 31 19:39:05 2011 +0100
1187
1188 CallMembersChanged(,,Reason) docstring copypasta fail
1189
1190 commit 1f299c1dc7091ed409c409f9e61ddfda297f224d
1191 Author: David Laban <david.laban@collabora.co.uk>
1192 Date: Thu Mar 31 18:01:38 2011 +0100
1193
1194 Add Error method to Stream.I.Media
1195
1196 commit 2f501f1f56b15c651e94674529c7f42fcbb8972c
1197 Author: David Laban <david.laban@collabora.co.uk>
1198 Date: Thu Mar 31 17:54:28 2011 +0100
1199
1200 Add Reason arg to a few signals
1201
1202 * Stream.RemoteMembersChanged
1203 * Stream.LocalSendingStateChanged
1204 * Call.CallMembersChanged
1205
1206 commit c6112bd920661d91f3cfb553b86c4aeb7b27f111
1207 Author: David Laban <david.laban@collabora.co.uk>
1208 Date: Thu Mar 31 17:10:57 2011 +0100
1209
1210 Fix whitespace in Content and type reference in Call
1211
1212 commit a72b3dd8e6d44d762229681e7ba6aa8d266b8027
1213 Author: David Laban <david.laban@collabora.co.uk>
1214 Date: Wed Mar 30 16:28:02 2011 +0100
1215
1216 Clean up Content removal error handling
1217
1218 * Port all Content_Removal_Reason uses to Call_State_Reason struct
1219 * Move reason etc from Content.Remove() to new Content.I.Media.Error()
1220 * In response to fd.o#35573 and comment 3 of #28723.
1221 * ContentRemoved(): Add Reason argument.
1222 * As discussed in fd.o #28723
1223
1224 commit 007fabc7c08b4d01f25bcca2fe6d2c016a21d9cd
1225 Author: David Laban <david.laban@collabora.co.uk>
1226 Date: Thu Mar 31 17:00:39 2011 +0100
1227
1228 Make Call_State_Reason struct more general
1229
1230 * Add reason values from Content_Removal_Reason to Call_State_Change_Reason
1231 enum
1232 * Add a Message member to Call_State_Reason, for optional debugging.
3971233
3981234 commit 9d6988fcd59c49f8925b671bf1d66f066c683be9
3991235 Author: Will Thompson <will.thompson@collabora.co.uk>
4821318
4831319 Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=35755
4841320
1321 commit 2ed36fe9997d243ed66740bb9b3abede9fae766f
1322 Author: David Laban <david.laban@collabora.co.uk>
1323 Date: Thu Mar 24 16:31:02 2011 +0000
1324
1325 RTCPMinimumInterval: Third time lucky?
1326
1327 commit ef0c43e8938be658ea8aed7c1baaffd5787c81c8
1328 Merge: 48aa9b0 935b328
1329 Author: David Laban <david.laban@collabora.co.uk>
1330 Date: Tue Mar 22 20:53:08 2011 +0000
1331
1332 Merge branch 'controlling' into call
1333
1334 Reviewed-by: Olivier Crête <olivier.crete@collabora.co.uk>
1335
4851336 commit bedca93acdc4d80a770f2519cebe2db763095ddd
4861337 Author: Will Thompson <will.thompson@collabora.co.uk>
4871338 Date: Tue Mar 22 14:32:35 2011 +0000
5351386
5361387 Reviewed-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
5371388
1389 commit ded2c6df9d4d3e1e270b7ed44c8db20921cacc6b
1390 Author: David Laban <david.laban@collabora.co.uk>
1391 Date: Fri Mar 18 18:06:15 2011 +0000
1392
1393 C.C.MD.I.RTCP-XR: Document where RTCP_XR_Statistics_Flags comes from.
1394
1395 commit 25ba803e9587168ada4a4d7f01147ec632d8e9b2
1396 Author: David Laban <david.laban@collabora.co.uk>
1397 Date: Fri Mar 18 18:05:32 2011 +0000
1398
1399 C.C.MD.I.RTCP-XR: reshape how I like it.
1400
1401 * Convert XRParameters members into their own properties.
1402 * Use 0 for disable, MAXUINT32 as no limit.
1403 This allows us to get rid of flags.
1404 * EnableMetrics needs its own bool property, as there are no longer flags
1405 for which types of report block to send.
1406
1407 commit 2d8a23a8735d5ed6e4b0589a600838ba4cec2b34
1408 Author: David Laban <david.laban@collabora.co.uk>
1409 Date: Fri Mar 18 15:54:42 2011 +0000
1410
1411 MD.I.RTCP_XR: convert to MediaDescription style and make it build cleanly.
1412
5381413 commit 8024150ae2f9d08343700d9a47b83fd3fe89236c
5391414 Author: Will Thompson <will.thompson@collabora.co.uk>
5401415 Date: Fri Mar 18 15:04:01 2011 +0000
5991474
6001475 https://bugs.freedesktop.org/show_bug.cgi?id=35408
6011476
1477 commit 294a855b9390be5bf1956a1103055d4a0e13196f
1478 Author: David Laban <david.laban@collabora.co.uk>
1479 Date: Thu Mar 17 16:28:46 2011 +0000
1480
1481 Import CodecOffer.I.RTCPXR from jonny as MD.I.RTCPXR
1482
1483 Not actually ported to MD yet or included in all.xml
1484
1485 commit 7e7bad916023c738633f0342c5aa4f2611e6886e
1486 Author: David Laban <david.laban@collabora.co.uk>
1487 Date: Wed Mar 16 16:58:17 2011 +0000
1488
1489 Add Channel.Hold interface to Content
1490
1491 Also re-wrap some of the interface docstring.
1492
1493 commit e9246cd93e5d713b1b94bb574731eeac75ef0625
1494 Author: David Laban <david.laban@collabora.co.uk>
1495 Date: Wed Mar 16 16:05:24 2011 +0000
1496
1497 make it build
1498
1499 commit 48aa9b07e5de7d8da34010f65fd848b17e75bf21
1500 Author: David Laban <david.laban@collabora.co.uk>
1501 Date: Wed Mar 16 14:29:38 2011 +0000
1502
1503 Make SSRCs into a list for extensibility
1504
1505 ocrete's request. There are no known use-cases for this.
1506
1507 commit 961104212ebf68cb508a58556f1365d37c45394e
1508 Author: David Laban <david.laban@collabora.co.uk>
1509 Date: Tue Mar 15 21:00:19 2011 +0000
1510
1511 Cross-reference RemoteMediaDescriptions to RemoteMembers and RemoteContact
1512
1513 This should make contacts less confusing, and allow me to close
1514 b.fd.o#31276 (*fingers crossed*)
1515
1516 commit 8325e3a34cb3897603c5e63e7476dced3f4ec52e
1517 Author: David Laban <david.laban@collabora.co.uk>
1518 Date: Tue Mar 15 20:58:27 2011 +0000
1519
1520 Rewrite RemoteMembers' docstring
1521
1522 * Specify that it is a list of expected recipients, and that all members
1523 are also members of the call.
1524 * Mention mute.
1525 * Compare and contrast with LocalSendingState
1526 * Mention that all senders will also be represented in
1527 RemoteMediaDescriptions in the streamed media case.
1528
1529 commit 81bde80af472589d9bae050862831d004147956b
1530 Author: David Laban <david.laban@collabora.co.uk>
1531 Date: Tue Mar 15 20:13:33 2011 +0000
1532
1533 Clarify LocalSendingState
1534
1535 Say that it is an error to redundantly call SetSending(True) before
1536 you've called Accept.
1537
1538 Clean up RemoteMembers' to remove reference to what is now
1539 LocalSendingState=Pending_Send.
1540
1541 Clarify the different methods to coerce a stream from Pending_Send to
1542 Sending.
1543
1544 commit 31db02eafe4134f5ba1677750388ce46a6101e02
1545 Author: David Laban <david.laban@collabora.co.uk>
1546 Date: Tue Mar 15 19:26:03 2011 +0000
1547
1548 Clarify how to map from MediaDescription to Stream
1549
1550 In response to b.fd.o#31276.
1551
1552 commit 926e95ded08cc00243c32c8157d024676b4e7d1e
1553 Author: David Laban <david.laban@collabora.co.uk>
1554 Date: Tue Mar 15 19:24:50 2011 +0000
1555
1556 Add an SSRC property to the MediaDescription
1557
1558 This should address b.fd.o#29597.
1559
1560 commit ee5004a37d9f7a2d0c8d033f7cdc18d0c65e3eb4
1561 Author: David Laban <david.laban@collabora.co.uk>
1562 Date: Tue Mar 15 18:14:22 2011 +0000
1563
1564 Direction changed vs Mute/Hold
1565
6021566 commit f30d22efb6353b661833cf6fb1c259564bdca03a
6031567 Author: Will Thompson <will.thompson@collabora.co.uk>
6041568 Date: Tue Mar 15 09:33:35 2011 +0000
6371601 Date: Mon Mar 14 10:54:24 2011 +0000
6381602
6391603 Undraft ContactBlocking.
1604
1605 commit 71d7927cc2085940de5f47a87e62e541f90fc544
1606 Author: David Laban <david.laban@collabora.co.uk>
1607 Date: Fri Mar 11 16:22:52 2011 +0000
1608
1609 Merge Content.Iface.Mute into Content.
1610
1611 We decided mute wasn't optional.
1612
1613 commit 0af0d08bbecaa1d9f53450a4c23ec3042d27ca98
1614 Author: David Laban <david.laban@collabora.co.uk>
1615 Date: Fri Mar 11 16:21:18 2011 +0000
1616
1617 oops: Muted copy-paste error
1618
1619 commit ebc90630332904e16acd9e39a17c734d17f22d4a
1620 Author: David Laban <david.laban@collabora.co.uk>
1621 Date: Fri Mar 11 15:52:39 2011 +0000
1622
1623 s/Pending_Send/Pending_Start/
1624
1625 This is what I meant to type, and what I typed everywhere else in the file.
1626 (This enumvalue is used in both SendingState and ReceivingState)
1627
1628 commit da47cad093f1845c1cc4ee3111b2265eaa7ab132
1629 Author: David Laban <david.laban@collabora.co.uk>
1630 Date: Fri Mar 11 15:50:04 2011 +0000
1631
1632 Mute != SendingStopped
1633
1634 with mute you could continue sending, but send
1635 silence. That's actually what your N900 does.
1636
1637 commit f78369bf4db96ac66be3ab111de57e0a4cfa25d5
1638 Author: David Laban <david.laban@collabora.co.uk>
1639 Date: Tue Mar 8 17:38:51 2011 +0000
1640
1641 Stream.Interface.Media.{Sending,Receiving}State
1642
1643 As discussed in fd.o#28707.
1644
1645 commit c757b92966edb9b6d4499cadb8788e72cf8d30db
1646 Merge: 6f86fbe 0dd2a48
1647 Author: David Laban <david.laban@collabora.co.uk>
1648 Date: Fri Mar 11 13:16:24 2011 +0000
1649
1650 Merge remote branch 'alsuren/stream-etc' into call
1651
1652 Reviewed-by: Olivier Crête <olivier.crete@collabora.co.uk>
6401653
6411654 commit 4c55d49925a90fd026370057df18d1b8d860dbec
6421655 Merge: 3a77d9c 131d606
7931806
7941807 Add Connection.Interface.Blocking draft
7951808
1809 commit 935b32821a9efae9f7a6a1de7769ac2a3a57f767
1810 Author: David Laban <david.laban@collabora.co.uk>
1811 Date: Tue Mar 8 11:50:54 2011 +0000
1812
1813 Endpoint.Controlling: Add Rationale
1814
1815 Stolen from Danni and Youness' Contributions to fd.o #31280
1816
1817 commit 798f9cdc6199082ba1ee26f0d7e53b4cc7b16dde
1818 Author: David Laban <david.laban@collabora.co.uk>
1819 Date: Mon Mar 7 19:30:04 2011 +0000
1820
1821 Endpoint: Controlling and IsICELite
1822
1823 commit 6f86fbe9ed7dc25ab1994067eeae93c2abacf740
1824 Merge: c60b6fe 0fe25db
1825 Author: David Laban <david.laban@collabora.co.uk>
1826 Date: Mon Mar 7 18:44:20 2011 +0000
1827
1828 Merge remote branch 'alsuren/rtp-hdrext-mediadesc-ftfy' into call
1829
1830 Fixes fd.o #29656
1831
1832 Reviewed-by: Olivier Crête <olivier.crete@collabora.co.uk>
1833
1834 commit c60b6fe8d42507dd22bf0374c4fbdd1aaa1cdffe
1835 Merge: 6a4b046 66291a9
1836 Author: David Laban <david.laban@collabora.co.uk>
1837 Date: Mon Mar 7 18:36:06 2011 +0000
1838
1839 Merge remote branch 'alsuren/SelectedCandidatePairs' into call
1840
1841 Fixes fd.o #34149
1842
1843 Reviewed-by: Olivier Crête <olivier.crete@collabora.co.uk>
1844
1845 commit 6a4b046febd4ec2afd309bcc7b5263db3e5c4276
1846 Merge: 59c5560 1507b2d
1847 Author: David Laban <david.laban@collabora.co.uk>
1848 Date: Thu Mar 3 13:22:57 2011 +0000
1849
1850 Merge branch 'mediadesc-FurtherNegotiationRequired'
1851
1852 Conflicts:
1853 spec/all.xml
1854
1855 Also, update Content.Interface.VideoControl to require
1856 Content.Interface.Media.DRAFT
1857
1858 Fixes fd.o #31274
1859
1860 Reviewed-by: Olivier Crête <olivier.crete@collabora.co.uk>
1861
1862 commit 17b5f2148644caf5b923ebfb1b3531e776f95761
1863 Author: David Laban <david.laban@collabora.co.uk>
1864 Date: Mon Mar 7 18:14:13 2011 +0000
1865
1866 Be less wrong about RTCPMinimumInterval=0
1867
1868 commit 0dd2a48dc31947a6927d452cd3f5bff70395721f
1869 Author: David Laban <david.laban@collabora.co.uk>
1870 Date: Fri Mar 4 14:19:43 2011 +0000
1871
1872 Document base-{ip,port}
1873
1874 commit b7db99ee7528bc6ea35f0e4be1f735b8c3ffef0c
1875 Author: David Laban <david.laban@collabora.co.uk>
1876 Date: Thu Mar 3 20:03:19 2011 +0000
1877
1878 Call.Stream.I.Media: Use gobject-property-case throughout.
1879
1880 <smcv> alsuren: our loose convention is that flat-namespace keys are in
1881 gobject-property-case but namespaced keys are CamelCase.DBusProperties
1882
7961883 commit 2b76dfc602af9367feced6793eb6db715e4a936d
7971884 Author: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
7981885 Date: Fri Mar 4 13:39:06 2011 +0100
8401927 Date: Thu Feb 10 12:56:18 2011 +0000
8411928
8421929 StreamHandler: Move docstring to the top
1930
1931 commit 0fe25dbc2175557a4ade4db78154a186ffd4452f
1932 Author: David Laban <david.laban@collabora.co.uk>
1933 Date: Thu Mar 3 20:17:53 2011 +0000
1934
1935 oops. Should probably type make before asking for review
1936
1937 commit 8a7b908bc170db5c1fb0e6bb2b74cfaf032b11f2
1938 Author: David Laban <david.laban@collabora.co.uk>
1939 Date: Thu Mar 3 18:07:45 2011 +0000
1940
1941 Add Multicast Candidate Type, and a TTL field for it
1942
1943 commit 9238afa876c9ea04391a851f5f2accc2e8631f21
1944 Author: David Laban <david.laban@collabora.co.uk>
1945 Date: Thu Mar 3 18:06:29 2011 +0000
1946
1947 Make CandidateInfo docs use the same layout as RelayInfo
1948
1949 Also fix capitalisation.
1950
1951 commit e492f9b6c15bb3859e91557cb757200805da14fb
1952 Author: David Laban <david.laban@collabora.co.uk>
1953 Date: Thu Mar 3 17:00:42 2011 +0000
1954
1955 Fix whitespace
1956
1957 commit 0c5fde53e2bfac3e0621c3d7cddf01ab02db2e55
1958 Author: David Laban <david.laban@collabora.co.uk>
1959 Date: Thu Mar 3 17:00:24 2011 +0000
1960
1961 Candidate_Info clarifications.
1962
1963 * Add Call_Stream_Candidate_Type enum
1964 * Fix types of well-known keys
1965 * Document that Priority is used rather than RawUDPFallback, and discuss
1966 IPv6 (fixes fd.o#34038)
8431967
8441968 commit 177372c96aec2aa3fe9c7ae6c0acbcda220bbb96
8451969 Author: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
8651989 Date: Thu Mar 3 12:52:13 2011 +1100
8661990
8671991 Mark Chan.I.CredentialsStorage as causes-havoc
1992
1993 commit 1507b2d93cb6ad89d0f59f3f6d8fc5e0184dde6f
1994 Author: David Laban <david.laban@collabora.co.uk>
1995 Date: Thu Mar 3 00:29:37 2011 +0000
1996
1997 Address review comments.
1998
1999 commit 340aacfd3b65f66d8895e06682f74ed9779cf88d
2000 Author: David Laban <david.laban@collabora.co.uk>
2001 Date: Wed Mar 2 18:51:23 2011 +0000
2002
2003 MD.I.RTPHeaderExtensions: s/Remote//
2004
2005 Also:
2006 * add some fullstops etc.
2007 * s/\t/ /
2008 * docstring update.
2009
2010 commit b6caf5f51bc407f64204e81aaa5be58b474793b0
2011 Author: David Laban <david.laban@collabora.co.uk>
2012 Date: Wed Mar 2 17:52:55 2011 +0000
2013
2014 Expand on MediaDescription's docstring.
2015
2016 commit 9bef867105d6eab70d97ffbeff5f1c279547e217
2017 Author: David Laban <david.laban@collabora.co.uk>
2018 Date: Wed Mar 2 17:51:56 2011 +0000
2019
2020 ContentIfaceMedia: update docstring
2021
2022 * Change some punctuation/grammar to make it easier to read
2023 * Mention FurtherNegotiationRequired
2024 * Update "Protocols without negotiation" to be easier to read.
2025 * Also update MD.Accept docstring to mention FurtherNegotiationRequired.
2026
2027 commit 5d4b7b97f55926334d84ea2699f1bb4f901ab785
2028 Author: David Laban <david.laban@collabora.co.uk>
2029 Date: Wed Mar 2 17:44:19 2011 +0000
2030
2031 ContentIfaceMedia:UpdateLocalMediaDescription: Remove Renegotiate param.
2032
2033 The FurtherNegotiationRequired property covers this use-case in a
2034 symmetrical way.
2035
2036 Also, add InvalidArgument to the list of errors, to reflect the signature
2037 of Accept()
2038
2039 commit ee909ee2aa27cf94116caffb09c82dfa7d1357e8
2040 Author: David Laban <david.laban@collabora.co.uk>
2041 Date: Wed Mar 2 16:39:23 2011 +0000
2042
2043 MediaDescription: FurtherNegotiationRequired
2044
2045 commit c00af9aa64aff01ccb181b5072aa2a716c0a2085
2046 Author: David Laban <david.laban@collabora.co.uk>
2047 Date: Wed Mar 2 16:38:59 2011 +0000
2048
2049 fix whitespace
2050
2051 commit e486db38aeb4b4cd2901408b17fe20e288101465
2052 Author: David Laban <david.laban@collabora.co.uk>
2053 Date: Wed Mar 2 16:38:37 2011 +0000
2054
2055 MediaDescription: HasRemoteInformation always exists in mapping.
2056
2057 The special case of an empty dict made me want to throw up. Sorry.
2058
2059 commit 0a210e937112a88788c078a04d6c9d75051581f1
2060 Author: David Laban <david.laban@collabora.co.uk>
2061 Date: Wed Mar 2 16:35:48 2011 +0000
2062
2063 MediaDescription: Clarify RemoteContact = 0
2064
2065 commit 3584bcc72cdefaa4205fa6baa1f6dff1750e758d
2066 Author: David Laban <david.laban@collabora.co.uk>
2067 Date: Wed Mar 2 15:47:32 2011 +0000
2068
2069 fix whitespace
2070
2071 commit 8ad127149c7865ff72d5a2fe9a950f9e4690c204
2072 Author: David Laban <david.laban@collabora.co.uk>
2073 Date: Wed Mar 2 12:54:49 2011 +0000
2074
2075 s/RemoteFeedbackMessages/FeedbackMessages/
2076
2077 commit b8887c34c40282604320f7198206f69c91b94db7
2078 Author: David Laban <david.laban@collabora.co.uk>
2079 Date: Wed Mar 2 12:51:20 2011 +0000
2080
2081 Document why MAXUINT is the default value.
2082
2083 Also, convert tabs to spaces.
8682084
8692085 commit 0de9ca669e9cde36128c20ee1ffadb9640d56c9f
8702086 Author: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
9842200
9852201 Merge branch 'hidden'
9862202
2203 commit 7c073ad0d6c676d980b77094d7163193e26e9888
2204 Author: David Laban <david.laban@collabora.co.uk>
2205 Date: Wed Feb 16 15:29:39 2011 +0000
2206
2207 Re-structure Call.Interface.Media's docstring.
2208
2209 * Re-order, so HasRemoteInfo = false first, then HasRemoteInfo = true
2210
2211 * Make Protocols without negotiation more like a footnote at the end,
2212 rather than in the middle between the SIP/XMPP standard case and
2213 "Changing codecs mid-call" (which also applies to SIP/XMPP)
2214
2215 * Might require adding more cross-references, but the xml is easier to
2216 edit if I leave that until later.
2217
9872218 commit 18dc63c416ba9f56a6c1b83adba0e8b961f05ff1
9882219 Author: Will Thompson <will.thompson@collabora.co.uk>
9892220 Date: Fri Feb 4 09:36:12 2011 +0100
9992230 Add initial Call.Content.I.VideoControl interface
10002231
10012232 https://bugs.freedesktop.org/show_bug.cgi?id=32900
2233
2234 commit 8da89948e8ed0b0878d5ba83f45880785fe1d497
2235 Author: Olivier Crête <olivier.crete@collabora.co.uk>
2236 Date: Sun Feb 13 16:44:19 2011 +0000
2237
2238 Call.Stream.I.Media: Explain when LocalCredentialsChanged happens
2239
2240 Ref fd.o#28705
2241
2242 commit 14deb263497a256b0a04a1fe82f101b069772e6e
2243 Author: Olivier Crête <olivier.crete@collabora.co.uk>
2244 Date: Sun Feb 13 16:42:34 2011 +0000
2245
2246 Call.Stream.I.Media: Explain what the LocalCredentials
2247
2248 Ref fd.o#28705
2249
2250 commit bbd9cdf27dcefbbbd24d1cb4560f88fcb248bcdd
2251 Author: Olivier Crête <olivier.crete@collabora.co.uk>
2252 Date: Sun Feb 13 16:39:51 2011 +0000
2253
2254 Call.Stream.I.Media: Clarify text about ICE restarts
2255
2256 commit 57e0704db429adb07177d2a68d24f03572740a1b
2257 Author: Olivier Crête <olivier.crete@collabora.co.uk>
2258 Date: Sun Feb 13 16:38:16 2011 +0000
2259
2260 Call.Stream.I.Media: Explain what this interface is for
2261
2262 Also explain how it is different from an Endpoint.
2263
2264 commit 6c01c5d3b54a1d7c4fe1626285c4fb9b78764f9c
2265 Author: Olivier Crête <olivier.crete@collabora.co.uk>
2266 Date: Sun Feb 13 16:30:48 2011 +0000
2267
2268 Call.Stream: Document what a stream is
2269
2270 fd.o#31160
2271
2272 commit 84d40392af4d85e0c282e957257d74114f2aa36e
2273 Author: Olivier Crête <olivier.crete@collabora.co.uk>
2274 Date: Sun Feb 13 16:16:29 2011 +0000
2275
2276 Call.Content.MediaDescription: Rename RemoteCodecs to Codecs
2277
2278 Since the same property names are used in the answer, it does not make
2279 sense to put the word Remote in there, since the property is also
2280 used to describe the local codecs in this context.
2281
2282 commit d970656a1fe1a281696e6d31a2a6719df9f00f0f
2283 Author: Olivier Crête <olivier.crete@collabora.co.uk>
2284 Date: Sun Feb 13 16:11:38 2011 +0000
2285
2286 C.Content.MediaDescription.I.RTPHeaderExtension: Move from CodecOffer to MediaDescription
2287
2288 Also remove the method in that interface, all the parameters are sent in the
2289 Accept call now. Ref fd.o#29656
2290
2291 commit 4222bf8f7db053de1c817938d2cf77e89c2cafd5
2292 Merge: 4c40f5a 9a75803
2293 Author: Olivier Crête <olivier.crete@collabora.co.uk>
2294 Date: Sun Feb 13 16:07:56 2011 +0000
2295
2296 Merge branch 'rtp-hdrext' into rtp-hdrext-mediadesc
2297
2298 Conflicts:
2299 spec/all.xml
2300
2301 commit c7fa8b8ab095c816749d1b89e4163f66df85487d
2302 Author: Olivier Crête <olivier.crete@collabora.co.uk>
2303 Date: Sun Feb 13 16:04:29 2011 +0000
2304
2305 C.Content.MediaDescription.I.RTCPFeedback: Move from CodecOffer to MediaDescription
2306
2307 Also remove the method in that interface, all the parameters are sent in the
2308 Accept call now. Ref fd.o#28687
2309
2310 commit e5ea605a2e619bf857b529b107f2160e1ca3924b
2311 Merge: 4c40f5a 2abed9e
2312 Author: Olivier Crête <olivier.crete@collabora.co.uk>
2313 Date: Sun Feb 13 15:56:10 2011 +0000
2314
2315 Merge branch 'rtcp-fb' into rtcp-fb-mediadesc
2316
2317 Conflicts:
2318 spec/Call_Content_Codec_Offer.xml
2319 spec/all.xml
2320
2321 commit 78d6dfad614ba9213650e9ffe68d01c2a3ddd4af
2322 Author: Olivier Crête <olivier.crete@collabora.co.uk>
2323 Date: Thu Jan 6 18:15:41 2011 -0500
2324
2325 Call.Content.I.Media: Rename UpdateCodecs to UpdateLocalMediaDescription
2326
2327 Also, flesh out how to do changes that trigger a renegotiation and changes
2328 that don't.
2329
2330 commit 61b5217a0172f8ab34f76ad2731c503223481bcc
2331 Author: Olivier Crête <olivier.crete@collabora.co.uk>
2332 Date: Thu Jan 6 18:08:33 2011 -0500
2333
2334 Call.Content.I.Media: Have a single local Media Description
2335
2336 There is only one stream of media sent to every person in the content.
2337
2338 commit 9a75803e01891a688f37d5bac3af802c123b8c34
2339 Author: Olivier Crête <olivier.crete@collabora.co.uk>
2340 Date: Thu Feb 10 11:49:10 2011 +0000
2341
2342 Add Call.Content.CodecOffer.Interface.RTPHeaderExtensions.DRAFT
2343
2344 commit 66291a990db5396861ba5462df18812c955883ad
2345 Author: David Laban <david.laban@collabora.co.uk>
2346 Date: Mon Feb 7 18:00:27 2011 +0000
2347
2348 Address ocrete's comments
2349
2350 Move struct definition into Call_Stream_Endpoint.xml
2351 Note the different behaviours expected by the Controlling
2352 and controlled sides in ICE
2353
2354 commit 2dfbe52b97817d2ed35224f941860738ab2d0827
2355 Author: David Laban <david.laban@collabora.co.uk>
2356 Date: Mon Feb 7 16:52:09 2011 +0000
2357
2358 Endpoint: s/SelectedCandidate/SelectedCandidatePairs/
2359
2360 Also, add some references to the ICE RFC, since this is what we are trying
2361 to represent here.
10022362
10032363 commit 23d7a8c9c5eb69b2ee914f53f7231fcb7bc8e2a0
10042364 Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
11492509
11502510 Add a first cut at A[M].Interface.Hidden.
11512511
2512 commit 4c40f5a9619b404cb7176659ceb752bb843130ca
2513 Merge: 9315a43 3fdfa27
2514 Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
2515 Date: Mon Jan 10 18:29:54 2011 +0000
2516
2517 Merge branch 'master' into description-objects-fresh-spec
2518
2519 commit 9315a43a8b3e7a240f32dee074495a788eb03212
2520 Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
2521 Date: Mon Jan 10 17:06:26 2011 +0000
2522
2523 Use more specific types
2524
2525 commit cd2c09dc8a5c59a31fb24426e6727ea9b3923b73
2526 Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
2527 Date: Mon Jan 10 17:06:11 2011 +0000
2528
2529 Clarify the LocalMediaDescriptions map
2530
2531 commit 50ca3a28d869d53486ea6e00f3449c24946a2921
2532 Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
2533 Date: Mon Jan 10 17:05:49 2011 +0000
2534
2535 Clarify the RemoteContact member a bit
2536
2537 commit 02c4f1c851845895508c5c995dbd359fd30efbdd
2538 Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
2539 Date: Mon Jan 10 17:02:33 2011 +0000
2540
2541 Rename NoRemoteInformation to HasRemoteInformation
2542
2543 commit 03ebd90ee47647b2b319092b2f211959576ff7ea
2544 Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
2545 Date: Mon Jan 10 16:57:19 2011 +0000
2546
2547 Several trivial typo fixes
2548
2549 commit b5f7d302343d7c02dd01a0262f47eda09132b868
2550 Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
2551 Date: Fri Jan 7 19:14:47 2011 +0000
2552
2553 Update UpdateCodecs text and possible errors
2554
2555 commit 2abed9e67f67d05f37c02ae6497483855c21092a
2556 Author: Olivier Crête <olivier.crete@collabora.co.uk>
2557 Date: Fri Jan 7 14:09:25 2011 -0500
2558
2559 RTCP_Feedback: Use MAXUINT to leave the MinimumReportingInterval at the default
2560
2561 commit d1326491b3a478f2802d8b86a3c2ae3b0430a4a7
2562 Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
2563 Date: Wed Jan 5 18:50:49 2011 +0000
2564
2565 Rename from Description to MediaDescription
2566
2567 commit 9cf8e9f831e8facde6362f7b858eefc50712afe8
2568 Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
2569 Date: Wed Jan 5 17:26:09 2011 +0000
2570
2571 Seperate description updating and removal
2572
2573 commit 63a7c44d7058b3ba5b123e55799aedf162d10822
2574 Author: Olivier Crête <olivier.crete@collabora.co.uk>
2575 Date: Tue Jan 4 15:24:40 2011 -0500
2576
2577 RTCP_Feedback: The Minimum RTCP reporting interval is per codec in RFC 4585
2578
2579 commit ed01cabc4d0b346cd9e474491c3ba88469de81da
2580 Author: Olivier Crête <olivier.crete@collabora.co.uk>
2581 Date: Tue Jan 4 15:11:24 2011 -0500
2582
2583 RTCP_Feedback: Put extra params as a single string
2584
2585 commit 810361031f60b4708d457e7e27a084954d0c3493
2586 Author: Olivier Crête <olivier.crete@collabora.co.uk>
2587 Date: Tue Jan 4 15:09:21 2011 -0500
2588
2589 RTCP_Feedback: feedback types are not Codecs, they're Messages
2590
2591 commit f080e7848681f21dccea62c924c19e3035a81d33
2592 Author: Jonny Lamb <jonny.lamb@collabora.co.uk>
2593 Date: Fri Oct 29 12:32:44 2010 +0100
2594
2595 RTCP_Feedback: add Category to codec feedback struct
2596
2597 Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
2598
2599 commit b4f23ae6c30a750e751d237b4a28a1762ac2e1d3
2600 Author: Jonny Lamb <jonny.lamb@collabora.co.uk>
2601 Date: Wed Oct 27 14:28:15 2010 +0100
2602
2603 RTCP_Feedback: simplify spec as per Mr. Crêpe's requests
2604
2605 Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
2606
2607 commit 90e364eae5b0fb077fcf437b08779d322d90f13a
2608 Author: Jonny Lamb <jonny.lamb@collabora.co.uk>
2609 Date: Fri Oct 15 08:51:32 2010 +0100
2610
2611 RTCP_Feedback: add InvalidArgument possible error
2612
2613 Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
2614
2615 commit a839eb20a01b8cfb753ea7bd2b3adb823b7392cb
2616 Author: Jonny Lamb <jonny.lamb@collabora.co.uk>
2617 Date: Thu Oct 14 13:00:50 2010 +0100
2618
2619 RTCP_Feedback: document interface
2620
2621 Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
2622
2623 commit 8868a22d13cd393ae6b49f1357141c6bc875c35f
2624 Author: Jonny Lamb <jonny.lamb@collabora.co.uk>
2625 Date: Wed Oct 13 13:30:10 2010 +0100
2626
2627 RTCP_Feedback: remove empty parameter flag value
2628
2629 Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
2630
2631 commit d20e97f64734ffb81275eb3c0e98fb36e6686a19
2632 Author: Jonny Lamb <jonny.lamb@collabora.co.uk>
2633 Date: Wed Oct 13 11:59:25 2010 +0100
2634
2635 RTCP_Feedback: wrap long lines
2636
2637 Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
2638
2639 commit 7cf330c48966c88c2f09b768d757499ba27acdfe
2640 Author: Jonny Lamb <jonny.lamb@collabora.co.uk>
2641 Date: Wed Oct 13 11:57:01 2010 +0100
2642
2643 RTCP_Feedback: a(uu) should in fact be a{uu}
2644
2645 Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
2646
2647 commit 9a155a6e0dbfcd3cf3b0179f806264f8e884b769
2648 Author: Jonny Lamb <jonny.lamb@collabora.co.uk>
2649 Date: Wed Oct 13 11:49:58 2010 +0100
2650
2651 RTCP_Feedback: change the parameters enum to a set of flags
2652
2653 Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
2654
2655 commit b080fa4d41914b6e9e1211a613aa405300fa4ea0
2656 Author: Jonny Lamb <jonny.lamb@collabora.co.uk>
2657 Date: Wed Oct 13 11:49:33 2010 +0100
2658
2659 RTCP_Feedback: rename Update to Set and add both ack and nack types
2660
2661 Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
2662
2663 commit 4ff5070f0d4018f5a2b4e1c9f2df4e8c104a38bf
2664 Author: Jonny Lamb <jonny.lamb@collabora.co.uk>
2665 Date: Tue Oct 12 17:35:38 2010 +0100
2666
2667 Call_Content_Codec_Offer: initial RTCP Feedback interface
2668
2669 Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
2670
11522671 commit 3fdfa27deea1b7204d458a126e015bddf87b92dc
11532672 Author: Danielle Madeley <danielle.madeley@collabora.co.uk>
11542673 Date: Thu Dec 23 11:23:03 2010 +1100
12212740 arguments, rather than correctly referencing the corresponding arguments
12222741 of the new signal.
12232742
2743 commit 0e65b1b3c632e01da574db97f11e990222484008
2744 Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
2745 Date: Fri Dec 17 15:38:28 2010 +0000
2746
2747 Small tweak and add fixme
2748
2749 commit c204607f49e0a7be504d4524487ddc36f2cb9e49
2750 Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
2751 Date: Fri Dec 17 15:26:33 2010 +0000
2752
2753 Document that DescriptionOfferDone has to be emitted after every NewDescriptionOffer
2754
12242755 commit 1574f2629ffbec26841d392da0a25f75171b66bb
12252756 Author: Simon McVittie <simon.mcvittie@collabora.co.uk>
12262757 Date: Fri Dec 17 12:03:55 2010 +0000
12862817
12872818 Also, PEPify constant assignment
12882819
2820 commit 9d590bc9bc102af63fd22a969b19a438cd06fab7
2821 Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
2822 Date: Tue Dec 14 19:15:22 2010 +0000
2823
2824 Rename EmptyDescription to NoRemoteInformation
2825
2826 commit 96a82dcb0a3c4c13b55845ff95a443e19c676518
2827 Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
2828 Date: Tue Dec 14 16:58:23 2010 +0000
2829
2830 Add a seperate signal for descriptions being done
2831
12892832 commit e9127a411d337754a7c0d1eb52c70e5740bb605f
12902833 Author: Alex Merry <dev@randomguy3.me.uk>
12912834 Date: Tue Dec 14 00:49:37 2010 +0000
13082851
13092852 Make a note of annotations when parsing the spec.
13102853
2854 commit 89a81b010338117319905d751a7b5ceaabe0632a
2855 Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
2856 Date: Mon Dec 13 16:42:51 2010 +0000
2857
2858 Fix wording in several places
2859
2860 commit 52de582c467ca57d9ec89865e108737db29fb898
2861 Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
2862 Date: Mon Dec 13 16:41:55 2010 +0000
2863
2864 Fix typo
2865
2866 commit d024700e6339ffcdea4d07e4b688600ee8c583f6
2867 Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
2868 Date: Mon Dec 13 16:41:44 2010 +0000
2869
2870 Correct naming of the description object path
2871
2872 commit 2a9163c799d38622285f1dd0ad6a47e0c187db4a
2873 Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
2874 Date: Mon Dec 13 16:41:31 2010 +0000
2875
2876 More Ugly_Case
2877
13112878 commit 8e556c3fe22eb1ee7f07dc4801bbe7d6aaa41144
13122879 Author: Alex Merry <dev@randomguy3.me.uk>
13132880 Date: Mon Dec 13 16:31:28 2010 +0000
13182885 by methods, properties and signals.
13192886
13202887 Signed-off-by: Will Thompson <will.thompson@collabora.co.uk>
2888
2889 commit 861fa6064bb7ccd2f8f237f5931059a0caef6453
2890 Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
2891 Date: Fri Dec 10 20:01:45 2010 +0000
2892
2893 Replace CodecOffer by Description objects
2894
2895 For several advanced features we want to Offer more then just the codecs to the
2896 local side. This changes the interface away from a very codec-centric way and
2897 towards using a more generic description of the remote (and local offers).
2898
2899 The other big change is that we now track our local offers per-handle. This is
2900 so that non-codec information that can be different per remote-end can be
2901 tracked explicitely over D-Bus.
13212902
13222903 commit 07085e8be62191fd56771c8fa9e31db67ec1110a
13232904 Author: Simon McVittie <simon.mcvittie@collabora.co.uk>
15783159 Date: Tue Nov 30 16:08:24 2010 +1100
15793160
15803161 Add parser support for <tp:client-interest>
3162
3163 commit f854fc4b9d9a07c6efc464acee1b3f1b9afb709b
3164 Author: Danielle Madeley <danielle.madeley@collabora.co.uk>
3165 Date: Tue Nov 9 16:38:14 2010 +1100
3166
3167 Call: add the CodecOffer's immutable properties to NewCodecOffer
3168
3169 Fixes https://bugs.freedesktop.org/show_bug.cgi?id=31274
15813170
15823171 commit b58d627911903c1aacd4e6fc15297989cedb6754
15833172 Author: Simon McVittie <simon.mcvittie@collabora.co.uk>
+27
-0
NEWS less more
00 This file contains the same edited highlights as the announcement emails.
11 For full details, see the ChangeLog in tarballs, or "git log" in Git
22 checkouts.
3
4 telepathy-spec 0.23.4 (2011-09-29)
5 ==================================
6
7 API additions and clarifications:
8
9 • Always give contact identifiers together with handles in
10 Channel.Interface.Group. This helps clients to create contact objects without
11 extra async operations. Additions are:
12 • Channel.Interface.Group.MemberIdentifiers;
13 • Channel.Interface.Group.SelfContactChanged; and
14 • Channel.Interface.Group.HandleOwnersChangedDetailed.
15
16 • AccountManager: remove note about service activation. Mission Control is
17 service-activatable and is probably the only implementation we'll ever have.
18
19 • Clarify possible errors returned by AM.CreateAccount.
20
21 Spec HTML improvements:
22
23 • Now <tp:value-ref> is used to reference a value in a enumeration.
24
25 Call DRAFT2 landed
26
27 • Call interfaces are now versioned. For example
28 org.freedesktop.Telepathy.Channel.Type.Call.DRAFT is now renamed to
29 org.freedesktop.Telepathy.Channel.Type.Call1.
330
431 telepathy-spec 0.23.3 (2011-07-14)
532 ==================================
+1
-1
doc/templates/interface.html less more
432432 #elif $property.emits_changed == $property.EMITS_CHANGED_NONE
433433 <div class="annotation emits-changed emits-changed-none">
434434 The <code>org.freedesktop.DBus.Properties.PropertiesChanged</code>
435 signal is <strong>not</strong> emitted when this property changes.</div>
435 signal is <strong>not</strong> emitted when this property changes.
436436 </div>
437437 #end if
438438
+9
-17
spec/Account_Manager.xml less more
2424 details.</p>
2525
2626 <p>The current account manager is defined to be the process that owns
27 the well-known bus name org.freedesktop.Telepathy.AccountManager on
27 the well-known bus name <tt>org.freedesktop.Telepathy.AccountManager</tt> on
2828 the session bus. This process must export an
29 /org/freedesktop/Telepathy/AccountManager object with the
29 <tt>/org/freedesktop/Telepathy/AccountManager</tt> object with the
3030 AccountManager interface.</p>
31
32 <p>Until a mechanism exists for making a reasonable automatic choice
33 of AccountManager implementation, implementations SHOULD NOT
34 register as an activatable service for the AccountManager's
35 well-known bus name. Instead, it is RECOMMENDED that some component
36 of the user's session will select and activate a particular
37 implementation, and that other Telepathy-enabled programs can
38 detect whether Telepathy is in use by checking whether the
39 AccountManager's well-known name is in use at runtime.</p>
4031 </tp:docstring>
4132 <tp:added version="0.17.2"/>
4233
274265 <tp:possible-errors>
275266 <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
276267 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
277 <p>The Connection_Manager is not installed or does not
278 implement the given Protocol, or one of the properties in the
279 Properties argument is unsupported.</p>
268 <p>The <var>Connection_Manager</var> is not installed or does not
269 implement the given <var>Protocol</var>.</p>
280270 </tp:docstring>
281271 </tp:error>
282272 <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
283273 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
284 <p>The Parameters provided omit a required parameter
285 or provide unsupported parameter, or the type of one
286 of the Parameters or Properties is inappropriate.</p>
274 <p>The <var>Parameters</var> provided were unacceptable: they might
275 omit a
276 <tp:value-ref type='Conn_Mgr_Param_Flags'>Required</tp:value-ref>
277 parameter, include an unsupported parameter, or have a value of
278 the wrong type.</p>
287279 </tp:docstring>
288280 </tp:error>
289281 </tp:possible-errors>
+35
-89
spec/Call_Content.xml less more
1919 02110-1301, USA.</p>
2020 </tp:license>
2121
22 <interface name="org.freedesktop.Telepathy.Call.Content.DRAFT"
22 <interface name="org.freedesktop.Telepathy.Call1.Content"
2323 tp:causes-havoc="experimental">
2424 <tp:added version="0.19.0">(draft 1)</tp:added>
25 <tp:requires
26 interface="org.freedesktop.Telepathy.Call1.Interface.Mute"/>
2527
2628 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
2729 This object represents one Content inside a <tp:dbus-ref
28 namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref>. For
30 namespace="ofdT.Channel.Type">Call1</tp:dbus-ref>. For
2931 example, in an audio/video call there would be one audio content
3032 and one video content. Each content has one or more <tp:dbus-ref
31 namespace="ofdT.Call">Stream.DRAFT</tp:dbus-ref> objects which
33 namespace="ofdT.Call1">Stream</tp:dbus-ref> objects which
3234 represent the actual transport to one or more remote contacts.
3335 </tp:docstring>
34
35 <tp:enum name="Content_Removal_Reason" type="u">
36 <tp:added version="0.21.2"/>
37 <tp:docstring>
38 A representation of the reason for a content to be removed,
39 which may be used by simple clients, or used as a fallback
40 when the DBus_Reason is not understood. This enum will be
41 extended with future reasons as and when appropriate, so
42 clients SHOULD keep up to date with its values, but also be
43 happy to fallback to the Unknown value when an unknown value
44 is encountered.
45 </tp:docstring>
46
47 <tp:enumvalue suffix="Unknown" value="0">
48 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
49 We just don't know. Unknown values of this enum SHOULD also be
50 treated like this.
51 </tp:docstring>
52 </tp:enumvalue>
53
54 <tp:enumvalue suffix="User_Requested" value="1">
55 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
56 <p>The local user requests that this content is removed
57 from the call.</p>
58 </tp:docstring>
59 </tp:enumvalue>
60
61 <tp:enumvalue suffix="Error" value="2">
62 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
63 <p>There is an error with the content which means that it
64 has to be removed from the call.</p>
65 </tp:docstring>
66 </tp:enumvalue>
67
68 <tp:enumvalue suffix="Unsupported" value="3">
69 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
70 <p>Some aspect of the content is unsupported so has to be
71 removed from the call.</p>
72 </tp:docstring>
73 </tp:enumvalue>
74 </tp:enum>
7536
7637 <method name="Remove" tp:name-for-bindings="Remove">
7738 <tp:changed version="0.21.2">previously there were no
7839 arguments</tp:changed>
7940 <tp:docstring>
80 Remove the content from the call.
81 </tp:docstring>
82
83 <arg direction="in" name="Reason" type="u"
84 tp:type="Content_Removal_Reason">
85 <tp:docstring>
86 A generic hangup reason.
87 </tp:docstring>
88 </arg>
89
90 <arg direction="in" name="Detailed_Removal_Reason" type="s"
91 tp:type="DBus_Error_Name">
92 <tp:docstring>
93 A more specific reason for the content removal, if one is
94 available, or an empty string.
95 </tp:docstring>
96 </arg>
97
98 <arg direction="in" name="Message" type="s">
99 <tp:docstring>
100 A human-readable message for the reason of removing the
101 content, such as "Fatal streaming failure" or "no codec
102 intersection". This property can be left empty if no reason
103 is to be given.
104 </tp:docstring>
105 </arg>
41 Remove the content from the call. This will cause
42 <tp:member-ref>Removed</tp:member-ref>((self_handle,
43 <tp:value-ref type="Call_State_Change_Reason">User_Requested</tp:value-ref>, "", "")) to be
44 emitted.
45 </tp:docstring>
10646
10747 <tp:possible-errors>
10848 <tp:error name="org.freedesktop.Telepathy.Error.NetworkError" />
11959 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
12060 <p>Emitted when the content is removed from the call. This
12161 is the same as the <tp:dbus-ref
122 namespace="ofdT.Channel.Type">Call.DRAFT.ContentRemoved</tp:dbus-ref>
62 namespace="ofdT.Channel.Type">Call1.ContentRemoved</tp:dbus-ref>
12363 signal.</p>
12464 </tp:docstring>
12565 </signal>
12969 <tp:added version="0.19.11"/>
13070 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
13171 <p>Extra interfaces provided by this content, such as <tp:dbus-ref
132 namespace="ofdT.Call">Content.Interface.Media.DRAFT</tp:dbus-ref> or
133 <tp:dbus-ref namespace="ofdT.Call">Content.Interface.Mute.DRAFT</tp:dbus-ref>.
72 namespace="ofdT.Call1">Content.Interface.Media</tp:dbus-ref>,
73 <tp:dbus-ref namespace="ofdT.Channel">Interface.Hold</tp:dbus-ref> or
74 <tp:dbus-ref namespace="ofdT.Call1">Interface.Mute</tp:dbus-ref>.
13475 This SHOULD NOT include the Content interface itself, and cannot
13576 change once the content has been created.</p>
13677 </tp:docstring>
163104 The disposition of this content, which defines whether to
164105 automatically start sending data on the streams when
165106 <tp:dbus-ref
166 namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref> is
107 namespace="ofdT.Channel.Type.Call1">Accept</tp:dbus-ref> is
167108 called on the channel.
168109 </tp:docstring>
169110
170111 <tp:enumvalue suffix="None" value="0">
171112 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
172 The content has no specific disposition
113 The content has no specific disposition.
173114 </tp:docstring>
174115 </tp:enumvalue>
175116
177118 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
178119 <p>The content was initially part of the call. When
179120 <tp:dbus-ref
180 namespace="ofdT.Channel.Type.Call.DRAFT">Accept</tp:dbus-ref>
121 namespace="ofdT.Channel.Type.Call1">Accept</tp:dbus-ref>
181122 is called on the channel, all streams of this content with
182123 <tp:dbus-ref
183 namespace="ofdT.Call.Stream.DRAFT">LocalSendingState</tp:dbus-ref>
184 set to <tp:type>Sending_State</tp:type>_Pending_Send will be
185 moved to <tp:type>Sending_State</tp:type>_Sending as if
124 namespace="ofdT.Call1.Stream">LocalSendingState</tp:dbus-ref>
125 set to <tp:value-ref type="Sending_State">Pending_Send</tp:value-ref> will be
126 moved to <tp:value-ref type="Sending_State">Sending</tp:value-ref> as if
186127 <tp:dbus-ref
187 namespace="ofdT.Call.Stream.DRAFT">SetSending</tp:dbus-ref>
128 namespace="ofdT.Call1.Stream">SetSending</tp:dbus-ref>
188129 (True) had been called.</p>
189130 </tp:docstring>
190131 </tp:enumvalue>
207148 <arg name="Streams" type="ao">
208149 <tp:docstring>
209150 The <tp:dbus-ref
210 namespace="ofdT.Call">Stream.DRAFT</tp:dbus-ref>s which were
151 namespace="ofdT.Call1">Stream</tp:dbus-ref>s which were
211152 added.
212153 </tp:docstring>
213154 </arg>
220161 <p>Emitted when streams are removed from a call</p>
221162 </tp:docstring>
222163 <arg name="Streams" type="ao">
223 <tp:docstring>
224 The <tp:dbus-ref
225 namespace="ofdT.Call">Stream.DRAFT</tp:dbus-ref>s which were
226 removed.
227 </tp:docstring>
228 </arg>
164 <tp:docstring>
165 The <tp:dbus-ref
166 namespace="ofdT.Call1">Stream</tp:dbus-ref>s which were
167 removed.
168 </tp:docstring>
169 </arg>
170 <arg name="Reason" type="(uuss)" tp:type="Call_State_Reason">
171 <tp:docstring>
172 Why the content was removed.
173 </tp:docstring>
174 </arg>
229175 </signal>
230176
231177 <property name="Streams" tp:name-for-bindings="Streams"
232178 type="ao" access="read">
233179 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
234 <p>The list of <tp:dbus-ref namespace="ofdT.Call"
235 >Stream.DRAFT</tp:dbus-ref> objects that exist in this
180 <p>The list of <tp:dbus-ref namespace="ofdT.Call1"
181 >Stream</tp:dbus-ref> objects that exist in this
236182 content.</p>
237183
238184 <tp:rationale>
+0
-87
spec/Call_Content_Codec_Offer.xml less more
0 <?xml version="1.0" ?>
1 <node name="/Call_Content_Codec_Offer"
2 xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
3 <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
4 <tp:copyright>Copyright © 2009-2010 Nokia Corporation</tp:copyright>
5 <tp:license xmlns="http://www.w3.org/1999/xhtml">
6 <p>This library is free software; you can redistribute it and/or
7 modify it under the terms of the GNU Lesser General Public
8 License as published by the Free Software Foundation; either
9 version 2.1 of the License, or (at your option) any later version.</p>
10
11 <p>This library is distributed in the hope that it will be useful,
12 but WITHOUT ANY WARRANTY; without even the implied warranty of
13 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
14 Lesser General Public License for more details.</p>
15
16 <p>You should have received a copy of the GNU Lesser General Public
17 License along with this library; if not, write to the Free Software
18 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
19 02110-1301, USA.</p>
20 </tp:license>
21
22 <interface name="org.freedesktop.Telepathy.Call.Content.CodecOffer.DRAFT"
23 tp:causes-havoc="experimental">
24 <tp:added version="0.19.0">(draft 1)</tp:added>
25
26 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
27 This object represents an offer of a Codec payload mapping.
28 </tp:docstring>
29
30 <method name="Accept" tp:name-for-bindings="Accept">
31 <arg name="Codecs" direction="in"
32 type="a(usuua{ss})" tp:type="Codec[]">
33 <tp:docstring>
34 The local codec mapping to send to the remote contacts and
35 to use in the <tp:dbus-ref
36 namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref>.
37 </tp:docstring>
38 </arg>
39 <tp:docstring>
40 Accept the updated Codec mapping and update the local mapping.
41 </tp:docstring>
42 <tp:possible-errors>
43 <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
44 <tp:docstring>
45 The codecs given as the argument are invalid in some way.
46 </tp:docstring>
47 </tp:error>
48 </tp:possible-errors>
49 </method>
50
51 <method name="Reject" tp:name-for-bindings="Reject">
52 <tp:docstring>
53 Reject the proposed update to the codecs
54 FIXME add error codes and strings here
55 </tp:docstring>
56 </method>
57
58 <property name="Interfaces" tp:name-for-bindings="Interfaces"
59 type="as" tp:type="DBus_Interface[]" access="read" tp:immutable="yes">
60 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
61 <p>Extra interfaces provided by this codec offer. This SHOULD
62 NOT include the CodecOffer interface itself, and cannot change
63 once the content has been created.</p>
64 </tp:docstring>
65 </property>
66
67 <property name="RemoteContactCodecs"
68 tp:name-for-bindings="Remote_Contact_Codecs"
69 type="a(usuua{ss})" tp:type="Codec[]" access="read"
70 tp:immutable="yes">
71 <tp:docstring>
72 A list of codecs the remote contact supports.
73 </tp:docstring>
74 </property>
75
76 <property name="RemoteContact" tp:name-for-bindings="Remote_Contact"
77 type="u" tp:type="Contact_Handle" access="read" tp:immutable="yes">
78 <tp:docstring>
79 The contact handle that this codec offer applies to.
80 </tp:docstring>
81 </property>
82
83
84 </interface>
85 </node>
86 <!-- vim:set sw=2 sts=2 et ft=xml: -->
+429
-215
spec/Call_Content_Interface_Media.xml less more
1919 02110-1301, USA.</p>
2020 </tp:license>
2121
22 <interface name="org.freedesktop.Telepathy.Call.Content.Interface.Media.DRAFT"
22 <interface
23 name="org.freedesktop.Telepathy.Call1.Content.Interface.Media"
2324 tp:causes-havoc="experimental">
24 <tp:added version="0.19.0">(draft 1)</tp:added>
25 <tp:requires interface="org.freedesktop.Telepathy.Call.Content.DRAFT"/>
25 <tp:added version="0.23.4">(draft 2)</tp:added>
26 <tp:requires interface="org.freedesktop.Telepathy.Call1.Content"/>
2627
2728 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
2829 <p>Interface to use by a software implementation of media
2930 streaming. The reason behind splitting the members of this
3031 interface out from the main <tp:dbus-ref
31 namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref> interface is
32 namespace="ofdT.Call1">Content</tp:dbus-ref> interface is
3233 that the software is not necessarily what controls the
3334 media. An example of this is in GSM phones, where the CM just
3435 tells the phone to dial a number and it does the audio routing
3536 in a device specific hardware way and the CM does not need
3637 to concern itself with codecs.</p>
3738
38 <h4>Codec negotiation</h4>
39 <h4>Codec Negotiation</h4>
3940
4041 <p>When a new <tp:dbus-ref
41 namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref> channel
42 appears, whether it was requested or not, a <tp:dbus-ref
43 namespace="ofdT.Call.Content">CodecOffer.DRAFT</tp:dbus-ref>
44 will either be waiting in the
45 <tp:member-ref>CodecOffer</tp:member-ref> property, or will
42 namespace="ofdT.Channel.Type">Call1</tp:dbus-ref> channel
43 appears (whether it was requested or not) a <tp:dbus-ref
44 namespace="ofdT.Call1.Content">MediaDescription</tp:dbus-ref>
45 object will either be waiting in the
46 <tp:member-ref>MediaDescriptionOffer</tp:member-ref> property, or will
4647 appear at some point via the
47 <tp:member-ref>NewCodecOffer</tp:member-ref> signal.</p>
48
49 <p>The <tp:dbus-ref
50 namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecs</tp:dbus-ref>
51 property on the codec offer lists the codecs which are
52 supported by the remote contact, and so will determine the
53 codecs that should be proposed by the local user's streaming
54 implementation. An empty list means all codecs can be proposed.</p>
55
56 <p>For incoming calls on protocols where codecs are proposed when
57 starting the call (for example, <a
58 href="http://xmpp.org/extensions/xep-0166.html">Jingle</a>),
59 the <tp:dbus-ref
60 namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecs</tp:dbus-ref>
61 will contain information on the codecs that have already been
62 proposed by the remote contact, otherwise the codec map will
63 be the empty list.</p>
64
65 <p>The streaming implementation should look at the remote codec
66 map and the codecs known by the local user and call
48 <tp:member-ref>NewMediaDescriptionOffer</tp:member-ref> signal.</p>
49
50 <p>If nothing is known about the remote side's Media capabilities
51 (e.g. outgoing SIP/XMPP call), this <tp:dbus-ref namespace="ofdT.Call1.Content"
52 >MediaDescription</tp:dbus-ref> will pop up with {<tp:dbus-ref
53 namespace="ofdT.Call1.Content.MediaDescription"
54 >HasRemoteInformation</tp:dbus-ref> = false, <tp:dbus-ref
55 namespace="ofdT.Call1.Content.MediaDescription"
56 >FurtherNegotiationRequired</tp:dbus-ref> = true}, and the local
57 user's streaming implementation SHOULD call
58 <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
59 >Accept</tp:dbus-ref>,
60 with a description of all supported codecs and other features.
61 The CM will then send this information to the remote side (and
62 <tp:member-ref>LocalMediaDescriptionChanged</tp:member-ref> will fire
63 with details of the description passed into <tp:dbus-ref
64 namespace="ofdT.Call1.Content.MediaDescription"
65 >Accept</tp:dbus-ref> for debugging purposes).
66 </p>
67 <p>When the remote codecs and other content information are available
68 (e.g. Remote user replies to initial offer, or sends a new offer of
69 their own, a new <tp:dbus-ref namespace="ofdT.Call1.Content"
70 >MediaDescription</tp:dbus-ref> will appear, with {<tp:dbus-ref
71 namespace="ofdT.Call1.Content.MediaDescription"
72 >HasRemoteInformation</tp:dbus-ref> = true, <tp:dbus-ref
73 namespace="ofdT.Call1.Content.MediaDescription"
74 >FurtherNegotiationRequired</tp:dbus-ref> = false},
75 and the <tp:dbus-ref
76 namespace="ofdT.Call1.Content.MediaDescription"
77 >Codecs</tp:dbus-ref>
78 property on the description offer set to the codecs which are
79 supported by the remote contact. The local user's streaming
80 implementation SHOULD then call Accept, with a description
81 that is compatible with the one one in the offer. After the codec
82 set is accepted, both
83 <tp:member-ref>LocalMediaDescriptionChanged</tp:member-ref> and
84 <tp:member-ref>RemoteMediaDescriptionsChanged</tp:member-ref>
85 will fire to signal their respective changes, to aid with debugging.
86 Note that if <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
87 >Accept</tp:dbus-ref> is called, with <tp:dbus-ref
88 namespace="ofdT.Call1.Content.MediaDescription"
89 >FurtherNegotiationRequired</tp:dbus-ref> set to false,
90 the CM should be able to rely on the fact that the
91 description passed into Accept is compatible with the one in the
92 offer, and the description passed into Accept will not be signalled to
93 the remote side.
94 </p>
95
96 <h4>Changing codecs mid-call</h4>
97
98 <p>To update the codecs in the local (and optionally remote) media
99 descriptions mid-call, the
100 <tp:member-ref>UpdateLocalMediaDescription</tp:member-ref> method
101 should be called with details of the new codec list. If this is
102 accepted, then
103 <tp:member-ref>LocalMediaDescriptionChanged</tp:member-ref>
104 will be emitted with the new codec set.
105 </p>
106 <p> If parameters requiring negotiation are changed, then the
67107 <tp:dbus-ref
68 namespace="ofdT.Call.Content">CodecOffer.DRAFT.Accept</tp:dbus-ref>
69 on the intersection of these two codec lists.</p>
70
71 <p>This means that in practice, outgoing calls will have a codec
72 offer pop up with no information in the <tp:dbus-ref
73 namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecs</tp:dbus-ref>,
74 so the local user will call <tp:dbus-ref
75 namespace="ofdT.Call.Content.CodecOffer.DRAFT">Accept</tp:dbus-ref>
76 with the list of all codecs supported. If this codec offer is
77 accepted, then <tp:member-ref>CodecsChanged</tp:member-ref>
78 will fire with the details of the codecs passed into
79 <tp:dbus-ref
80 namespace="ofdT.Call.Content.CodecOffer.DRAFT">Accept</tp:dbus-ref>. If
81 the call is incoming, then the <tp:dbus-ref
82 namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecs</tp:dbus-ref>
83 will contain details of the remote contact's codecs and the
84 local user will call <tp:dbus-ref
85 namespace="ofdT.Call.Content.CodecOffer.DRAFT">Accept</tp:dbus-ref>
86 with the codecs that both sides understand. After the codec
87 set is accepted, <tp:member-ref>CodecsChanged</tp:member-ref>
88 will fire to signal this change.</p>
89
90 <h4>Protocols without codec negotiation</h4>
91
92 <p>For protocols where the codecs are not negotiable, instead of
93 popping up the initial content's <tp:dbus-ref
94 namespace="ofdT.Call.Content">CodecOffer.DRAFT</tp:dbus-ref>
95 object with an empty <tp:dbus-ref
96 namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecs</tp:dbus-ref>,
97 the CM should set the supported codec values to known codec
98 values in the said object's codec map.</p>
99
100 <h4>Changing codecs mid-call</h4>
101
102 <p>To update the codec list used mid-call, the
103 <tp:member-ref>UpdateCodecs</tp:member-ref> method should be
104 called with details of the new codec list. If this is
105 accepted, then <tp:member-ref>CodecsChanged</tp:member-ref>
106 will be emitted with the new codec set.</p>
108 namespace="ofdT.Call1.Content.MediaDescription"
109 >FurtherNegotiationRequired</tp:dbus-ref> property should be set to
110 TRUE, and the new media description should
111 only be used once they come in a new MediaDescriptionOffer
112 </p>
107113
108114 <p>If the other side decides to update his or her codec list
109115 during a call, a new <tp:dbus-ref
110 namespace="ofdT.Call.Content">CodecOffer.DRAFT</tp:dbus-ref>
116 namespace="ofdT.Call1.Content">MediaDescription</tp:dbus-ref>
111117 object will appear through
112 <tp:member-ref>NewCodecOffer</tp:member-ref> which should be
118 <tp:member-ref>NewMediaDescriptionOffer</tp:member-ref> which should be
113119 acted on as documented above.</p>
114120
121 <h4>Protocols without negotiation</h4>
122
123 <p>For protocols where the codecs are not negotiable, the initial content's <tp:dbus-ref
124 namespace="ofdT.Call1.Content">MediaDescription</tp:dbus-ref>
125 object will appear with <tp:dbus-ref
126 namespace="ofdT.Call1.Content.MediaDescription"
127 >HasRemoteInformation</tp:dbus-ref>,
128 set to true and the known supported codec values in <tp:dbus-ref
129 namespace="ofdT.Call1.Content.MediaDescription"
130 >Codecs</tp:dbus-ref>.
131 </p>
115132 </tp:docstring>
116133
117134 <tp:struct name="Codec" array-name="Codec_List">
139156 Number of channels of the codec if applicable, otherwise 0.
140157 </tp:docstring>
141158 </tp:member>
159 <tp:member name="Updated" type="b">
160 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
161 This should be set to true in calls to <tp:dbus-ref
162 namespace="ofdT.Call1.Content.MediaDescription"
163 >Accept</tp:dbus-ref> and
164 <tp:member-ref>UpdateLocalMediaDescription</tp:member-ref> if this
165 codec has changed in a way that needs to be signalled over the
166 network. If it is set to false, the CM is allowed ignore any
167 differences between the current parameters and the previous ones
168 <tp:rationale>
169 This mechanism may be used to save bandwidth and avoid the CM
170 having to calculate diffs against previous versions of this
171 struct, which can lead to false-positives (e.g. redundant ptime
172 updates).
173 </tp:rationale>
174 </tp:docstring>
175 </tp:member>
142176 <tp:member name="Parameters" type="a{ss}" tp:type="String_String_Map">
143177 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
144178 Extra parameters for this codec.
155189 A contact handle.
156190 </tp:docstring>
157191 </tp:member>
158 <tp:member name="Codecs" type="a(usuua{ss})" tp:type="Codec[]">
192 <tp:member name="Codecs" type="a(usuuba{ss})" tp:type="Codec[]">
159193 <tp:docstring>
160194 The codecs that the contact supports.
161195 </tp:docstring>
162196 </tp:member>
163197 </tp:mapping>
164198
165 <tp:struct name="Codec_Offering">
166 <tp:docstring>
167 A codec offer and its corresponding remote contact codec map.
168 </tp:docstring>
169 <tp:member name="Codec_Offer" type="o">
170 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
171 The object path to the <tp:dbus-ref namespace="ofdT.Call.Content"
172 >CodecOffer.DRAFT</tp:dbus-ref>
199 <tp:mapping name="Contact_Media_Description_Properties_Map">
200 <tp:member name="Remote_Contact" type="u" tp:type="Handle">
201 <tp:docstring>
202 The remote contact this description refers to or 0. This matches the
203 <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
204 >RemoteContact</tp:dbus-ref> property on
205 <tp:dbus-ref namespace="ofdT.Call1.Content"
206 >MediaDescription</tp:dbus-ref>
207 </tp:docstring>
208 </tp:member>
209 <tp:member name="Media_Description_Properties" type="a{sv}"
210 tp:type="Media_Description_Properties">
211 <tp:docstring>
212 The properties of the description
213 </tp:docstring>
214 </tp:member>
215 </tp:mapping>
216
217 <tp:struct name="Media_Description_Offer">
218 <tp:docstring>
219 The remote description offer and its information
220 </tp:docstring>
221 <tp:member name="Media_Description" type="o">
222 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
223 The object path to the <tp:dbus-ref namespace="ofdT.Call1.Content"
224 >MediaDescription</tp:dbus-ref>
173225 </tp:docstring>
174226 </tp:member>
175227 <tp:member name="Remote_Contact" type="u" tp:type="Contact_Handle">
176228 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
177 The contact handle that this codec offer applies to.
178 </tp:docstring>
179 </tp:member>
180 <tp:member name="Remote_Contact_Codecs" type="a(usuua{ss})"
181 tp:type="Codec[]">
182 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
183 The <tp:dbus-ref namespace="ofdT.Call.Content"
184 >CodecOffer.DRAFT.RemoteContactCodecs</tp:dbus-ref> property
185 of the codec offer.
229 The contact handle that this description applies to.
230 </tp:docstring>
231 </tp:member>
232 <tp:member name="Properties" type="a{sv}"
233 tp:type="Media_Description_Properties">
234 <tp:docstring>
235 The immutable properties of all interfaces of the codec description.
236
237 <tp:rationale>
238 Having all the codec description properties here saves a D-Bus
239 round-trip - it shouldn't be necessary to get the properties from the
240 MediaDescription object, in practice.
241 </tp:rationale>
186242 </tp:docstring>
187243 </tp:member>
188244 </tp:struct>
189245
190 <signal name="CodecsChanged" tp:name-for-bindings="Codecs_Changed">
191 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
192 <p>Emitted when the codecs in use change.</p>
193
194 <p>As well as acting as change notification for the
195 <tp:member-ref>ContactCodecMap</tp:member-ref>, emission of this
196 signal implies that the <tp:member-ref>CodecOffer</tp:member-ref>
197 property has changed to <code>('/', {})</code>.</p>
198 </tp:docstring>
199 <arg name="Updated_Codecs" type="a{ua(usuua{ss})}"
200 tp:type="Contact_Codec_Map">
201 <tp:docstring>
202 A map from contact to his or her codecs. Each pair in this
203 map is added to the
204 <tp:member-ref>ContactCodecMap</tp:member-ref> property,
205 replacing any previous pair with that key.
206 </tp:docstring>
207 </arg>
208 <arg name="Removed_Contacts" type="au" tp:type="Contact_Handle[]">
209 <tp:docstring>
210 A list of keys which were removed from the
211 <tp:member-ref>ContactCodecMap</tp:member-ref>, probably because
212 those contacts left the call.
213 </tp:docstring>
214 </arg>
215 </signal>
216
217 <method name="UpdateCodecs" tp:name-for-bindings="Update_Codecs">
218 <tp:docstring>
219 Update the local codec mapping. This method should only be
220 used during an existing call to update the codec mapping.
221 </tp:docstring>
222 <arg name="Codecs" direction="in"
223 type="a(usuua{ss})" tp:type="Codec[]">
224 <tp:docstring>
225 The codecs now supported by the local user.
246 <method name="UpdateLocalMediaDescription"
247 tp:name-for-bindings="Update_Local_Media_Description">
248 <tp:docstring>
249 Update the local codec mapping and other interfaces of the
250 MediaDescription. This method should only be
251 used during an existing call to update the local media description.
252 This may trigger a re-negotiation which may result in new
253 new MediaDescriptionOffers if the "FurtherNegotiationRequired"
254 property is TRUE.
255 Otherwise, only parameters which strictly describe the media being sent
256 can be changed.
257 </tp:docstring>
258 <arg name="Remote_Contact" type="u" tp:type="Handle" direction="in">
259 <tp:docstring>
260 The remote contact that this description should be negotiated with
261 (or 0 to mean "negotiate this with everyone"). Note that encoding
262 the same video multiple times is often needlessly expensive, so
263 differences in MediaDescriptions negotiated with different parties
264 in the call should be limited to payloading parameters if possible.
265 </tp:docstring>
266 </arg>
267 <arg name="MediaDescription" direction="in" type="a{sv}"
268 tp:type="Media_Description_Properties">
269 <tp:docstring>
270 The updated media description that the local side wants to use.
226271 </tp:docstring>
227272 </arg>
228273 <tp:possible-errors>
229 <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
274 <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
230275 <tp:docstring>
231 Raised when a <tp:dbus-ref
232 namespace="ofdT.Call.Content">CodecOffer.DRAFT</tp:dbus-ref>
233 object exists and is referred to in the
234 <tp:member-ref>CodecOffer</tp:member-ref> property which
235 should be used instead of calling this method, or before
236 the content's initial <tp:dbus-ref
237 namespace="ofdT.Call.Content">CodecOffer.DRAFT</tp:dbus-ref>
238 object has appeared.
276 The protocol does not support changing the codecs mid-call.
239277 </tp:docstring>
240278 </tp:error>
241 </tp:possible-errors>
279 <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
280 <tp:docstring>
281 The description given is invalid in some way.
282 </tp:docstring>
283 </tp:error>
284 </tp:possible-errors>
242285 </method>
243286
244 <property name="ContactCodecMap" tp:name-for-bindings="Contact_Codec_Map"
245 type="a{ua(usuua{ss})}" tp:type="Contact_Codec_Map" access="read">
246 <tp:docstring>
247 <p>A map from contact handles (including the local user's own handle)
248 to the codecs supported by that contact.</p>
287 <property name="RemoteMediaDescriptions"
288 tp:name-for-bindings="Remote_Media_Descriptions"
289 type="a{ua{sv}}"
290 tp:type="Contact_Media_Description_Properties_Map" access="read">
291 <tp:docstring>
292 <p>A map from contact handles to descriptions supported by that
293 contact.</p>
294
295 <p>Keys of this map will appear in at most one <tp:dbus-ref
296 namespace="ofdT.Call1.Stream">RemoteMembers</tp:dbus-ref>.
297 See <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
298 >RemoteContact</tp:dbus-ref> for more details on how to map between
299 MediaDescriptions and Streams.</p>
300 </tp:docstring>
301 </property>
302
303 <property name="LocalMediaDescriptions"
304 tp:name-for-bindings="Local_Media_Descriptions"
305 type="a{ua{sv}}"
306 tp:type="Contact_Media_Description_Properties_Map" access="read">
307 <tp:docstring>
308 <p>A map from contact handles to the descriptions the local side
309 responsed with.</p> </tp:docstring>
310 </property>
311
312 <signal name="NewMediaDescriptionOffer"
313 tp:name-for-bindings="New_Media_Description_Offer">
314 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
315 <p>Emitted when a new <tp:dbus-ref namespace="ofdT.Call1.Content"
316 >MediaDescription</tp:dbus-ref> appears. The streaming
317 >implementation MUST respond by calling the
318 <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
319 >Accept</tp:dbus-ref> or <tp:dbus-ref
320 namespace="ofdT.Call1.Content.MediaDescription"
321 >Reject</tp:dbus-ref> method on the description object appeared.</p>
322
323 <p>Emission of this signal indicates that the
324 <tp:member-ref>MediaDescriptionOffer</tp:member-ref> property has
325 changed to
326 <code>(Description, Contact, MediaDescriptionProperties)</code>.</p>
327
328 <p>When the MediaDescriptionOffer has been dealt with then
329 <tp:dbus-ref namespace="ofdT.Call1.Content.Interface.Media"
330 >MediaDescriptionOfferDone</tp:dbus-ref> must be emitted
331 before <tp:dbus-ref
332 namespace="ofdT.Call1.Content.Interface.Media"
333 >NewMediaDescriptionOffer</tp:dbus-ref> is emitted again.
334 </p>
335
336 </tp:docstring>
337 <arg name="Media_Description" type="o">
338 <tp:docstring>
339 The object path of the new media description. This replaces any
340 previous media description.
341 </tp:docstring>
342 </arg>
343 <arg name="Contact" type="u">
344 <tp:docstring>
345 The remote contact the media description belongs to.
346 </tp:docstring>
347 </arg>
348 <arg name="Properties" type="a{sv}"
349 tp:type="Media_Description_Properties">
350 <tp:docstring>
351 The immutable properties of the remote media description.
352
353 <tp:rationale>
354 Having all the MediaDescription properties here saves a D-Bus
355 round-trip - it shouldn't be necessary to get the properties from the
356 MediaDescription object, in practice.
357 </tp:rationale>
358 </tp:docstring>
359 </arg>
360 </signal>
361
362 <signal name="MediaDescriptionOfferDone"
363 tp:name-for-bindings="Media_Description_Offer_Done">
364 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
365 <p>Emitted when a <tp:dbus-ref namespace="ofdT.Call1.Content"
366 >MediaDescription</tp:dbus-ref> has been handled. </p>
367 <p>Emission of this signal indicates that the
368 <tp:member-ref>MediaDescriptionOffer</tp:member-ref> property has
369 changed to
370 <code>("/", 0, {})</code>.</p>
371 </tp:docstring>
372 </signal>
373
374
375 <signal name="LocalMediaDescriptionChanged"
376 tp:name-for-bindings="Local_Media_Description_Changed">
377
378 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
379 <p>Change notification for
380 <tp:dbus-ref namespace="ofdT.Call1.Content.Interface.Media"
381 >LocalMediaDescriptions</tp:dbus-ref>
382 </p>
383 </tp:docstring>
384
385 <arg name="Remote_Contact" type="u" tp:type="Handle">
386 <tp:docstring>
387 The remote contact that this description was negotiated with
388 (or 0 to mean "negotiated with everyone").
389 </tp:docstring>
390 </arg>
391
392 <arg name="Updated_Media_Description" type="a{sv}"
393 tp:type="Media_Description_Properties">
394 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
395 <p>The local content description that was updated</p>
396 </tp:docstring>
397 </arg>
398 </signal>
399
400 <signal name="RemoteMediaDescriptionsChanged"
401 tp:name-for-bindings="Remote_Media_Descriptions_Changed">
402
403 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
404 <p>Change notification for
405 <tp:dbus-ref namespace="ofdT.Call1.Content.Interface.Media"
406 >RemoteMediaDescriptions</tp:dbus-ref>
407 </p>
408 </tp:docstring>
409
410 <arg name="Updated_Media_Descriptions" type="a{ua{sv}}"
411 tp:type="Contact_Media_Description_Properties_Map">
412 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
413 <p>The remote content descriptions that were updated</p>
414 </tp:docstring>
415 </arg>
416 </signal>
417
418 <signal name="MediaDescriptionsRemoved"
419 tp:name-for-bindings="Media_Descriptions_Removed">
420
421 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
422 <p>Removal notification for
423 <tp:dbus-ref namespace="ofdT.Call1.Content.Interface.Media"
424 >RemoteMediaDescriptions</tp:dbus-ref>
425 and
426 <tp:dbus-ref namespace="ofdT.Call1.Content.Interface.Media"
427 >LocalMediaDescriptions</tp:dbus-ref>
428 </p>
429 </tp:docstring>
430
431 <arg name="Removed_Media_Descriptions" type="au"
432 tp:type="Contact_Handle[]">
433 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
434 <p>The local and remote content descriptions that are no longer part
435 of this content</p>
436 </tp:docstring>
437 </arg>
438 </signal>
439
440 <property name="MediaDescriptionOffer"
441 tp:name-for-bindings="Media_Description_Offer"
442 type="(oua{sv})" tp:type="Media_Description_Offer" access="read">
443 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
444 <p>The object path to the current
445 <tp:dbus-ref namespace="ofdT.Call1.Content"
446 >MediaDescription</tp:dbus-ref> object, its
447 <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
448 >RemoteContact</tp:dbus-ref> and
449 a mapping of the MediaDescriptions properties.
450 If the object path is "/" then there isn't an outstanding
451 content description, and the mapping MUST be empty.</p>
452
453 <tp:rationale>
454 Having all <tp:dbus-ref
455 namespace="ofdT.Call1.Content">MediaDescription</tp:dbus-ref>
456 properties here saves a D-Bus round-trip - it shouldn't be
457 necessary to get these properties from the Content MediaDescription
458 object, in practice.
459 </tp:rationale>
249460
250461 <p>Change notification is via the
251 <tp:member-ref>CodecsChanged</tp:member-ref> signal.</p>
252 </tp:docstring>
253 </property>
254
255 <signal name="NewCodecOffer" tp:name-for-bindings="New_Codec_Offer">
256 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
257 <p>Emitted when a new <tp:dbus-ref namespace="ofdT.Call.Content"
258 >CodecOffer.DRAFT</tp:dbus-ref> appears. The streaming
259 implementation MUST respond by calling the <tp:dbus-ref
260 namespace="ofdT.Call.Content.CodecOffer.DRAFT"
261 >Accept</tp:dbus-ref> or <tp:dbus-ref
262 namespace="ofdT.Call.Content.CodecOffer.DRAFT"
263 >Reject</tp:dbus-ref> method on the codec offer object.</p>
264
265 <p>Emission of this signal indicates that the
266 <tp:member-ref>CodecOffer</tp:member-ref> property has changed to
267 <code>(Contact, Offer, Codecs)</code>.</p>
268 </tp:docstring>
269 <arg name="Contact" type="u">
270 <tp:docstring>
271 The contact the codec offer belongs to.
272 </tp:docstring>
273 </arg>
274 <arg name="Offer" type="o">
275 <tp:docstring>
276 The object path of the new codec offer. This replaces any previous
277 codec offer.
278 </tp:docstring>
279 </arg>
280 <arg name="Codecs" type="a(usuua{ss})" tp:type="Codec[]">
281 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
282 <p>The <tp:dbus-ref namespace="ofdT.Call.Content"
283 >CodecOffer.DRAFT.RemoteContactCodecs</tp:dbus-ref> property
284 of the codec offer.</p>
285
286 <tp:rationale>
287 Having the <tp:dbus-ref
288 namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecs</tp:dbus-ref>
289 property here saves a D-Bus round-trip - it shouldn't be
290 necessary to get the property from the CodecOffer object, in
291 practice.
292 </tp:rationale>
293 </tp:docstring>
294 </arg>
295 </signal>
296
297 <property name="CodecOffer" tp:name-for-bindings="Codec_Offer"
298 type="(oua(usuua{ss}))" tp:type="Codec_Offering" access="read">
299 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
300 <p>The object path to the current
301 <tp:dbus-ref namespace="ofdT.Call.Content"
302 >CodecOffer.DRAFT</tp:dbus-ref> object, its
303 <tp:dbus-ref namespace="ofdT.Call.Content"
304 >CodecOffer.DRAFT.RemoteContact</tp:dbus-ref> and
305 <tp:dbus-ref namespace="ofdT.Call.Content"
306 >CodecOffer.DRAFT.RemoteContactCodecs</tp:dbus-ref> properties.
307 If the object path is "/" then there isn't an outstanding
308 codec offer, and the mapping MUST be empty.</p>
309
310 <tp:rationale>
311 Having the <tp:dbus-ref
312 namespace="ofdT.Call.Content.CodecOffer.DRAFT"
313 >RemoteContact</tp:dbus-ref> and
314 <tp:dbus-ref namespace="ofdT.Call.Content.CodecOffer.DRAFT"
315 >RemoteContactCodecs</tp:dbus-ref>
316 properties here saves a D-Bus round-trip - it shouldn't be
317 necessary to get these properties from the CodecOffer object, in
318 practice.
319 </tp:rationale>
320
321 <p>Change notification is via the
322 <tp:member-ref>NewCodecOffer</tp:member-ref> (which replaces the
323 value of this property with a new codec offer), and
324 <tp:member-ref>CodecsChanged</tp:member-ref> (which implies that
325 there is no longer any active codec offer) signals.</p>
462 <tp:member-ref>NewMediaDescriptionOffer</tp:member-ref> and
463 <tp:member-ref>MediaDescriptionOfferDone</tp:member-ref> signals.
464 </p>
326465 </tp:docstring>
327466 </property>
328467
361500 <p>The packetization method in use for this content.</p>
362501 </tp:docstring>
363502 </property>
503
504 <signal name="DTMFChangeRequested"
505 tp:name-for-bindings="DTMF_Change_Requested">
506 <tp:docstring>
507 Used by the CM to relay instructions from <tp:dbus-ref
508 namespace="ofdT">Channel.Interface.DTMF</tp:dbus-ref> to the streaming
509 implementation. If any contact in this call supports the
510 telephone-event codec in their MediaDescription, this event should be
511 sent as outlined in RFC 4733. Otherwise, it should be sent as an
512 audible tone.
513 </tp:docstring>
514 <arg name="Event" type="y" tp:type="DTMF_Event">
515 <tp:docstring>
516 The event to send (or stop sending).
517 </tp:docstring>
518 </arg>
519 <arg name="State" type="u" tp:type="Sending_State">
520 <tp:docstring>
521 Either <tp:value-ref type="Sending_State">Pending_Send</tp:value-ref> or
522 <tp:value-ref type="Sending_State">Pending_Stop_Sending</tp:value-ref>.
523 </tp:docstring>
524 </arg>
525 </signal>
526
527 <method name="AcknowledgeDTMFChange"
528 tp:name-for-bindings="Acknowledge_DTMF_Change">
529 <tp:docstring>
530 Called by the streaming implementation in response to
531 <tp:member-ref>DTMFChangeRequested</tp:member-ref> to confirm that it
532 has started or stopped sending the event in question.
533 </tp:docstring>
534 <arg name="Event" type="y" tp:type="DTMF_Event" direction="in">
535 <tp:docstring>
536 The event referred to in the corresponding
537 <tp:member-ref>DTMFChangeRequested</tp:member-ref> signal.
538 </tp:docstring>
539 </arg>
540 <arg name="State" type="u" tp:type="Sending_State" direction="in">
541 <tp:docstring>
542 Either <tp:value-ref type="Sending_State">Sending</tp:value-ref> or
543 <tp:value-ref type="Sending_State">None</tp:value-ref>.
544 </tp:docstring>
545 </arg>
546 </method>
547
548 <property name="CurrentDTMFEvent"
549 tp:name-for-bindings="Current_DTMF_Event" type="y" tp:type="DTMF_Event"
550 access="read">
551 <tp:docstring>
552 The currently requested DTMF event (for state-recoverability of
553 <tp:member-ref>DTMFChangeRequested</tp:member-ref>). Should be ignored
554 if <tp:member-ref>CurrentDTMFState</tp:member-ref> is None.
555 </tp:docstring>
556 </property>
557
558 <property name="CurrentDTMFState"
559 tp:name-for-bindings="Current_DTMF_State" type="u" tp:type="Sending_State"
560 access="read">
561 <tp:docstring>
562 The current DTMF state (for state-recoverability of
563 <tp:member-ref>DTMFChangeRequested</tp:member-ref>).
564 </tp:docstring>
565 </property>
566
567 <method name="Fail" tp:name-for-bindings="Fail">
568 <tp:docstring>
569 Signal an unrecoverable error for this content, and remove it.
570 </tp:docstring>
571 <arg direction="in" name="Reason" type="(uuss)"
572 tp:type="Call_State_Reason">
573 <tp:docstring>
574 A reason struct describing the error.
575 </tp:docstring>
576 </arg>
577 </method>
364578 </interface>
365579 </node>
366580 <!-- vim:set sw=2 sts=2 et ft=xml: -->
+0
-85
spec/Call_Content_Interface_Mute.xml less more
0 <?xml version="1.0" ?>
1 <node name="/Call_Content_Interface_Mute" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
2 <tp:copyright> Copyright © 2005-2010 Nokia Corporation </tp:copyright>
3 <tp:copyright> Copyright © 2005-2010 Collabora Ltd </tp:copyright>
4 <tp:license xmlns="http://www.w3.org/1999/xhtml">
5 This library is free software; you can redistribute it and/or
6 modify it under the terms of the GNU Lesser General Public
7 License as published by the Free Software Foundation; either
8 version 2.1 of the License, or (at your option) any later version.
9
10 This library is distributed in the hope that it will be useful,
11 but WITHOUT ANY WARRANTY; without even the implied warranty of
12 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
13 Lesser General Public License for more details.
14
15 You should have received a copy of the GNU Lesser General Public
16 License along with this library; if not, write to the Free Software
17 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
18 </tp:license>
19
20 <interface name="org.freedesktop.Telepathy.Call.Content.Interface.Mute.DRAFT" tp:causes-havoc="experimental">
21 <tp:added version="0.19.6">(draft version, not API-stable)</tp:added>
22 <tp:requires interface="org.freedesktop.Telepathy.Call.Content.DRAFT"/>
23
24 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
25 <p>Interface for calls which may be muted. This only makes sense
26 for channels where audio or video is streaming between members.</p>
27
28 <p>Muting a call content indicates that the user does not wish to send
29 outgoing audio or video.</p>
30
31 <p>Although it's client's responsibility to actually mute the microphone
32 or turn off the camera, using this interface the client can also
33 inform the CM and other clients of that fact.</p>
34
35 <tp:rationale>
36 For some protocols, the fact that the content is muted needs
37 to be transmitted to the peer; for others, the notification
38 to the peer is only informational (eg. XMPP), and some
39 protocols may have no notion of muting at all.
40 </tp:rationale>
41 </tp:docstring>
42
43 <signal name="MuteStateChanged" tp:name-for-bindings="Mute_State_Changed">
44 <tp:docstring>
45 Emitted to indicate that the mute state has changed for this call content.
46 This may occur as a consequence of the client calling
47 <tp:member-ref>SetMuted</tp:member-ref>, or as an indication that another
48 client has (un)muted the content.
49 </tp:docstring>
50 <arg name="MuteState" type="b">
51 <tp:docstring>
52 True if the content is now muted.
53 </tp:docstring>
54 </arg>
55 </signal>
56
57 <property name="MuteState" type="b"
58 access="read" tp:name-for-bindings="Mute_State">
59 <tp:docstring>
60 True if the content is muted.
61 </tp:docstring>
62 </property>
63
64 <method name="SetMuted" tp:name-for-bindings="Set_Muted">
65 <tp:changed version="0.21.2">renamed from SetMuted to Mute</tp:changed>
66 <tp:changed version="0.21.3">renamed back from Mute to SetMuted</tp:changed>
67 <arg direction="in" name="Muted" type="b">
68 <tp:docstring>
69 True if the client has muted the content.
70 </tp:docstring>
71 </arg>
72 <tp:docstring>
73 <p>Inform the CM that the call content has been muted or unmuted by
74 the client.</p>
75
76 <p>It is the client's responsibility to actually mute or unmute the
77 microphone or camera used for the content. However, the client
78 MUST call this whenever it mutes or unmutes the content.</p>
79 </tp:docstring>
80 </method>
81
82 </interface>
83 </node>
84 <!-- vim:set sw=2 sts=2 et ft=xml: -->
+2
-2
spec/Call_Content_Interface_Video_Control.xml less more
1919 02110-1301, USA.</p>
2020 </tp:license>
2121
22 <interface name="org.freedesktop.Telepathy.Call.Content.Interface.VideoControl.DRAFT"
22 <interface name="org.freedesktop.Telepathy.Call1.Content.Interface.VideoControl"
2323 tp:causes-havoc="experimental">
2424 <tp:added version="0.21.10">(draft 1)</tp:added>
25 <tp:requires interface="org.freedesktop.Telepathy.Call.Content.Interface.Media.DRAFT"/>
25 <tp:requires interface="org.freedesktop.Telepathy.Call1.Content.Interface.Media"/>
2626
2727 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
2828 <p>An interface that allows the connection manager to control the video
+236
-0
spec/Call_Content_Media_Description.xml less more
0 <?xml version="1.0" ?>
1 <node name="/Call_Content_Media_Description"
2 xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
3 <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
4 <tp:copyright>Copyright © 2009-2010 Nokia Corporation</tp:copyright>
5 <tp:license xmlns="http://www.w3.org/1999/xhtml">
6 <p>This library is free software; you can redistribute it and/or
7 modify it under the terms of the GNU Lesser General Public
8 License as published by the Free Software Foundation; either
9 version 2.1 of the License, or (at your option) any later version.</p>
10
11 <p>This library is distributed in the hope that it will be useful,
12 but WITHOUT ANY WARRANTY; without even the implied warranty of
13 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
14 Lesser General Public License for more details.</p>
15
16 <p>You should have received a copy of the GNU Lesser General Public
17 License along with this library; if not, write to the Free Software
18 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
19 02110-1301, USA.</p>
20 </tp:license>
21
22 <interface name="org.freedesktop.Telepathy.Call1.Content.MediaDescription"
23 tp:causes-havoc="experimental">
24 <tp:added version="0.23.4">(draft 1)</tp:added>
25
26 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
27 This object represents a remote Description Offer to which the local
28 streaming implementation should reply with its local Description.
29
30 This is intended as a temporary transactional object for use with <tp:dbus-ref
31 namespace="ofdT.Call1">Content.Interface.Media</tp:dbus-ref>.
32 There will always be 0 or 1 MediaDescription object per Content.
33 In most cases, this object will stay alive until you call either
34 <tp:member-ref>Accept</tp:member-ref> or
35 <tp:member-ref>Reject</tp:member-ref>, and then disappear.
36 There are some cases (e.g. an endpoint being removed from the call)
37 where a MediaDescription object will disappear before you have had a
38 chance to either Accept or Reject it.
39 </tp:docstring>
40
41 <method name="Accept" tp:name-for-bindings="Accept">
42 <arg name="Local_Media_Description" direction="in"
43 type="a{sv}" tp:type="Media_Description_Properties">
44 <tp:docstring>
45 The local description to send to the remote contacts and
46 to use in the <tp:dbus-ref
47 namespace="ofdT.Call1">Content</tp:dbus-ref>.
48 </tp:docstring>
49 </arg>
50 <tp:docstring>
51 Accepts the updated Description and update the corresponding
52 local description. If FurtherNegotiationRequired is True,
53 calling this method will generally cause a network round-trip
54 and a new MediaDescription to be offered (hopefully with
55 FurtherNegotiationRequired set to False).
56 </tp:docstring>
57 <tp:possible-errors>
58 <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
59 <tp:docstring>
60 The description given is invalid in some way.
61 </tp:docstring>
62 </tp:error>
63 </tp:possible-errors>
64 </method>
65
66 <method name="Reject" tp:name-for-bindings="Reject">
67 <tp:docstring>
68 Reject the proposed update to the remote description.
69 </tp:docstring>
70 <arg name="Reason" type="(uuss)" tp:type="Call_State_Reason"
71 direction="out">
72 <tp:docstring>
73 A structured reason for the rejection.
74 </tp:docstring>
75 </arg>
76 </method>
77
78 <property name="Interfaces" tp:name-for-bindings="Interfaces"
79 type="as" tp:type="DBus_Interface[]" access="read" tp:immutable="yes">
80 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
81 <p>Extra interfaces provided by this media description. This SHOULD
82 NOT include the Description interface itself.</p>
83 </tp:docstring>
84 </property>
85
86 <property name="FurtherNegotiationRequired"
87 tp:name-for-bindings="Further_Negotiation_Required" type="b"
88 access="read" tp:immutable="yes">
89 <tp:docstring xmlns="http://www.w3.org/1999/xhtml" >
90 <p> If this is set to True by the CM in a MediaDescriptionOffer, it
91 means "This is an offer under the SDP Offer/Answer model. Whatever
92 you accept this offer with is what I will send to the other side in
93 my answer."
94
95 If this is set to False by the CM then it means "This is an Answer
96 under the SDP Offer/Answer model, and if it remains False in the
97 Accept(), no further codec negotiation needs to happen."
98
99 If this is set to True by the streaming implementation (e.g. in an
100 Accept or UpdateLocalMediaDescription call) then a new SDP
101 Offer/Answer round-trip will be initiated.
102 </p>
103 </tp:docstring>
104 </property>
105
106 <property name="HasRemoteInformation"
107 tp:name-for-bindings="Has_Remote_Information" type="b"
108 access="read" tp:immutable="yes">
109 <tp:docstring xmlns="http://www.w3.org/1999/xhtml" >
110 <p> True if this offer contains information from the remote side:
111 If False then the Accept response solely depends on the
112 capabilities and preferences of the local side.
113
114 In most protocols this property will be False for the initial
115 DescriptionOffer on an outgoing call.
116 </p>
117 </tp:docstring>
118 </property>
119
120 <property name="Codecs"
121 tp:name-for-bindings="Codecs"
122 type="a(usuuba{ss})" tp:type="Codec[]" access="read"
123 tp:immutable="yes">
124 <tp:docstring>
125 A list of codecs the remote contact supports. When used with
126 <tp:member-ref>Accept</tp:member-ref>, it means the locally supported
127 codecs.
128 </tp:docstring>
129 </property>
130
131 <property name="RemoteContact" tp:name-for-bindings="Remote_Contact"
132 type="u" tp:type="Contact_Handle" access="read" tp:immutable="yes">
133 <tp:docstring>
134 The contact handle that this description applies to.
135
136 This property can be used as an opaque identifier, and searched for in
137 <tp:dbus-ref namespace="ofdT.Call1.Stream"
138 >RemoteMembers</tp:dbus-ref> for each Stream in this Content, to
139 determine which Stream this MediaDescription applies to. If multiple
140 MediaDescriptions apply to the same Stream, the
141 <tp:member-ref>SSRCs</tp:member-ref> property should be used to
142 separate media before decoding.
143
144 If this property is 0, this MediaDescription applies to all streams,
145 so the above matching method is unneccesary (e.g. in conference calls
146 with a mixer, media from all participants is mixed into one stream).
147
148 When calling Accept or UpdateLocalMediaDescription, this should always
149 be set to 0, or omitted, because it is assumed that you send the same
150 MediaDescription to everyone (Encoding a stream separately for each
151 contact in a call is inefficient, and should be avoided).
152 </tp:docstring>
153 </property>
154
155 <tp:mapping name="Contact_SSRCs_Map">
156 <tp:member name="Contact" type="u" tp:type="Handle">
157 <tp:docstring>
158 The remote contact these SSRCs belong to or 0.
159 </tp:docstring>
160 </tp:member>
161 <tp:member name="SSRCs" type="au">
162 <tp:docstring>
163 The list of Synchronisation Sources.
164 </tp:docstring>
165 </tp:member>
166 </tp:mapping>
167
168 <property name="SSRCs" tp:name-for-bindings="SSRCs"
169 type="a{uau}" tp:type="Contact_SSRCs_Map" access="read" tp:immutable="yes">
170 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
171 <p>A map from Handle to list of Synchronisation Sources, as defined by
172 RFC 3550.</p>
173
174 <p>Some protocols require the negotiation of SSRC identifiers for RTP
175 streams. If this is the case, then MediaDescription offers will appear
176 with this property set. The streaming implementation should then call
177 <tp:member-ref>Accept</tp:member-ref> with a map from 0 to a
178 list containing a single SSRC (which does not collide with these,
179 or any previously seen SSRCs). If a new MediaDescription offer
180 appears with an SSRC the same as one in <tp:dbus-ref
181 namespace="ofdT.Call1.Content.Interface.Media"
182 >LocalMediaDescriptions</tp:dbus-ref>, then the streaming
183 implementation should pick a new SSRC to resolve the collision.</p>
184
185 <p>It is expected that this list will normally be at most one element long,
186 but it is kept as a list for extensibility. The concatenation of all
187 SSRCs associated with a Stream should contain no duplicate entries. If
188 there are collisions, then it is the responsibility of the protocol
189 implementation to resolve them and generate new offers.</p>
190
191 <p>If this property is omitted, then the streaming implementation can
192 assume that there is only one MediaDescription per Stream.</p>
193
194 <p>If there is a single multicast Call Stream with multiple
195 Remote Members, and all members are forced to use the same
196 MediaDescription, this map can be used by the streaming implementation
197 to determine which video sources belong to which contacts (e.g. in
198 order to put a name under each face in the call)</p>
199 </tp:docstring>
200 </property>
201
202 <tp:mapping name="Media_Description_Properties">
203 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
204 <p>
205 A mapping containing all properties that define the information from a
206 <tp:dbus-ref
207 namespace="ofdT.Call1.Content"
208 >MediaDescription</tp:dbus-ref> and its interfaces.
209 </p>
210
211 <p>
212 If <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
213 >HasRemoteInformation</tp:dbus-ref> is True, then this mapping
214 will always contains at least
215 <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
216 >Codecs</tp:dbus-ref>
217 </p>
218 </tp:docstring>
219
220 <tp:member name="Media_Description_Property"
221 type="s" tp:type="DBus_Qualified_Member">
222 <tp:docstring>
223 A D-Bus interface name, followed by a dot and a D-Bus property name.
224 </tp:docstring>
225 </tp:member>
226 <tp:member name="Media_Description_Property_Value" type="v">
227 <tp:docstring>
228 The value of the property
229 </tp:docstring>
230 </tp:member>
231 </tp:mapping>
232
233 </interface>
234 </node>
235 <!-- vim:set sw=2 sts=2 et ft=xml: -->
+145
-0
spec/Call_Content_Media_Description_Interface_RTCP_Extended_Reports.xml less more
0 <?xml version="1.0" ?>
1 <node name="/Call_Content_Media_Description_Interface_RTCP_Extended_Reports" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
2 <tp:copyright> Copyright © 2005-2010 Nokia Corporation </tp:copyright>
3 <tp:copyright> Copyright © 2005-2010 Collabora Ltd </tp:copyright>
4 <tp:license xmlns="http://www.w3.org/1999/xhtml">
5 This library is free software; you can redistribute it and/or
6 modify it under the terms of the GNU Lesser General Public
7 License as published by the Free Software Foundation; either
8 version 2.1 of the License, or (at your option) any later version.
9
10 This library is distributed in the hope that it will be useful,
11 but WITHOUT ANY WARRANTY; without even the implied warranty of
12 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
13 Lesser General Public License for more details.
14
15 You should have received a copy of the GNU Lesser General Public
16 License along with this library; if not, write to the Free Software
17 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
18 </tp:license>
19
20 <interface name="org.freedesktop.Telepathy.Call1.Content.MediaDescription.Interface.RTCPExtendedReports"
21 tp:causes-havoc="experimental">
22 <tp:added version="0.23.4">(draft version, not API-stable)</tp:added>
23 <tp:requires
24 interface="org.freedesktop.Telepathy.Call1.Content.MediaDescription"/>
25
26 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
27 <p>This codec offer interface provides a method of signalling for
28 RTCP extended reports, documented by <em>RTP Control Protocol
29 Extended Reports (RTCP XR)</em> (RFC 3611). CMs should ignore
30 all RTCP Extended Report parameters that are not listed
31 in this spec at the time of implementation. More parameters can be
32 added to the spec as required.</p>
33
34 <p>For more details on what RTCP extended reports can do and how
35 to use them, one should refer to
36 <a href="http://www.faqs.org/rfcs/rfc3611.html">RFC 3611</a>.</p>
37
38 </tp:docstring>
39
40 <property access="read" type="u" name="LossRLEMaxSize" tp:name-for-bindings="Loss_RLE_Max_Size">
41 <tp:docstring>
42 If non-zero, enable Loss Run Length Encoded Report Blocks. The value
43 of this integer represents the max-size of report blocks, as specified
44 in RFC 3611 section 5.1. MAXUINT32 is used to indicate that there is
45 no limit.
46 </tp:docstring>
47 </property>
48 <property access="read" type="u" name="DuplicateRLEMaxSize" tp:name-for-bindings="Duplicate_RLE_Max_Size">
49 <tp:docstring>
50 If non-zero, enable Duplicate Run-Length-Encoded Report Blocks. The
51 value of this integer represents the max-size of report blocks, as
52 specified in RFC 3611 section 5.1. MAXUINT32 is used to indicate that
53 there is no limit.
54 </tp:docstring>
55 </property>
56 <property access="read" type="u" name="PacketReceiptTimesMaxSize" tp:name-for-bindings="Packet_Receipt_Times_Max_Size">
57 <tp:docstring>
58 If non-zero, enable Packet Receipt Times Report Blocks. The
59 value of this integer represents the max-size of report blocks, as
60 specified in RFC 3611 section 5.1. MAXUINT32 is used to indicate that
61 there is no limit.
62 </tp:docstring>
63 </property>
64 <property access="read" type="u" name="DLRRMaxSize" tp:name-for-bindings="DLRR_Max_Size">
65 <tp:docstring>
66 If non-zero, enable Receiver Reference Time and Delay since Last
67 Receiver Report Blocks (for estimating Round Trip Times between
68 non-senders and other parties in the call. The value of this integer
69 represents the max-size of report blocks, as specified in RFC 3611
70 section 5.1. MAXUINT32 is used to indicate that there is no limit.
71 </tp:docstring>
72 </property>
73 <property access="read" type="u" tp:type="RCPT_XR_RTT_Mode"
74 name="RTTMode" tp:name-for-bindings="RTT_Mode">
75 <tp:docstring>
76 Who is allowed to send Delay since Last Receiver Reports.
77 </tp:docstring>
78 </property>
79
80 <property access="read" type="u" tp:type="RTCP_XR_Statistics_Flags"
81 name="StatisticsFlags" tp:name-for-bindings="Statistics_Flags">
82 <tp:docstring>
83 Which fields SHOULD be included in the statistics summary
84 report blocks that are sent, and whether to send VoIP Metrics Report
85 Blocks. There can be zero or more flags
86 set.
87 </tp:docstring>
88 </property>
89
90 <property access="read" type="b" name="EnableMetrics" tp:name-for-bindings="Enable_Metrics">
91 <tp:docstring>
92 Whether to enable VoIP Metrics Report Blocks. These blocks are of a
93 fixed size.
94 </tp:docstring>
95 </property>
96
97 <tp:flags name="RTCP_XR_Statistics_Flags" type="u">
98 <tp:flag suffix="Loss" value="1">
99 <tp:docstring>
100 Loss report flag, as defined in RFC3611 section 4.6.
101 </tp:docstring>
102 </tp:flag>
103 <tp:flag suffix="Duplicate" value="2">
104 <tp:docstring>
105 Duplicate report flag, as defined in RFC3611 section 4.6.
106 </tp:docstring>
107 </tp:flag>
108 <tp:flag suffix="Jitter" value="4">
109 <tp:docstring>
110 Jitter flag, as defined in RFC3611 section 4.6.
111 </tp:docstring>
112 </tp:flag>
113 <tp:flag suffix="TTL" value="8">
114 <tp:docstring>
115 First bit of TTL or Hop Limit flag, as defined in RFC3611 section
116 4.6.
117 </tp:docstring>
118 </tp:flag>
119 <tp:flag suffix="HL" value="16">
120 <tp:docstring>
121 Second bit of TTL or Hop Limit flag, as defined in RFC3611 section
122 4.6.
123 </tp:docstring>
124 </tp:flag>
125 </tp:flags>
126
127 <tp:enum name="RCPT_XR_RTT_Mode" type="u">
128 <tp:enumvalue suffix="All" value="0">
129 <tp:docstring>
130 Both RTP data senders and data receivers MAY send DLRR
131 blocks.
132 </tp:docstring>
133 </tp:enumvalue>
134 <tp:enumvalue suffix="Sender" value="1">
135 <tp:docstring>
136 Only active RTP senders MAY send DLRR blocks, i.e., non RTP
137 senders SHALL NOT send DLRR blocks.
138 </tp:docstring>
139 </tp:enumvalue>
140 </tp:enum>
141
142 </interface>
143 </node>
144 <!-- vim:set sw=2 sts=2 et ft=xml: -->
+61
-0
spec/Call_Content_Media_Description_Interface_RTCP_Feedback.xml less more
0 <?xml version="1.0" ?>
1 <node name="/Call_Content_Media_Description_Interface_RTCP_Feedback" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
2 <tp:copyright> Copyright © 2005-2010 Nokia Corporation </tp:copyright>
3 <tp:copyright> Copyright © 2005-2010 Collabora Ltd </tp:copyright>
4 <tp:license xmlns="http://www.w3.org/1999/xhtml">
5 This library is free software; you can redistribute it and/or
6 modify it under the terms of the GNU Lesser General Public
7 License as published by the Free Software Foundation; either
8 version 2.1 of the License, or (at your option) any later version.
9
10 This library is distributed in the hope that it will be useful,
11 but WITHOUT ANY WARRANTY; without even the implied warranty of
12 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
13 Lesser General Public License for more details.
14
15 You should have received a copy of the GNU Lesser General Public
16 License along with this library; if not, write to the Free Software
17 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
18 </tp:license>
19
20 <interface name="org.freedesktop.Telepathy.Call1.Content.MediaDescription.Interface.RTCPFeedback"
21 tp:causes-havoc="experimental">
22 <tp:added version="0.23.4">(draft version, not API-stable)</tp:added>
23 <tp:requires interface="org.freedesktop.Telepathy.Call1.Content.MediaDescription"/>
24
25 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
26 <p>This codec offer interface provides a method of signalling
27 support for RTCP feedback, documented by <em>Extended RTP
28 Profile for Real-time Transport Control Protocol (RTCP)-Based
29 Feedback (RTP/AVPF)</em> (RFC 4585).</p>
30
31 <p>The codec identifiers used in the description of the Feedback Messages
32 sent in the <tp:dbus-ref
33 namespace="ofdT.Call1.Content.MediaDescription">Accept</tp:dbus-ref>'s
34 should match those used for the RemoteCodecs in the same Accept call.
35 </p>
36
37 <p>For more details on what RTCP Feedback can do and how to use
38 it, one should refer to
39 <a href="http://www.faqs.org/rfcs/rfc4585.html">RFC 4585</a>.</p>
40
41 </tp:docstring>
42
43 <property name="FeedbackMessages" type="a{u(ua(sss))}"
44 tp:type="RTCP_Feedback_Message_Map"
45 access="read" tp:name-for-bindings="Feedback_Messages">
46 <tp:docstring>
47 A map of remote feedback codec properties that are supported.
48 </tp:docstring>
49 </property>
50
51 <property name="DoesAVPF" type="b"
52 access="read" tp:name-for-bindings="Does_AVPF">
53 <tp:docstring>
54 True if the remote contact supports Audio-Visual Profile
55 Feedback (AVPF), otherwise False.
56 </tp:docstring>
57 </property>
58 </interface>
59 </node>
60 <!-- vim:set sw=2 sts=2 et ft=xml: -->
+73
-0
spec/Call_Content_Media_Description_Interface_RTP_Header_Extensions.xml less more
0 <?xml version="1.0" ?>
1 <node name="/Call_Content_Media_Description_Interface_RTP_Header_Extensions" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
2 <tp:copyright> Copyright © 2005-2010 Nokia Corporation </tp:copyright>
3 <tp:copyright> Copyright © 2005-2010 Collabora Ltd </tp:copyright>
4 <tp:license xmlns="http://www.w3.org/1999/xhtml">
5 This library is free software; you can redistribute it and/or
6 modify it under the terms of the GNU Lesser General Public
7 License as published by the Free Software Foundation; either
8 version 2.1 of the License, or (at your option) any later version.
9
10 This library is distributed in the hope that it will be useful,
11 but WITHOUT ANY WARRANTY; without even the implied warranty of
12 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
13 Lesser General Public License for more details.
14
15 You should have received a copy of the GNU Lesser General Public
16 License along with this library; if not, write to the Free Software
17 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
18 </tp:license>
19
20 <interface name="org.freedesktop.Telepathy.Call1.Content.MediaDescription.Interface.RTPHeaderExtensions"
21 tp:causes-havoc="experimental">
22 <tp:added version="0.23.4">(draft version, not API-stable)</tp:added>
23 <tp:requires interface="org.freedesktop.Telepathy.Call1.Content.MediaDescription"/>
24
25 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
26 <p>This media description interface provides a method of signalling
27 support for RTP Header Extensions, documented by
28 <em>A General Mechanism for RTP Header Extensions (RFC 5285)</em>.</p>
29
30 <p>For more details on the General Mechanism for RTP Header Extensions
31 and how to use them, one should refer to
32 <a href="http://www.faqs.org/rfcs/rfc5285.html">RFC 5285</a>.</p>
33
34 </tp:docstring>
35
36 <tp:struct name="RTP_Header_Extension"
37 array-name="RTP_Header_Extensions_List">
38 <tp:docstring>
39 A struct defining a RTP Header extension.
40 </tp:docstring>
41 <tp:member type="u" name="ID">
42 <tp:docstring>
43 Identifier to be negotiated.
44 </tp:docstring>
45 </tp:member>
46 <tp:member type="u" tp:type="Media_Stream_Direction" name="Direction">
47 <tp:docstring>
48 Direction in which the Header Extension is negotiated.
49 </tp:docstring>
50 </tp:member>
51 <tp:member type="s" name="URI">
52 <tp:docstring>
53 URI defining the extension.
54 </tp:docstring>
55 </tp:member>
56 <tp:member type="s" name="Parameters">
57 <tp:docstring>
58 Feedback parameters as a string. Format is defined in the relevant RFC.
59 </tp:docstring>
60 </tp:member>
61 </tp:struct>
62
63 <property name="HeaderExtensions" type="a(uuss)"
64 tp:type="RTP_Header_Extension[]"
65 access="read" tp:name-for-bindings="Header_Extensions">
66 <tp:docstring>
67 A list of remote header extensions which are supported.
68 </tp:docstring>
69 </property>
70 </interface>
71 </node>
72 <!-- vim:set sw=2 sts=2 et ft=xml: -->
+144
-0
spec/Call_Interface_Mute.xml less more
0 <?xml version="1.0" ?>
1 <node name="/Call_Interface_Mute" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
2 <tp:copyright> Copyright © 2005-2010 Nokia Corporation </tp:copyright>
3 <tp:copyright> Copyright © 2005-2010 Collabora Ltd </tp:copyright>
4 <tp:license xmlns="http://www.w3.org/1999/xhtml">
5 This library is free software; you can redistribute it and/or
6 modify it under the terms of the GNU Lesser General Public
7 License as published by the Free Software Foundation; either
8 version 2.1 of the License, or (at your option) any later version.
9
10 This library is distributed in the hope that it will be useful,
11 but WITHOUT ANY WARRANTY; without even the implied warranty of
12 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
13 Lesser General Public License for more details.
14
15 You should have received a copy of the GNU Lesser General Public
16 License along with this library; if not, write to the Free Software
17 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
18 </tp:license>
19
20 <interface name="org.freedesktop.Telepathy.Call1.Interface.Mute" tp:causes-havoc="experimental">
21 <tp:added version="0.19.6">(draft version, not API-stable)</tp:added>
22 <tp:xor-requires interface="org.freedesktop.Telepathy.Channel.Type.Call1"/>
23 <tp:xor-requires interface="org.freedesktop.Telepathy.Call1.Content"/>
24 <tp:xor-requires interface="org.freedesktop.Telepathy.Call1.Stream"/>
25
26 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
27 <p>Interface for calls which may be muted. This only makes sense
28 for channels where audio or video is streaming between members.</p>
29
30 <p>Muting a call content indicates that the user does not wish to send
31 outgoing audio or video.</p>
32
33 <p>It should always be possible to mute an entire call. It is sometimes
34 also possible to mute individual Contents (e.g. to prevent background
35 noise from disturbing other participants, but remain visible on
36 webcam) or to mute individual streams (e.g. to "whisper" to other call
37 participants)</p>
38
39 <tp:rationale>
40 For some protocols, the fact that the content is muted needs
41 to be transmitted to the peer; for others, the notification
42 to the peer is only informational (eg. XMPP), and some
43 protocols may have no notion of muting at all.
44 </tp:rationale>
45 </tp:docstring>
46
47 <tp:enum name="Local_Mute_State" type="u">
48 <tp:docstring>
49 The mute state of (at least part of) the call. See
50 <tp:member-ref>LocalMuteState</tp:member-ref> for more details.
51 </tp:docstring>
52
53 <tp:enumvalue value="0" suffix="Unmuted">
54 <tp:docstring>
55 All streams are unmuted (the call is active). New channels SHOULD
56 have this mute state.
57 </tp:docstring>
58 </tp:enumvalue>
59
60 <tp:enumvalue value="1" suffix="Muted">
61 <tp:docstring>
62 All streams are Muted.
63 </tp:docstring>
64 </tp:enumvalue>
65
66 <tp:enumvalue value="2" suffix="Pending_Mute">
67 <tp:docstring>
68 The connection manager is attempting to move to state Muted, but
69 has not yet completed that operation. It is unspecified whether
70 any, all or none of the streams making up the channel are muted.
71 Examining the Mute state of Call Contents (if applicable) may
72 provide more useful information.
73 </tp:docstring>
74 </tp:enumvalue>
75
76 <tp:enumvalue value="3" suffix="Pending_Unmute">
77 <tp:docstring>
78 The connection manager is attempting to move to state Unmuted, but
79 has not yet completed that operation. It is unspecified whether
80 any, all or none of the streams making up the channel are muted.
81 Examining the Mute state of Call Contents or Streams may
82 provide more useful information.
83 </tp:docstring>
84 </tp:enumvalue>
85
86 <tp:enumvalue value="4" suffix="Partially_Muted">
87 <tp:docstring>
88 Some of the constituent Streams are Muted. This state only makes
89 sense on Call Channels or Contents.
90 Examining the Mute state of Call Contents or Streams should
91 provide more useful information.
92 </tp:docstring>
93 </tp:enumvalue>
94 </tp:enum>
95
96 <signal name="MuteStateChanged" tp:name-for-bindings="Mute_State_Changed">
97 <tp:docstring>
98 Emitted to indicate that the mute state has changed for this call content.
99 This may occur as a consequence of the client calling
100 <tp:member-ref>RequestMuted</tp:member-ref>, or as an indication that another
101 client has (un)muted the content.
102 </tp:docstring>
103 <arg name="MuteState" type="u" tp:type="Local_Mute_State">
104 <tp:docstring>
105 The new mute state.
106 </tp:docstring>
107 </arg>
108 </signal>
109
110 <property name="LocalMuteState" type="u" tp:type="Local_Mute_State"
111 access="read" tp:name-for-bindings="Local_Mute_State">
112 <tp:docstring>
113 The current mute state of this part of the call. New
114 <tp:dbus-ref namespace="ofdT.Call1">Content</tp:dbus-ref>s should
115 inherit the value of this property from the parent
116 <tp:dbus-ref namespace="ofdT.Channel.Type">Call1</tp:dbus-ref>.
117 Similarly, <tp:dbus-ref namespace="ofdT.Call1">Stream</tp:dbus-ref>s
118 should inherit it from the parent <tp:dbus-ref
119 namespace="ofdT.Call1">Content</tp:dbus-ref>.
120 </tp:docstring>
121 </property>
122
123 <method name="RequestMuted" tp:name-for-bindings="Request_Muted">
124 <tp:changed version="0.21.2">renamed from SetMuted to Mute</tp:changed>
125 <tp:changed version="0.21.3">renamed back from Mute to SetMuted</tp:changed>
126 <arg direction="in" name="Muted" type="b">
127 <tp:docstring>
128 True if the client wishes to mute the Content or Call.
129 </tp:docstring>
130 </arg>
131 <tp:docstring>
132 <p>Inform the CM that the Call, Content or Stream should be muted or
133 unmuted.</p>
134
135 <p>The CM will tell the streaming implementation to Mute Streams as
136 required, and emit <tp:member-ref>MuteStateChanged</tp:member-ref>
137 when done.</p>
138 </tp:docstring>
139 </method>
140
141 </interface>
142 </node>
143 <!-- vim:set sw=2 sts=2 et ft=xml: -->
+60
-30
spec/Call_Stream.xml less more
1919 02110-1301, USA.</p>
2020 </tp:license>
2121
22 <interface name="org.freedesktop.Telepathy.Call.Stream.DRAFT"
22 <interface name="org.freedesktop.Telepathy.Call1.Stream"
2323 tp:causes-havoc="experimental">
2424 <tp:added version="0.19.0">(draft 1)</tp:added>
2525
2626 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
2727 One stream inside a <tp:dbus-ref
28 namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref>.
28 namespace="ofdT.Call1">Content</tp:dbus-ref>. A stream is
29 a single flow of packets to and from a single remote endpoint.
30 If your call connects to multiple people, you could have
31 multiple streams.
2932 </tp:docstring>
3033
3134 <method name="SetSending" tp:name-for-bindings="Set_Sending">
3841 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
3942 <p>If True, the
4043 <tp:member-ref>LocalSendingState</tp:member-ref> should
41 change to <tp:type>Sending_State</tp:type>_Sending, if it isn't
44 change to <tp:value-ref type="Sending_State">Sending</tp:value-ref>, if it isn't
4245 already.</p>
4346
4447 <p>If False, the
4548 <tp:member-ref>LocalSendingState</tp:member-ref> should
46 change to <tp:type>Sending_State</tp:type>_None, if it isn't
49 change to <tp:value-ref type="Sending_State">None</tp:value-ref>, if it isn't
4750 already.</p>
4851 </tp:docstring>
4952 </arg>
5053
5154 <tp:possible-errors>
5255 <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented" />
56 <tp:error name="org.freedesktop.Telepathy.Error.NotYet">
57 <tp:docstring>If the call has not been accepted yet, calling
58 SetSending(True) is an error. See
59 <tp:member-ref>LocalSendingState</tp:member-ref> for details.
60 </tp:docstring>
61 </tp:error>
5362 </tp:possible-errors>
5463 </method>
5564
115124 property, as a result of the contact leaving this stream
116125 </tp:docstring>
117126 </arg>
127 <arg name="Reason" type="(uuss)" tp:type="Call_State_Reason">
128 <tp:docstring>
129 A structured reason for the change.
130 </tp:docstring>
131 </arg>
118132 </signal>
119133
120134 <signal name="LocalSendingStateChanged"
127141 <tp:docstring>
128142 The new value of
129143 <tp:member-ref>LocalSendingState</tp:member-ref>.
144 </tp:docstring>
145 </arg>
146
147 <arg name="Reason" type="(uuss)" tp:type="Call_State_Reason">
148 <tp:docstring>
149 A structured reason for the change.
130150 </tp:docstring>
131151 </arg>
132152 </signal>
183203 <tp:added version="0.19.11"/>
184204 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
185205 <p>Extra interfaces provided by this stream, such as <tp:dbus-ref
186 namespace="ofdT.Call">Stream.Interface.Media.DRAFT</tp:dbus-ref>.
206 namespace="ofdT.Call1">Stream.Interface.Media</tp:dbus-ref>.
187207 This SHOULD NOT include the Stream interface itself, and cannot
188208 change once the stream has been created.</p>
189209 </tp:docstring>
193213 type="a{uu}" access="read" tp:type="Contact_Sending_State_Map">
194214 <tp:changed version="0.21.2">renamed from Senders</tp:changed>
195215 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
196 <p>A map from remote contacts to their sending state. The
197 local user's sending state is shown in
198 <tp:member-ref>LocalSendingState</tp:member-ref>.</p>
199
200 <p><tp:type>Sending_State</tp:type>_Pending_Send indicates
201 that another contact has asked the local user to send
202 media.</p>
203
204 <p>Other contacts' handles in this map indicate whether they are
205 sending media to the contacts in this stream.
206 Sending_State_Pending_Send indicates contacts who are not sending but
207 have been asked to do so.</p>
216 <p>A map from remote contacts to their sending state.</p>
217
218 <p>Media sent to this stream will be sent to all members listed here.
219 All members listed here will also appear in <tp:dbus-ref
220 namespace="ofdT.Channel.Type.Call1">CallMembers</tp:dbus-ref>,
221 and each CallMembers member will be listed in at most one Stream per
222 Content. Therefore, to hide things from a member of the
223 call, UIs only need to mute one Stream per Content.</p>
224
225 <p>Contacts' handles in this map indicate whether they are
226 sending media to this stream. Sending_State_Pending_Send indicates
227 contacts who are not sending but have been asked to do so. The
228 local user's sending state is shown in <tp:member-ref
229 >LocalSendingState</tp:member-ref>.</p>
230
231 <p>This mapping is also used by the streaming implementation to map
232 from <tp:dbus-ref namespace="ofdT.Call1.Content"
233 >MediaDescription</tp:dbus-ref>s to Streams. In this use-case,
234 all of the senders in this stream will be represented in
235 <tp:dbus-ref namespace="ofdT.Call1.Content.Interface.Media"
236 >RemoteMediaDescriptions</tp:dbus-ref>. This use-case should not
237 affect anything that does not handle media streaming.</p>
208238 </tp:docstring>
209239 </property>
210240
227257 special-cased.
228258 </tp:rationale>
229259
230 <p>A value of <tp:type>Sending_State</tp:type>_Pending_Send for
260 <p>A value of <tp:value-ref type="Sending_State">Pending_Send</tp:value-ref> for
231261 this property indicates that the other side requested the
232 local user start sending media, which can be done by calling
233 <tp:member-ref>SetSending</tp:member-ref>. When a call is
234 accepted, all initial contents with streams that have a
235 local sending state of
236 <tp:type>Sending_State</tp:type>_Pending_Send are
237 automatically set to sending. For example, on an incoming
238 call it means you need to <tp:dbus-ref
239 namespace="ofdT.Channel.Type.Call.DRAFT">Accept</tp:dbus-ref>
240 to start the actual call, on an outgoing call it might mean
241 you need to call <tp:dbus-ref
242 namespace="ofdT.Channel.Type.Call.DRAFT">Accept</tp:dbus-ref>
243 before actually starting the call.</p>
262 local user start sending media (which can be done by calling either
263 <tp:member-ref>SetSending</tp:member-ref> or <tp:dbus-ref
264 namespace="ofdT.Channel.Type.Call1">Accept</tp:dbus-ref>).</p>
265
266 <p>When <tp:dbus-ref
267 namespace="ofdT.Channel.Type.Call1">Accept</tp:dbus-ref> is
268 called, all streams with a local sending state of
269 <tp:value-ref type="Sending_State">Pending_Send</tp:value-ref> and the associated
270 <tp:dbus-ref namespace="ofdT.Call1.Content"
271 >Disposition</tp:dbus-ref> set to
272 <tp:value-ref type="Call_Content_Disposition">Initial</tp:value-ref> are
273 automatically set to sending.</p>
244274 </tp:docstring>
245275 </property>
246276
+266
-48
spec/Call_Stream_Endpoint.xml less more
1919 02110-1301, USA.</p>
2020 </tp:license>
2121
22 <interface name="org.freedesktop.Telepathy.Call.Stream.Endpoint.DRAFT"
22 <interface name="org.freedesktop.Telepathy.Call1.Stream.Endpoint"
2323 tp:causes-havoc="experimental">
2424 <tp:added version="0.19.0">(draft 1)</tp:added>
2525
9191 </arg>
9292 </signal>
9393
94 <signal name="CandidateSelected"
95 tp:name-for-bindings="Candidate_Selected">
96 <tp:docstring>
97 Emitted when a candidate is selected for use in the stream.
98 </tp:docstring>
99 <arg name="Candidate"
94 <tp:struct name="Candidate_Pair" array-name="Candidate_Pair_List">
95 <tp:docstring>A Pair of candidates.</tp:docstring>
96 <tp:member name="Local" type="(usua{sv})" tp:type="Candidate">
97 <tp:docstring>The local candidate.</tp:docstring>
98 </tp:member>
99 <tp:member name="Remote" type="(usua{sv})" tp:type="Candidate">
100 <tp:docstring>The remote candidate.</tp:docstring>
101 </tp:member>
102 </tp:struct>
103
104 <signal name="CandidatePairSelected"
105 tp:name-for-bindings="Candidate_Pair_Selected">
106 <tp:docstring>
107 Emitted when a candidate is selected for use in the stream by the
108 controlling side of an ICE session.
109 The controlled side should call
110 <tp:member-ref>AcceptSelectedCandidatePair</tp:member-ref> or
111 <tp:member-ref>RejectSelectedCandidatePair</tp:member-ref> when
112 connectivity checks have either succeeded or failed for this candidate
113 pair. See also: <tp:member-ref>SelectedCandidatePairs</tp:member-ref>.
114 </tp:docstring>
115 <arg name="Local_Candidate"
100116 type="(usua{sv})" tp:type="Candidate">
101117 <tp:docstring>
102 The candidate that has been selected.
118 The local candidate that has been selected.
119 </tp:docstring>
120 </arg>
121 <arg name="Remote_Candidate"
122 type="(usua{sv})" tp:type="Candidate">
123 <tp:docstring>
124 The remote candidate that has been selected.
103125 </tp:docstring>
104126 </arg>
105127 </signal>
106128
107 <property name="SelectedCandidate"
108 tp:name-for-bindings="Selected_Candidate"
109 type="(usua{sv})" tp:type="Candidate" access="read">
110 <tp:docstring>
111 The candidate that has been selected for use to stream packets
112 to the remote contact. Change notification is given via the
113 the <tp:member-ref>CandidateSelected</tp:member-ref> signal.
114 </tp:docstring>
115 </property>
116
117 <method name="SetSelectedCandidate"
118 tp:name-for-bindings="Set_Selected_Candidate">
119 <tp:docstring>
120 Set the value of
121 <tp:member-ref>CandidateSelected</tp:member-ref>.
122 </tp:docstring>
123 <arg name="Candidate"
124 type="(usua{sv})" tp:type="Candidate" direction="in">
125 <tp:docstring>
126 The candidate that has been selected.
129 <property name="SelectedCandidatePairs"
130 tp:name-for-bindings="Selected_Candidate_Pairs"
131 type="a((usua{sv})(usua{sv}))" tp:type="Candidate_Pair[]"
132 access="read">
133 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
134 <p>The candidates that have been selected for use to stream packets
135 to the remote contact for each component of the stream.
136 Change notification is given via the
137 the <tp:member-ref>CandidatePairSelected</tp:member-ref> signal.</p>
138
139 <p>Note to client implementors (from <a
140 href="http://tools.ietf.org/html/rfc5245#section-9.2.2.3">RFC 5245
141 section 9.2.2.3</a>):</p>
142
143 <blockquote>
144 <p>If at least one of the pairs is In-Progress, the agent SHOULD wait
145 for those checks to complete, and as each completes, redo the
146 processing in this section until there are no losing pairs.</p>
147 </blockquote>
148
149 <p>Also note that some or all of the local candidates in this list may
150 represent a peer-reflexive candidate that do not appear in
151 <tp:dbus-ref namespace="ofdT.Call1.Stream.Interface.Media"
152 >LocalCandidates</tp:dbus-ref>.</p>
153
154 <p>See <a href='http://tools.ietf.org/html/rfc5245#appendix-B.6'>RFC
155 5245 Appendix B.6.</a> for more details about why this is.</p>
156 </tp:docstring>
157 </property>
158
159 <method name="SetSelectedCandidatePair"
160 tp:name-for-bindings="Set_Selected_Candidate_Pair">
161 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
162 <p>Update the entry in
163 <tp:member-ref>SelectedCandidatePairs</tp:member-ref>
164 for a particular component, and signal it to the remote side.</p>
165
166 <p>This method should only be called by the controlling side of an
167 ICE session. See <tp:member-ref>CandidatePairSelected</tp:member-ref>
168 for details.</p>
169
170 <tp:rationale>
171 <p>In the SDP offer/answer model, this signalling will take place as
172 generating an updated offer.
173 Note that updates may be queued up until information about all
174 components of all streams is gathered.</p>
175 </tp:rationale>
176 </tp:docstring>
177 <arg name="Local_Candidate"
178 type="(usua{sv})" tp:type="Candidate" direction="in">
179 <tp:docstring>
180 The local candidate that has been selected.
181 </tp:docstring>
182 </arg>
183 <arg name="Remote_Candidate"
184 type="(usua{sv})" tp:type="Candidate" direction="in">
185 <tp:docstring>
186 The remote candidate that has been selected.
127187 </tp:docstring>
128188 </arg>
129189 <tp:possible-errors>
131191 </tp:possible-errors>
132192 </method>
133193
134 <property name="StreamState" tp:name-for-bindings="Stream_State"
135 type="u" tp:type="Media_Stream_State"
194 <tp:enum name="Stream_Endpoint_State" type="u">
195 <tp:docstring>
196 Represents the state of ICE negotiation for a single component of a
197 stream to an endpoint.
198 </tp:docstring>
199 <tp:enumvalue suffix="Connecting" value="0">
200 <tp:docstring>
201 Candidate gathering and connectivity checks are in progress.
202 </tp:docstring>
203 </tp:enumvalue>
204 <tp:enumvalue suffix="Provisionally_Connected" value="1">
205 <tp:docstring>
206 The streaming implementation has found at least one working
207 candidate pair. It is possible to send media at this point, but the
208 controlling side has yet to negotiate the final candidates for use
209 in this call.
210 </tp:docstring>
211 </tp:enumvalue>
212 <tp:enumvalue suffix="Fully_Connected" value="2">
213 <tp:docstring>
214 This component of the stream is connected, and an updated offer has
215 been sent and accepted (finalising the candidates to be used for the
216 call). This should be set by the CM in response to
217 <tp:member-ref>AcceptSelectedCandidatePair</tp:member-ref>.
218 </tp:docstring>
219 </tp:enumvalue>
220 <tp:enumvalue suffix="Exhausted_Candidates" value="3">
221 <tp:docstring>
222 The streaming implementation has tried connecting to all of the
223 available candidates and none of them have connected. This is
224 distinct from Failed, because the CM might be able to provide more
225 candidates later (more likely in XMPP than SIP).
226 </tp:docstring>
227 </tp:enumvalue>
228 <tp:enumvalue suffix="Failed" value="4">
229 <tp:docstring>
230 The CM and streaming implementation are in agreement that it is
231 impossible to connect to this endpoint. This value should only be
232 set by the CM.
233 </tp:docstring>
234 </tp:enumvalue>
235 </tp:enum>
236
237 <tp:mapping name="Component_State_Map">
238 <tp:member name="Component" type="u" tp:type="Stream_Component"/>
239 <tp:member name="State" type="u" tp:type="Stream_Endpoint_State"/>
240 </tp:mapping>
241
242 <property name="EndpointState" tp:name-for-bindings="Endpoint_State"
243 type="a{uu}" tp:type="Component_State_Map"
136244 access="read">
137245 <tp:docstring>
138 The stream state of the endpoint.
139 </tp:docstring>
140 </property>
141
142 <signal name="StreamStateChanged"
143 tp:name-for-bindings="Stream_State_Changed">
144 <tp:docstring>
145 Emitted when the <tp:member-ref>StreamState</tp:member-ref>
246 The state of ICE negotiation with this Endpoint for each component of
247 the stream.
248 </tp:docstring>
249 </property>
250
251 <signal name="EndpointStateChanged"
252 tp:name-for-bindings="Endpoint_State_Changed">
253 <tp:docstring>
254 Emitted when the <tp:member-ref>EndpointState</tp:member-ref>
146255 property changes.
147256 </tp:docstring>
148 <arg name="state" type="u" tp:type="Media_Stream_State">
149 <tp:docstring>
150 The new <tp:member-ref>StreamState</tp:member-ref> value.
257 <arg name="Component" type="u" tp:type="Stream_Component">
258 <tp:docstring>
259 The component whose state has changed.
260 </tp:docstring>
261 </arg>
262 <arg name="State" type="u" tp:type="Stream_Endpoint_State">
263 <tp:docstring>
264 The new state of this component.
151265 </tp:docstring>
152266 </arg>
153267 </signal>
154268
155 <method name="SetStreamState"
156 tp:name-for-bindings="Set_Stream_State">
157 <tp:docstring>
158 Change the <tp:member-ref>StreamState</tp:member-ref> of the
269 <method name="SetEndpointState"
270 tp:name-for-bindings="Set_Endpoint_State">
271 <tp:docstring>
272 Change the <tp:member-ref>EndpointState</tp:member-ref> of the
159273 endpoint.
160274 </tp:docstring>
161 <arg direction="in" name="State" type="u" tp:type="Media_Stream_State">
162 <tp:docstring>
163 The requested stream state.
275 <arg direction="in" name="Component" type="u" tp:type="Stream_Component">
276 <tp:docstring>
277 The component whose state needs updating.
278 </tp:docstring>
279 </arg>
280 <arg direction="in" name="State" type="u" tp:type="Stream_Endpoint_State">
281 <tp:docstring>
282 The new state of this component.
164283 </tp:docstring>
165284 </arg>
166285 <tp:possible-errors>
169288 </tp:possible-errors>
170289 </method>
171290
291 <method name="AcceptSelectedCandidatePair"
292 tp:name-for-bindings="Accept_Selected_Candidate_Pair">
293 <tp:docstring>
294 Called in response to
295 <tp:member-ref>CandidatePairSelected</tp:member-ref> if/when this
296 candidate pair is known to have passed its connectivity checks.
297 </tp:docstring>
298 <arg name="Local_Candidate"
299 type="(usua{sv})" tp:type="Candidate" direction="in">
300 <tp:docstring>
301 The local candidate that has been selected.
302 </tp:docstring>
303 </arg>
304 <arg name="Remote_Candidate"
305 type="(usua{sv})" tp:type="Candidate" direction="in">
306 <tp:docstring>
307 The remote candidate that has been selected.
308 </tp:docstring>
309 </arg>
310 <tp:possible-errors>
311 <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
312 </tp:possible-errors>
313 </method>
314
315 <method name="RejectSelectedCandidatePair"
316 tp:name-for-bindings="Reject_Selected_Candidate_Pair">
317 <tp:docstring>
318 Called in response to
319 <tp:member-ref>CandidatePairSelected</tp:member-ref> if/when this
320 candidate pair is known to have failed its connectivity checks.
321 </tp:docstring>
322 <arg name="Local_Candidate"
323 type="(usua{sv})" tp:type="Candidate" direction="in">
324 <tp:docstring>
325 The local candidate that has been selected.
326 </tp:docstring>
327 </arg>
328 <arg name="Remote_Candidate"
329 type="(usua{sv})" tp:type="Candidate" direction="in">
330 <tp:docstring>
331 The remote candidate that has been selected.
332 </tp:docstring>
333 </arg>
334 <tp:possible-errors>
335 <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
336 </tp:possible-errors>
337 </method>
338
172339 <property name="Transport" tp:name-for-bindings="Transport"
173340 type="u" tp:type="Stream_Transport_Type" access="read">
174341 <tp:docstring>
175342 The transport type for the stream endpoint.
343 </tp:docstring>
344 </property>
345
346 <property name="Controlling" tp:name-for-bindings="Controlling"
347 type="b" access="read">
348 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
349 <p>
350 The local side is taking the controlling role (as defined by ICE RFC
351 5245). Change notification is given via the
352 <tp:member-ref>ControllingChanged</tp:member-ref> signal.</p>
353
354 <tp:rationale>In ICE, the Caller is normally in controlling mode (and
355 the Callee in controlled-mode), except if the Caller is doing ICE-Lite,
356 in which case it's reversed. The Controlling side is responsible for
357 selecting nominated pairs, and generating updated offers upon
358 conclusion of ICE.</tp:rationale>
359 </tp:docstring>
360 </property>
361
362 <method name="SetControlling"
363 tp:name-for-bindings="Set_Controlling">
364 <tp:docstring>
365 Set whether the local side is taking the Controlling role. Note that
366 if there are multiple endpoints (e.g. SIP call forking) it may be the
367 case that all endpoints need to have the same controlling/controlled
368 orientation.
369 </tp:docstring>
370 <arg name="Controlling" type="b" direction="in">
371 <tp:docstring>
372 The new value of <tp:member-ref>Controlling</tp:member-ref>.
373 </tp:docstring>
374 </arg>
375 </method>
376
377 <signal name="ControllingChanged"
378 tp:name-for-bindings="Controlling_Changed">
379 <tp:docstring>
380 The value of <tp:member-ref>Controlling</tp:member-ref> has changed.
381 </tp:docstring>
382 <arg name="Controlling" type="b">
383 <tp:docstring>
384 The new value of <tp:member-ref>Controlling</tp:member-ref>.
385 </tp:docstring>
386 </arg>
387 </signal>
388
389 <property name="IsICELite" tp:name-for-bindings="Is_ICE_Lite"
390 type="b" access="read">
391 <tp:docstring>
392 The Remote side is an ICE Lite endpoint. (The local side is assumed to
393 always be an ICE Full implementation.)
176394 </tp:docstring>
177395 </property>
178396
+348
-51
spec/Call_Stream_Interface_Media.xml less more
1919 02110-1301, USA.</p>
2020 </tp:license>
2121
22 <interface name="org.freedesktop.Telepathy.Call.Stream.Interface.Media.DRAFT"
22 <interface name="org.freedesktop.Telepathy.Call1.Stream.Interface.Media"
2323 tp:causes-havoc="experimental">
2424 <tp:added version="0.19.0">(draft 1)</tp:added>
25 <tp:requires interface="org.freedesktop.Telepathy.Call.Stream.DRAFT"/>
25 <tp:requires interface="org.freedesktop.Telepathy.Call1.Stream"/>
2626
2727 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
28 [FIXME]
28 <p>This interface deals with how to connect a stream to an
29 endpoint. It contains all that is required to describe the
30 local endpoint, to succesfully establish a connection. While a
31 call is established, one may try to connect to multiple remote
32 endpoints at the same time. This is called forking in the SIP
33 jargon. Informations related to the connections are on the
34 <tp:dbus-ref
35 namespace="ofdT.Call1.Stream">Endpoint</tp:dbus-ref>
36 objects. Once the call is established, there MUST be a single
37 endpoint left.</p>
2938
3039 <h4>ICE restarts</h4>
3140
32 <p>If the <tp:dbus-ref
33 namespace="ofdT.Call.Stream.Endpoint.DRAFT">RemoteCredentialsSet</tp:dbus-ref>
34 signal is fired during a call once it has been called before
35 whilst setting up the call for initial use, and the
36 credentials have changed, then there has been an ICE
37 restart. In such a case, the CM SHOULD also empty the remote
38 candidate list in the <tp:dbus-ref
39 namespace="ofdT.Call.Stream">Endpoint.DRAFT</tp:dbus-ref>.</p>
40
41 <p>If the CM does an ICE restart, then the
42 <tp:member-ref>PleaseRestartICE</tp:member-ref> signal is
43 emitted and the streaming implementation should then call
44 <tp:member-ref>SetCredentials</tp:member-ref> again.</p>
41 <p>If the CM wants to do an ICE restart, then the
42 <tp:member-ref>ICERestartPending</tp:member-ref> property is set,
43 and the <tp:member-ref>ICERestartRequested</tp:member-ref> signal is
44 emitted. The streaming implementation should then call
45 <tp:member-ref>SetCredentials</tp:member-ref> again. This will trigger
46 the actual ICE restart, and cause
47 <tp:member-ref>LocalCandidates</tp:member-ref> to be cleared.</p>
4548
4649 <p>For more information on ICE restarts see
4750 <a href="http://tools.ietf.org/html/rfc5245#section-9.1.1.1">RFC 5245
4851 section 9.1.1.1</a></p>
4952 </tp:docstring>
5053
54 <tp:enum type="u" name="Stream_Flow_State">
55 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
56 The type of <tp:member-ref>SendingState</tp:member-ref>
57 and <tp:member-ref>ReceivingState</tp:member-ref>.
58 </tp:docstring>
59 <tp:enumvalue suffix="Stopped" value="0">
60 <tp:docstring>
61 No data is flowing (or expected to be flowing) at this time.
62 </tp:docstring>
63 </tp:enumvalue>
64 <tp:enumvalue suffix="Pending_Start" value="1">
65 <tp:docstring>
66 The streaming implementation has been told to start or receiving,
67 but has not yet indicated that it is doing so.
68 </tp:docstring>
69 </tp:enumvalue>
70 <tp:enumvalue suffix="Pending_Stop" value="2">
71 <tp:docstring>
72 The streaming implementation has been told to stop sending or
73 receiving data, but it has not yet indicated that it has done so.
74 </tp:docstring>
75 </tp:enumvalue>
76 <tp:enumvalue suffix="Started" value="3">
77 <tp:docstring>
78 The streaming implementation is successfully sending or receiving
79 data, and everything is going swimmingly.
80 </tp:docstring>
81 </tp:enumvalue>
82 <tp:enumvalue suffix="Pending_Pause" value="4">
83 <tp:docstring>
84 The streaming implementation has been told to pause sending or
85 displaying data, but it has not yet indicated that it has done so.
86 </tp:docstring>
87 </tp:enumvalue>
88 <tp:enumvalue suffix="Paused" value="5">
89 <tp:docstring>
90 The streaming implementation has successfully paused either sending or
91 displaying data, and the local user's privacy or peace-and-quiet is
92 protected.
93 </tp:docstring>
94 </tp:enumvalue>
95 </tp:enum>
96
97 <property name="SendingState" tp:name-for-bindings="Sending_State"
98 type="u" tp:type="Stream_Flow_State" access="read">
99 <tp:docstring>
100 Indicates whether the streaming implementation is/should be sending
101 media for this stream. The streaming implementation should be able to
102 rely on reading this value and listening to
103 <tp:member-ref>SendingStateChanged</tp:member-ref> to
104 determine whether it should be sending media or not. It should not
105 need to listen to the Mute/Hold interfaces on the Call/Content.
106 Feedback on success should be given via
107 <tp:member-ref>CompleteSendingStateChange</tp:member-ref>. Failures
108 should be reported via <tp:member-ref>ReportSendingFailure</tp:member-ref>.
109 </tp:docstring>
110 </property>
111
112 <signal name="SendingStateChanged"
113 tp:name-for-bindings="Sending_State_Changed">
114 <tp:docstring>
115 Change notification for <tp:member-ref>SendingState</tp:member-ref>.
116 Note that this information is duplicated onto the Stream interface, so
117 that UIs can ignore the Media interface, and streaming implementations
118 can ignore everything but the media interface.
119 </tp:docstring>
120 <arg name="State" type="u" tp:type="Stream_Flow_State">
121 <tp:docstring>
122 The new value of SendingState.
123 </tp:docstring>
124 </arg>
125 </signal>
126
127 <method name="CompleteSendingStateChange"
128 tp:name-for-bindings="Complete_Sending_State_Change">
129 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
130 <p>Called in response to
131 <tp:member-ref>SendingStateChanged</tp:member-ref>(Pending_*, *) to
132 indicate that the media state has successfully progressed from
133 Pending_{Start, Stop, Pause} to the corresponding non-pending
134 state.</p>
135 </tp:docstring>
136 <arg name="State" type="u" tp:type="Stream_Flow_State" direction="in">
137 <tp:docstring>
138 The new (non-pending) value of SendingState.
139 </tp:docstring>
140 </arg>
141 <tp:possible-errors>
142 <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
143 <tp:docstring>
144 The state change made no sense, and was ignored by the CM. The
145 most likely cause for this is a race-condition between the CM
146 emitting a new state change and the streaming implementation
147 responding to the previous state change.
148 </tp:docstring>
149 </tp:error>
150 </tp:possible-errors>
151 </method>
152
153 <method name="ReportSendingFailure"
154 tp:name-for-bindings="Report_Sending_Failure">
155 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
156 Can be called at any point to indicate a failure in the outgoing
157 portion of the stream.
158 </tp:docstring>
159 <arg name="Reason" type="u" tp:type="Call_State_Change_Reason"
160 direction="in"/>
161 <arg name="Error" type="s" tp:type="DBus_Error_Name" direction="in"/>
162 <arg name="Message" type="s" direction="in"/>
163 </method>
164
165 <property name="ReceivingState" tp:name-for-bindings="Receiving_State"
166 type="u" tp:type="Stream_Flow_State" access="read">
167 <tp:docstring>
168 The counterpart of <tp:member-ref>SendingState</tp:member-ref>.
169 Indicates whether the streaming implementation is/should be expecting
170 to receive media for this stream. The CM should only tell the
171 streaming implementation to stop receiving if it has been told to put
172 the stream on hold, or the stream has been removed from the call.
173 </tp:docstring>
174 </property>
175
176 <signal name="ReceivingStateChanged"
177 tp:name-for-bindings="Receiving_State_Changed">
178 <tp:docstring>
179 Change notification for <tp:member-ref>ReceivingState</tp:member-ref>.
180 </tp:docstring>
181 <arg name="State" type="u" tp:type="Stream_Flow_State">
182 <tp:docstring>
183 The new value of ReceivingState.
184 </tp:docstring>
185 </arg>
186 </signal>
187
188 <method name="CompleteReceivingStateChange"
189 tp:name-for-bindings="Complete_Receiving_State_Change">
190 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
191 <p>Called in response to
192 <tp:member-ref>ReceivingStateChanged</tp:member-ref>(Pending_*, *) to
193 indicate that the media state has successfully progressed from
194 Pending_{Start, Stop, Pause} to the corresponding non-pending
195 state.</p>
196 </tp:docstring>
197 <arg name="State" type="u" tp:type="Stream_Flow_State" direction="in">
198 <tp:docstring>
199 The new (non-pending) value of ReceivingState.
200 </tp:docstring>
201 </arg>
202 <tp:possible-errors>
203 <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
204 <tp:docstring>
205 The state change made no sense, and was ignored by the CM. The
206 most likely cause for this is a race-condition between the CM
207 emitting a new state change and the streaming implementation
208 responding to the previous state change.
209 </tp:docstring>
210 </tp:error>
211 </tp:possible-errors>
212 </method>
213
214 <method name="ReportReceivingFailure"
215 tp:name-for-bindings="Report_Receiving_Failure">
216 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
217 Can be called at any point to indicate a failure in the outgoing
218 portion of the stream.
219 </tp:docstring>
220 <arg name="Reason" type="u" tp:type="Call_State_Change_Reason"
221 direction="in"/>
222 <arg name="Error" type="s" tp:type="DBus_Error_Name" direction="in"/>
223 <arg name="Message" type="s" direction="in"/>
224 </method>
225
51226 <method name="SetCredentials" tp:name-for-bindings="Set_Credentials">
52227 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
53228 <p>Used to set the username fragment and password for streams that have
64239 </tp:docstring>
65240 </arg>
66241 </method>
242
243 <tp:enum type="u" name="Call_Stream_Candidate_Type">
244 <tp:docstring>
245 The network topology that an IP candidate represents. This can
246 sometimes be used to infer what kind of performance characteristics
247 (latency, bandwith, etc) can be expected of connections made to this
248 candidate.
249 </tp:docstring>
250 <tp:enumvalue suffix="None" value="0">
251 <tp:docstring>
252 This is not an IP candidate. This is a reserved value, and should
253 not be seen on the bus.
254 </tp:docstring>
255 </tp:enumvalue>
256 <tp:enumvalue suffix="Host" value="1">
257 <tp:docstring>
258 This candidate represents a direct connection to the host, as its
259 address is taken directly the host's IP stack.
260 </tp:docstring>
261 </tp:enumvalue>
262 <tp:enumvalue suffix="Server_Reflexive" value="2">
263 <tp:docstring>
264 This candidate probably represents a connection to the host through
265 a NAT device, as its address was discovered by sending a binding
266 request to a STUN server or similar.
267 </tp:docstring>
268 </tp:enumvalue>
269 <tp:enumvalue suffix="Peer_Reflexive" value="3">
270 <tp:docstring>
271 This candidate probably represents a good route between the host and
272 its peer, as its address was discovered by sending a STUN binding
273 request to one of the candidates advertised by the peer.
274 </tp:docstring>
275 </tp:enumvalue>
276 <tp:enumvalue suffix="Relay" value="4">
277 <tp:docstring>
278 This candidate represents the address of a relay server (usually
279 somewhere on the public internet). This candidate is the most likely
280 to work, but all media will go via a relay server, so latency is
281 likely to be higher than other types of candidate.
282 </tp:docstring>
283 </tp:enumvalue>
284 <tp:enumvalue suffix="Multicast" value="5">
285 <tp:docstring>
286 This candidate represents a Multicast group. This value should only
287 appear if the Stream's <tp:member-ref>Transport</tp:member-ref> is
288 set to Multicast.
289 </tp:docstring>
290 </tp:enumvalue>
291 </tp:enum>
292
67293
68294 <tp:mapping name="Candidate_Info">
69295 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
72298 used:</p>
73299
74300 <dl>
75 <dt>Type (u)</dt>
76 <dd>type of candidate (host, srflx, prflx, relay)</dd>
77
78 <dt>Foundation (s)</dt>
79 <dd>the foundation of this candiate</dd>
80
81 <dt>Protocol (u) </dt>
82 <dd>Underlying protocol of the candidate (udp, tcp) </dd>
83
84 <dt>Priority (u) </dt>
85 <dd>Priority of the candidate </dd>
86
87 <dt>BaseIP (u) </dt>
88 <dd>Base IP of this candidate </dd>
89
90 <dt>Username (s) </dt>
301 <dt><code>type</code> - u</dt>
302 <dd>The type of candidate
303 (<tp:type>Call_Stream_Candidate_Type</tp:type>)</dd>
304
305 <dt><code>foundation</code> - s</dt>
306 <dd>The foundation of this candidate</dd>
307
308 <dt><code>protocol</code> - u</dt>
309 <dd>Underlying protocol of the candidate
310 (<tp:type>Media_Stream_Base_Proto</tp:type>) </dd>
311
312 <dt><code>priority</code> - u</dt>
313 <dd>Priority of the candidate (should be a number between 0 and
314 65535). Most ICE implementations will prefer the highest priority
315 candidate pair that manages to connect. For backwards
316 compatibility with non-ICE SIP clients, the lowest priority
317 candidate may be sent as a raw UDP fallback candidate.
318 It is recommended that a relay candidate is used as the lowest
319 priority candidate if possible. If both IPv4 and IPv6 raw udp
320 fallback candidates are available, they should be set to the
321 same priority and advertised to the CM at the same time. The CM
322 will decide which to advertise to the remote end.</dd>
323
324 <dt><code>base-ip</code> - s</dt>
325 <dd>The underlying Host address where media sent to this
326 (non-host-type) candidate will eventually arrive.</dd>
327
328 <dt><code>base-port</code> - u</dt>
329 <dd>The underlying Host port where media sent to this
330 (non-host-type) candidate will eventually arrive.</dd>
331
332 <dt><code>username</code> - s</dt>
91333 <dd>Username of this candidate
92334 (only if credentials are per candidate)</dd>
93335
94 <dt>Password (s) </dt>
336 <dt><code>password</code> - s</dt>
95337 <dd>Password of this candidate
96338 (only if credentials are per candidate)</dd>
97339
98 <dt>RawUDPFallback (b) </dt>
99 <dd>Indicate whether this candidate may be used to provide a UDP
100 fallback</dd>
340 <dt><code>ttl</code> - u</dt>
341 <dd>The TTL mandated for RTP/RTCP packets sent to a multicast group
342 (only valid for Multicast Streams)</dd>
101343 </dl>
102344 </tp:docstring>
103345 <tp:member name="Key" type="s">
155397 <tp:docstring>
156398 Add candidates to the
157399 <tp:member-ref>LocalCandidates</tp:member-ref> property and
158 signal them to the remote contact(s).
400 signal them to the remote contact(s). Note that connection managers
401 MAY delay the sending of candidates until
402 <tp:member-ref>FinishInitialCandidates</tp:member-ref> is called.
159403 </tp:docstring>
160404 <arg name="Candidates" direction="in"
161405 type="a(usua{sv})" tp:type="Candidate[]">
165409 </arg>
166410 </method>
167411
168 <method name="CandidatesPrepared"
169 tp:name-for-bindings="Candidates_Prepared">
412 <method name="FinishInitialCandidates"
413 tp:name-for-bindings="Finish_Initial_Candidates">
170414 <tp:docstring>
171415 This indicates to the CM that the initial batch of candidates
172 has been added.
416 has been added, and should now be processed/sent to the remote side.
417 <tp:rationale>
418 Protocols supporting Raw UDP SHOULD wait for FinishInitialCandidates,
419 and then set the lowest priority candidate as the Raw UDP candidate.
420 </tp:rationale>
173421 </tp:docstring>
174422 </method>
175423
189437 Raw UDP, with or without STUN. All streaming clients are assumed to
190438 support this transport, so there is no handler capability token for
191439 it in the <tp:dbus-ref namespace="ofdT.Channel.Type"
192 >Call.DRAFT</tp:dbus-ref> interface.
440 >Call1</tp:dbus-ref> interface.
193441 [This corresponds to "none" or "stun" in the old Media.StreamHandler
194442 interface.]
195443 </tp:docstring>
276524 <property name="LocalCredentials" tp:name-for-bindings="Local_Credentials"
277525 type="(ss)" tp:type="Stream_Credentials" access="read">
278526 <tp:docstring>
279 [FIXME]. Change notification is via the
527 The local credentials are sent to the remote site over the
528 signalling protocol. They are used in ICE to make sure that
529 the connectivity checks come from the right peer. Change
530 notification is via the
280531 <tp:member-ref>LocalCredentialsChanged</tp:member-ref> signal.
532
533 This property will be a pair of empty strings if ICE has not yet been
534 started.
281535 </tp:docstring>
282536 </property>
283537
286540 <tp:changed version="0.21.2">renamed from LocalCredentailsSet</tp:changed>
287541 <tp:docstring>
288542 Emitted when the value of
289 <tp:member-ref>LocalCredentials</tp:member-ref> changes.
543 <tp:member-ref>LocalCredentials</tp:member-ref> changes to a non-empty
544 value. This should only happen when the streaming implementation calls
545 <tp:member-ref>SetCredentials</tp:member-ref>, so this signal is
546 mostly useful for debugging.
290547 </tp:docstring>
291548 <arg name="Username" type="s" />
292549 <arg name="Password" type="s" />
332589 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
333590 <p>A list of mappings describing TURN or Google relay servers
334591 available for the client to use in its candidate gathering, as
335 determined from the protocol. Map keys are:</p>
592 determined from the protocol. Well-known map keys are:</p>
336593
337594 <dl>
338595 <dt><code>ip</code> - s</dt>
365622 <dd>The UDP or TCP port of the relay server as an ASCII unsigned
366623 integer</dd>
367624
625 <dt><code>unique-id</code> - s</dt>
626 <dd>A string identifying the relay server. If two RelayInfo entries
627 have the same unique-id, but different <code>type</code>s, there
628 is usually little point in connecting to both. Use
629 <code>priority</code> to determine which version to prefer in this
630 case. Can also be used by the streaming implementation to avoid
631 connecting to the same relay multiple times if relaying is
632 required for both audio and video.</dd>
633
634 <dt><code>priority</code> - u</dt>
635 <dd>A number determining which version of a server to prefer (if
636 multiple are present with the same <code>unique-id</code>,
637 the one with the highest priority should be used, or the streaming
638 implementation should use the one whose <code>type</code> has the
639 most desirable properties)</dd>
640
368641 <dt><code>username</code> - s</dt>
369642 <dd>The username to use</dd>
370643
450723 <property name="Endpoints" tp:name-for-bindings="Endpoints"
451724 type="ao" access="read">
452725 <tp:docstring>
453 <p>The list of <tp:dbus-ref namespace="ofdT.Call.Stream"
454 >Endpoint.DRAFT</tp:dbus-ref> objects that exist for this
726 <p>The list of <tp:dbus-ref namespace="ofdT.Call1.Stream"
727 >Endpoint</tp:dbus-ref> objects that exist for this
455728 stream.</p>
456729
457730 <p>Change notification is via the
459732 </tp:docstring>
460733 </property>
461734
462 <signal name="PleaseRestartICE"
463 tp:name-for-bindings="Please_Restart_ICE">
464 <tp:docstring>
465 Emitted when the CM does an ICE restart to notify the
466 streaming implementation that it should call
735 <signal name="ICERestartRequested"
736 tp:name-for-bindings="ICE_Restart_Requested">
737 <tp:docstring>
738 Emitted when the remote side requests an ICE restart (e.g. third party
739 call control, when the remote endpoint changes). The streaming
740 implementation should call
467741 <tp:member-ref>SetCredentials</tp:member-ref> again.
468742 </tp:docstring>
469743 </signal>
744
745 <property name="ICERestartPending"
746 tp:name-for-bindings="ICE_Restart_Pending" access="read" type="b">
747 <tp:docstring>
748 State recovery for <tp:member-ref>ICERestartRequested</tp:member-ref>.
749 Set when the signal is emitted, and unset when
750 <tp:member-ref>SetCredentials</tp:member-ref> is called.
751 Useful for debugging.
752 </tp:docstring>
753 </property>
754
755 <method name="Fail" tp:name-for-bindings="Fail">
756 <tp:docstring>
757 Signal an unrecoverable error for this stream, and remove it. If all
758 streams are removed from a content, then it will also be removed.
759 </tp:docstring>
760 <arg direction="in" name="Reason" type="(uuss)"
761 tp:type="Call_State_Reason">
762 <tp:docstring>
763 A structured reason for stream removal.
764 </tp:docstring>
765 </arg>
766 </method>
470767 </interface>
471768 </node>
472769 <!-- vim:set sw=2 sts=2 et ft=xml: -->
+2
-2
spec/Channel_Interface_DTMF.xml less more
2020 <interface name="org.freedesktop.Telepathy.Channel.Interface.DTMF">
2121 <tp:xor-requires>
2222 <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>
23 <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Call.DRAFT"/>
23 <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Call1"/>
2424 </tp:xor-requires>
2525 <tp:changed version="0.19.6">The <tp:type>Stream_ID</tp:type>s in this
2626 interface should now be ignored by CMs. This is primarily to allow this
2727 interface to be used with <tp:dbus-ref
28 namespace='ofdT.Channel.Type'>Call.DRAFT</tp:dbus-ref>
28 namespace='ofdT.Channel.Type'>Call1</tp:dbus-ref>
2929 channels.</tp:changed>
3030
3131 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+86
-0
spec/Channel_Interface_Group.xml less more
333333 </tp:docstring>
334334 <tp:added version="0.17.6">This signal should not be relied on
335335 unless Channel_Group_Flag_Properties is present.</tp:added>
336 <tp:deprecated version="0.23.4">Clients should listen to
337 <tp:member-ref>HandleOwnersChangedDetailed</tp:member-ref> instead to
338 get the new identifiers as well.
339 </tp:deprecated>
336340
337341 <arg name="Added" type="a{uu}" tp:type="Handle_Owner_Map">
338342 <tp:docstring>
347351 The channel-specific handles that were removed from the keys of the
348352 HandleOwners property, as a result of the contact leaving this group
349353 in a previous <tp:member-ref>MembersChanged</tp:member-ref> signal
354 </tp:docstring>
355 </arg>
356 </signal>
357
358 <signal name="HandleOwnersChangedDetailed"
359 tp:name-for-bindings="Handle_Owners_Changed_Detailed">
360 <tp:docstring>
361 <p>Emitted whenever the <tp:member-ref>HandleOwners</tp:member-ref>
362 property changes.</p>
363
364 <p>Clients can assume this signal is emitted by the Connection Manager
365 if the <tp:member-ref>MemberIdentifiers</tp:member-ref> property exists
366 </p>
367 </tp:docstring>
368 <tp:added version="0.23.4"/>
369
370 <arg name="Added" type="a{uu}" tp:type="Handle_Owner_Map">
371 <tp:docstring>
372 A map from channel-specific handles to their owners, in which the
373 keys include all the handles that were added to the keys of the
374 HandleOwners property, and all the handles in that property whose
375 owner has changed
376 </tp:docstring>
377 </arg>
378 <arg name="Removed" type="au" tp:type="Contact_Handle[]">
379 <tp:docstring>
380 The channel-specific handles that were removed from the keys of the
381 HandleOwners property, as a result of the contact leaving this group
382 in a previous <tp:member-ref>MembersChanged</tp:member-ref> signal
383 </tp:docstring>
384 </arg>
385 <arg name="Identifiers" type="a{us}" tp:type="Handle_Identifier_Map">
386 <tp:docstring>
387 The string identifiers for handles mentioned in this signal, to
388 give clients the minimal information necessary to create contacts
389 without waiting for round-trips. Connection managers MUST include at
390 least the identifiers for all handles in the Added map, and MAY
391 include those from Removed array.
350392 </tp:docstring>
351393 </arg>
352394 </signal>
518560 </tp:docstring>
519561 <tp:added version="0.17.6">This signal should not be relied on
520562 unless Channel_Group_Flag_Properties is present.</tp:added>
563 <tp:deprecated version="0.23.4">Clients should listen to
564 <tp:member-ref>SelfContactChanged</tp:member-ref> instead to get the new
565 identifier as well.
566 </tp:deprecated>
521567
522568 <arg type="u" tp:type="Contact_Handle" name="Self_Handle">
523569 <tp:docstring>
524570 The new value of the SelfHandle property.
571 </tp:docstring>
572 </arg>
573 </signal>
574
575 <signal name="SelfContactChanged" tp:name-for-bindings="Self_Contact_Changed">
576 <tp:docstring>
577 <p>Emitted whenever the <tp:member-ref>SelfHandle</tp:member-ref> property
578 changes.</p>
579
580 <p>Clients can assume this signal is emitted by the Connection Manager
581 if the <tp:member-ref>MemberIdentifiers</tp:member-ref> property exists.
582 </p>
583 </tp:docstring>
584 <tp:added version="0.23.4"/>
585
586 <arg type="u" tp:type="Contact_Handle" name="Self_Handle">
587 <tp:docstring>
588 The new value of the SelfHandle property.
589 </tp:docstring>
590 </arg>
591 <arg type="s" name="Self_ID">
592 <tp:docstring>
593 The new value of the SelfHandle property's identifier.
525594 </tp:docstring>
526595 </arg>
527596 </signal>
542611 <tp:added version="0.17.6">For backwards compatibility,
543612 clients should fall back to calling GetSelfHandle if
544613 Channel_Group_Flag_Properties is not present.</tp:added>
614 </property>
615
616 <property name="MemberIdentifiers" type="a{us}" tp:type="Handle_Identifier_Map"
617 access="read" tp:name-for-bindings="Member_Identifiers">
618 <tp:docstring>
619 The string identifiers for handles mentioned in this channel, to
620 give clients the minimal information necessary to create contacts
621 without waiting for round-trips. Connection managers MUST include at
622 least the identifiers for
623 <tp:member-ref>SelfHandle</tp:member-ref>,
624 <tp:member-ref>Members</tp:member-ref>,
625 <tp:member-ref>LocalPendingMembers</tp:member-ref> (and their actors if
626 any),
627 <tp:member-ref>RemotePendingMembers</tp:member-ref> and
628 <tp:member-ref>HandleOwners</tp:member-ref>.
629 </tp:docstring>
630 <tp:added version="0.23.4"/>
545631 </property>
546632
547633 <method name="GetSelfHandle" tp:name-for-bindings="Get_Self_Handle">
+13
-3
spec/Channel_Interface_Hold.xml less more
2121 <interface name="org.freedesktop.Telepathy.Channel.Interface.Hold">
2222 <tp:xor-requires>
2323 <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>
24 <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Call.DRAFT"/>
24 <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Call1"/>
25 <tp:requires interface="org.freedesktop.Telepathy.Call1.Content"/>
2526 </tp:xor-requires>
2627 <tp:changed version="0.17.4">first API-stable version</tp:changed>
2728
3031 This only makes sense for channels where
3132 you are streaming media to or from the members. (To see whether the
3233 other participant has put you on hold, see <tp:dbus-ref
33 namespace="org.freedesktop.Telepathy.Channel.Interface">CallState</tp:dbus-ref>.)</p>
34 namespace="org.freedesktop.Telepathy.Channel.Interface"
35 >CallState</tp:dbus-ref>.)</p>
3436
3537 <p>If you place a channel on hold, this indicates that you do not wish
3638 to be sent media streams by any of its members and will be ignoring
3941 an actively used channel (e.g. in a GSM or PBX call, it will be
4042 necessary to place an active call on hold before you can start
4143 another call).</p>
44
45 <p>This can also be used for putting a single Content on hold, if the
46 protocol supports it (This interface is in the Channel namespace for
47 historical reasons).</p>
4248 </tp:docstring>
4349
4450 <method name="GetHoldState" tp:name-for-bindings="Get_Hold_State">
106112 The connection manager is attempting to move to state Held, but
107113 has not yet completed that operation. It is unspecified whether
108114 any, all or none of the streams making up the channel are on hold.
115 Examining the Hold state of Call Contents (if applicable) may
116 provide more useful information.
109117 </tp:docstring>
110118 </tp:enumvalue>
111119
112120 <tp:enumvalue value="3" suffix="Pending_Unhold">
113121 <tp:docstring>
114 The connection manager is attempting to move to state Held, but
122 The connection manager is attempting to move to state Unheld, but
115123 has not yet completed that operation. It is unspecified whether
116124 any, all or none of the streams making up the channel are on hold.
125 Examining the Hold state of Call Contents (if applicable) may
126 provide more useful information.
117127 </tp:docstring>
118128 </tp:enumvalue>
119129 </tp:enum>
+1
-1
spec/Channel_Interface_Messages.xml less more
10461046 recipient. If a delivery failure is detected later, this is
10471047 signalled by receiving a message whose <code>message-type</code>
10481048 header maps to
1049 <tp:type>Channel_Text_Message_Type</tp:type>_Delivery_Report.
1049 <tp:value-ref type="Channel_Text_Message_Type">Delivery_Report</tp:value-ref>.
10501050 Similarly, if delivery is detected to have been successful
10511051 (which is not possible in all protocols), a successful delivery
10521052 report will be signalled.</p>
+3
-3
spec/Channel_Interface_SMS.xml less more
4949 { ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
5050 ...<tp:dbus-ref namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>,<br/>
5151   ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>:
52 <tp:type>Handle_Type</tp:type>_Contact,<br/>
52 <tp:value-ref type="Handle_Type">Contact</tp:value-ref>,<br/>
5353   ...<tp:dbus-ref namespace='ofdT.Channel.Interface'>SMS.Flash</tp:dbus-ref>:
5454 True,<br/>
5555 }</code></blockquote>
7373 ({ ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
7474 ...<tp:dbus-ref namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>,<br/>
7575    ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>:
76 <tp:type>Handle_Type</tp:type>_Contact,<br/>
76 <tp:value-ref type="Handle_Type">Contact</tp:value-ref>,<br/>
7777  },<br/>
7878  [ ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandle</tp:dbus-ref>,
7979 ...<tp:dbus-ref namespace='ofdT.Channel'>TargetID</tp:dbus-ref> ]),<br/>
8181 ({ ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
8282 ...<tp:dbus-ref namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>,<br/>
8383    ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>:
84 <tp:type>Handle_Type</tp:type>_Contact,<br/>
84 <tp:value-ref type="Handle_Type">Contact</tp:value-ref>,<br/>
8585    ...<tp:member-ref>SMSChannel</tp:member-ref>: True,<br/>
8686  },<br/>
8787  [ ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandle</tp:dbus-ref>,
+418
-287
spec/Channel_Type_Call.xml less more
1616 License along with this library; if not, write to the Free Software
1717 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
1818 </tp:license>
19 <interface name="org.freedesktop.Telepathy.Channel.Type.Call.DRAFT"
19 <interface name="org.freedesktop.Telepathy.Channel.Type.Call1"
2020 tp:causes-havoc="experimental">
2121 <tp:added version="0.19.0">(draft 1)</tp:added>
2222
2323 <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
24 <tp:requires
25 interface="org.freedesktop.Telepathy.Call1.Interface.Mute"/>
2426 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
2527 <p>A channel type for making audio and video calls. Call
2628 channels supersede the old <tp:dbus-ref
5153
5254 <h4>Contents</h4>
5355
54 <p><tp:dbus-ref namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref>
56 <p><tp:dbus-ref namespace="ofdT.Call1">Content</tp:dbus-ref>
5557 objects represent the actual media that forms the Call (for
5658 example an audio content and a video content). Calls always
5759 have one or more Content objects associated with them. As a
6163 as the Requestable Channel Classes will document.</p>
6264
6365 <p><tp:dbus-ref
64 namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref> objects have
66 namespace="ofdT.Call1">Content</tp:dbus-ref> objects have
6567 one or more stream associated with them. More information on
6668 these streams and how to maniuplate them can be found on the
67 <tp:dbus-ref namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref>
69 <tp:dbus-ref namespace="ofdT.Call1">Content</tp:dbus-ref>
6870 interface page.</p>
6971
7072 <h4>Outgoing calls</h4>
7678 <pre>
7779 <tp:dbus-ref namespace="ofdT.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>({
7880 ...<tp:dbus-ref namespace="ofdT.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref
79 namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref>,
81 namespace="ofdT.Channel.Type">Call1</tp:dbus-ref>,
8082 ...<tp:dbus-ref namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref>: Contact,
8183 ...<tp:dbus-ref namespace="ofdT.Channel">TargetID</tp:dbus-ref>: 'foo@example.com',
8284 ...<tp:member-ref>InitialAudio</tp:member-ref>: True,
99101
100102 <p>After a new Call channel is requested, the
101103 <tp:member-ref>CallState</tp:member-ref> property will be
102 <tp:type>Call_State</tp:type>_Pending_Initiator. As the local
104 <tp:value-ref type="Call_State">Pending_Initiator</tp:value-ref>. As the local
103105 user is the initiator, the call must be accepted by the handler
104106 by calling the <tp:member-ref>Accept</tp:member-ref> method.
105107 At this point, <tp:member-ref>CallState</tp:member-ref> changes
106 to <tp:type>Call_State</tp:type>_Pending_Receiver which signifies
107 that the call is ringing, waiting for the remote contact to
108 accept the call. All changes to
109 <tp:member-ref>CallState</tp:member-ref> property are signalled
110 using the <tp:member-ref>CallStateChanged</tp:member-ref>
111 signal.</p>
108 to <tp:value-ref type="Call_State">Initialising</tp:value-ref>, which signifies
109 that the call is waiting for the network to do
110 something. When the CM has information indicating that the remote contact has been
111 notified about the call (or immediately if the network is known not to convey such
112 information) it should also change to
113 <tp:value-ref type="Call_State">Ringing</tp:value-ref>. All changes to
114 the <tp:member-ref>CallState</tp:member-ref> property are signalled using
115 the <tp:member-ref>CallStateChanged</tp:member-ref> signal.</p>
112116
113117 <p>When the call is accepted by the remote contact, the
114118 <tp:member-ref>CallStateChanged</tp:member-ref> signal fires
115119 again to show that <tp:member-ref>CallState</tp:member-ref> =
116 <tp:type>Call_State</tp:type>_Accepted.</p>
120 <tp:value-ref type="Call_State">Accepted</tp:value-ref>.</p>
117121
118122 <p>At this point <a
119123 href="http://telepathy.freedesktop.org/doc/telepathy-farstream/">telepathy-farstream</a>
120124 will signal that a pad is available for the handler to show
121 in the user interface.</p>
125 in the user interface. Once media is correctly flowing in both
126 directions, the state will change to
127 <tp:value-ref type="Call_State">Active</tp:value-ref>, to inform the user that they
128 have a correctly working call there is nothing amiss.</p>
122129
123130 <h5>Missed calls</h5>
124131
128135 not do this and rely on the call initiator terminating the call.
129136 A missed call is shown in a Call channel by the
130137 <tp:member-ref>CallState</tp:member-ref> property changing to
131 <tp:type>Call_State</tp:type>_Ended, and the
138 <tp:value-ref type="Call_State">Ended</tp:value-ref>, and the
132139 <tp:member-ref>CallStateReason</tp:member-ref> property changing
133140 to (remote contact,
134 <tp:type>Call_State_Change_Reason</tp:type>_No_Answer, "").</p>
141 <tp:value-ref type="Call_State_Change_Reason">No_Answer</tp:value-ref>, "").</p>
135142
136143 <h5>Rejected calls</h5>
137144
139146 talking to the local user, he or she can reject his or her
140147 incoming call. This will be shown in the Call channel by
141148 <tp:member-ref>CallState</tp:member-ref> changing to
142 <tp:type>Call_State</tp:type>_Ended and the
149 <tp:value-ref type="Call_State">Ended</tp:value-ref> and the
143150 <tp:member-ref>CallStateReason</tp:member-ref> property
144151 changing to (remote contact,
145 <tp:type>Call_State</tp:type>_Change_Reason_User_Requested,
152 <tp:value-ref type="Call_State_Change_Reason">User_Requested</tp:value-ref>,
146153 "org.freedesktop.Telepathy.Error.Rejected").</p>
147154
148155 <h4>Incoming calls</h4>
158165 /org/freedesktop/Telepathy/Connection/foo/bar/foo_40bar_2ecom/CallChannel,
159166 {
160167 ...<tp:dbus-ref namespace="ofdT.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref
161 namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref>,
168 namespace="ofdT.Channel.Type">Call1</tp:dbus-ref>,
162169 ...<tp:dbus-ref namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref>: Contact,
163170 ...<tp:dbus-ref namespace="ofdT.Channel">TargetID</tp:dbus-ref>: 'foo@example.com',
164171 ...<tp:dbus-ref namespace="ofdT.Channel">TargetHandle</tp:dbus-ref>: 42,
185192 The new channel should also be given to telepathy-farstream to
186193 work out how the two participants will connect together.
187194 telepathy-farstream will call the appropriate methods on the call's
188 <tp:dbus-ref namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref>s
195 <tp:dbus-ref namespace="ofdT.Call1">Content</tp:dbus-ref>s
189196 to negotiate codecs and transports.</p>
190197
191198 <p>To pick up the call, the handler should call
192199 <tp:member-ref>Accept</tp:member-ref>. The
193200 <tp:member-ref>CallState</tp:member-ref> property changes to
194 <tp:type>Call_State</tp:type>_Accepted and once media is
201 <tp:value-ref type="Call_State">Accepted</tp:value-ref> and once media is
195202 being transferred, telepathy-farstream will notify the
196203 handler of a new pad to be shown to the local user in the
197 UI</p>
204 UI. Once media is correctly flowing in both directions, the state will
205 change to <tp:value-ref type="Call_State">Active</tp:value-ref>, to inform the user
206 that they have a correctly working call there is nothing amiss.</p>
198207
199208 <p>To reject the call, the handler should call the
200209 <tp:member-ref>Hangup</tp:member-ref> method. The
201210 <tp:member-ref>CallState</tp:member-ref> property will change to
202 <tp:type>Call_State</tp:type>_Ended and the
211 <tp:value-ref type="Call_State">Ended</tp:value-ref> and the
203212 <tp:member-ref>CallStateReason</tp:member-ref> property will
204213 change to (self handle,
205 <tp:type>Call_State_Change_Reason</tp:type>_User_Requested,
214 <tp:value-ref type="Call_State_Change_Reason">User_Requested</tp:value-ref>,
206215 "org.freedesktop.Telepathy.Error.Rejected").</p>
207216
208217 <h4>Ongoing calls</h4>
220229
221230 <blockquote>
222231 <pre><tp:member-ref>AddContent</tp:member-ref>("video",
223 <tp:type>Media_Stream_Type</tp:type>_Video)</pre>
232 <tp:value-ref type="Media_Stream_Type">Video</tp:value-ref>)</pre>
224233 </blockquote>
225234
226235 <p>Assuming no errors, the new video content will be added to
231240
232241 <p>A similar method is used for removing contents from a call,
233242 except that the <tp:dbus-ref
234 namespace="ofdT.Call.Content.DRAFT">Remove</tp:dbus-ref> method
243 namespace="ofdT.Call1.Content">Remove</tp:dbus-ref> method
235244 is on the <tp:dbus-ref
236 namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref> object.</p>
245 namespace="ofdT.Call1">Content</tp:dbus-ref> object.</p>
237246
238247 <h5>Ending the call</h5>
239248
240249 <p>To end the call, the handler should call the
241250 <tp:member-ref>Hangup</tp:member-ref> method. The
242251 <tp:member-ref>CallState</tp:member-ref> property will change to
243 <tp:type>Call_State</tp:type>_Ended and
252 <tp:value-ref type="Call_State">Ended</tp:value-ref> and
244253 <tp:member-ref>CallStateReason</tp:member-ref> will change
245254 to (self handle,
246 <tp:type>Call_State_Change_Reason</tp:type>_User_Requested,
255 <tp:value-ref type="Call_State_Change_Reason">User_Requested</tp:value-ref>,
247256 "org.freedesktop.Telepathy.Error.Cancelled").</p>
248257
249258 <p>If the other participant hangs up first then the
250259 <tp:member-ref>CallState</tp:member-ref> property will change to
251 <tp:type>Call_State</tp:type>_Ended and
260 <tp:value-ref type="Call_State">Ended</tp:value-ref> and
252261 <tp:member-ref>CallStateReason</tp:member-ref> will change
253262 to (remote contact,
254 <tp:type>Call_State_Change_Reason</tp:type>_User_Requested,
263 <tp:value-ref type="Call_State_Change_Reason">User_Requested</tp:value-ref>,
255264 "org.freedesktop.Telepathy.Error.Terminated").</p>
256265
257266 <h4>Multi-party calls</h4>
258
259 [TODO]
260
261 <h4>Call states</h4>
262
263 <p>There are many combinations of the
264 <tp:member-ref>CallState</tp:member-ref> and
265 <tp:member-ref>CallStateReason</tp:member-ref> properties which
266 mean different things. Here is a table to try to make these
267 meanings clearer:</p>
268
269 <table>
270 <tr>
271 <th rowspan="2"><tp:dbus-ref namespace="ofdT.Channel">Requested</tp:dbus-ref></th>
272 <th rowspan="2"><tp:member-ref>CallState</tp:member-ref></th>
273 <th colspan="3"><tp:member-ref>CallStateReason</tp:member-ref></th>
274 <th rowspan="2">Meaning</th>
275 </tr>
276 <tr>
277 <th>Actor</th>
278 <th>Reason</th>
279 <th>DBus_Reason</th>
280 </tr>
281 <!-- Pending_Initiator -->
282 <tr>
283 <td>True</td>
284 <td><tp:type>Call_State</tp:type>_Pending_Initiator</td>
285 <td>Self handle</td>
286 <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
287 <td>""</td>
288 <td>The outgoing call channel is waiting for the local user to call <tp:member-ref>Accept</tp:member-ref>.</td>
289 </tr>
290 <!-- Pending_Receiver -->
291 <tr>
292 <td>True</td>
293 <td><tp:type>Call_State</tp:type>_Pending_Receiver</td>
294 <td>Self handle</td>
295 <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
296 <td>""</td>
297 <td>The outgoing call is waiting for the remote contact to pick up the call.</td>
298 </tr>
299 <tr>
300 <td>False</td>
301 <td><tp:type>Call_State</tp:type>_Pending_Receiver</td>
302 <td>0</td>
303 <td><tp:type>Call_State_Change_Reason</tp:type>_Unknown</td>
304 <td>""</td>
305 <td>The incoming call is waiting for the local user to call <tp:member-ref>Accept</tp:member-ref> on the call.</td>
306 </tr>
307 <!-- Accepted -->
308 <tr>
309 <td>True</td>
310 <td><tp:type>Call_State</tp:type>_Accepted</td>
311 <td>Remote contact handle</td>
312 <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
313 <td>""</td>
314 <td>The remote contact accepted the outgoing call.</td>
315 </tr>
316 <tr>
317 <td>False</td>
318 <td><tp:type>Call_State</tp:type>_Accepted</td>
319 <td>Self handle</td>
320 <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
321 <td>""</td>
322 <td>The local user accepted the incoming call.</td>
323 </tr>
324 <!-- Ended -->
325 <tr>
326 <td>True or False</td>
327 <td><tp:type>Call_State</tp:type>_Ended</td>
328 <td>Self handle</td>
329 <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
330 <td><tp:error-ref>Cancelled</tp:error-ref></td>
331 <td>The local user hung up the incoming or outgoing call.</td>
332 </tr>
333 <tr>
334 <td>True or False</td>
335 <td><tp:type>Call_State</tp:type>_Ended</td>
336 <td>Remote contact handle</td>
337 <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
338 <td><tp:error-ref>Terminated</tp:error-ref></td>
339 <td>The remote contact hung up the incoming or outgoing call.</td>
340 </tr>
341 <tr>
342 <td>True</td>
343 <td><tp:type>Call_State</tp:type>_Ended</td>
344 <td>Remote contact handle</td>
345 <td><tp:type>Call_State_Change_Reason</tp:type>_No_Answer</td>
346 <td>""</td>
347 <td>The outgoing call was not picked up and the call ended.</td>
348 </tr>
349 <tr>
350 <td>False</td>
351 <td><tp:type>Call_State</tp:type>_Ended</td>
352 <td>Remote contact handle</td>
353 <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
354 <td><tp:error-ref>PickedUpElsewhere</tp:error-ref></td>
355 <td>The incoming call was ended because it was picked up elsewhere.</td>
356 </tr>
357 </table>
358267
359268 <h4>Requestable channel classes</h4>
360269
361270 <p>The <tp:dbus-ref
362271 namespace="ofdT.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>
363272 for <tp:dbus-ref
364 namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref> channels
273 namespace="ofdT.Channel.Type">Call1</tp:dbus-ref> channels
365274 can be:</p>
366275
367276 <blockquote>
368277 <pre>
369 [( Fixed = { ...<tp:dbus-ref namespace="ofdT.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref>,
278 [( Fixed = { ...<tp:dbus-ref namespace="ofdT.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="ofdT.Channel.Type">Call1</tp:dbus-ref>,
370279 ...<tp:dbus-ref namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref>: Contact,
371280 ...<tp:member-ref>InitialVideo</tp:member-ref>: True
372281 },
375284 ...<tp:member-ref>InitialAudioName</tp:member-ref>
376285 ]
377286 ),
378 ( Fixed = { ...<tp:dbus-ref namespace="ofdT.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref>,
287 ( Fixed = { ...<tp:dbus-ref namespace="ofdT.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="ofdT.Channel.Type">Call1</tp:dbus-ref>,
379288 ...<tp:dbus-ref namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref>: Contact,
380289 ...<tp:member-ref>InitialAudio</tp:member-ref>: True
381290 },
392301 class, and vice versa for CMs without audio support.</p>
393302
394303 <p>Handlers should not close <tp:dbus-ref
395 namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref> channels
304 namespace="ofdT.Channel.Type">Call1</tp:dbus-ref> channels
396305 without first calling <tp:member-ref>Hangup</tp:member-ref> on
397306 the channel. If a Call handler crashes, the <tp:dbus-ref
398307 namespace="ofdT">ChannelDispatcher</tp:dbus-ref> will call
399308 <tp:dbus-ref namespace="ofdT.Channel">Close</tp:dbus-ref> on the
400309 channel which SHOULD also imply a call to
401 <tp:member-ref>Hangup</tp:member-ref>(<tp:type>Call_State_Change_Reason</tp:type>_User_Requested,
310 <tp:member-ref>Hangup</tp:member-ref>(<tp:value-ref type="Call_State_Change_Reason">User_Requested</tp:value-ref>,
402311 "org.freedesktop.Telepathy.Error.Terminated", "") before
403312 actually closing the channel.</p>
404313
414323 channel's <tp:dbus-ref namespace="ofdT.Channel">Requested</tp:dbus-ref>
415324 property is False, and
416325 the <tp:member-ref>CallState</tp:member-ref> is
417 <tp:type>Call_State</tp:type>_Pending_Receiver (an incoming
418 call waiting on the local user to pick up). While this is
419 the case, this method SHOULD change the
420 <tp:member-ref>CallFlags</tp:member-ref> to include
421 <tp:type>Call_Flags</tp:type>_Locally_Ringing, and notify the
326 <tp:value-ref type="Call_State">Ringing</tp:value-ref> (an incoming
327 call is ready and waiting for the user to be notified). Calling this method
328 SHOULD set <tp:member-ref>CallFlags</tp:member-ref>' bit
329 <tp:value-ref type="Call_Flags">Locally_Ringing</tp:value-ref>, and notify the
422330 remote contact that the local user has been alerted (if the
423 protocol implements this); repeated calls to this method
331 protocol supports this); repeated calls to this method
424332 SHOULD succeed, but have no further effect.</p>
425333
426334 <p>In all other states, this method SHOULD fail with the error
437345 <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
438346 <tp:docstring>
439347 The call is no longer in state
440 <tp:type>Call_State</tp:type>_Pending_Receiver.
348 <tp:value-ref type="Call_State">Ringing</tp:value-ref>.
441349 </tp:docstring>
442350 </tp:error>
443351 </tp:possible-errors>
444352 </method>
445353
354 <method name="SetQueued" tp:name-for-bindings="Set_Queued">
355 <tp:changed version="0.21.2">renamed from Ringing</tp:changed>
356 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
357 <p>Notifies the CM that the local user is already in a call, so this
358 call has been put in a call-waiting style queue.</p>
359
360 <p>This method is only useful if the
361 channel's <tp:dbus-ref namespace="ofdT.Channel">Requested</tp:dbus-ref>
362 property is False, and
363 the <tp:member-ref>CallState</tp:member-ref> is
364 <tp:value-ref type="Call_State">Initialising</tp:value-ref> or
365 <tp:value-ref type="Call_State">Ringing</tp:value-ref>. Calling this method
366 SHOULD set <tp:member-ref>CallFlags</tp:member-ref>' bit
367 <tp:value-ref type="Call_Flags">Locally_Queued</tp:value-ref>, and notify the
368 remote contact that the call is in a queue (if the
369 protocol supports this); repeated calls to this method
370 SHOULD succeed, but have no further effect.</p>
371
372 <p>Locally_Queued is a little like Locally_Held, but applies to calls that have not
373 been Accepted (the Locally_Queued flag should be unset by the CM when Accept
374 is called). It should also be set in response to the state of the
375 world, rather than in response to user action.</p>
376 </tp:docstring>
377
378 <tp:possible-errors>
379 <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
380 <tp:docstring>
381 The call was <tp:dbus-ref namespace="ofdT.Channel"
382 >Requested</tp:dbus-ref>, so ringing does not make sense.
383 </tp:docstring>
384 </tp:error>
385 <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
386 <tp:docstring>
387 The call is no longer in state
388 <tp:value-ref type="Call_State">Initialising</tp:value-ref> or _Ringing.
389 </tp:docstring>
390 </tp:error>
391 </tp:possible-errors>
392 </method>
393
446394 <method name="Accept" tp:name-for-bindings="Accept">
447395 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
448396 <p>For incoming calls in state
449 <tp:type>Call_State</tp:type>_Pending_Receiver, accept the
450 incoming call; this changes the
451 <tp:member-ref>CallState</tp:member-ref> to
452 <tp:type>Call_State</tp:type>_Accepted.</p>
397 <tp:value-ref type="Call_State">Ringing</tp:value-ref>, accept the incoming call.
398 This changes the <tp:member-ref>CallState</tp:member-ref> to
399 <tp:value-ref type="Call_State">Accepted</tp:value-ref>.</p>
453400
454401 <p>For outgoing calls in state
455 <tp:type>Call_State</tp:type>_Pending_Initiator, actually
402 <tp:value-ref type="Call_State">Pending_Initiator</tp:value-ref>, actually
456403 call the remote contact; this changes the
457404 <tp:member-ref>CallState</tp:member-ref> to
458 <tp:type>Call_State</tp:type>_Pending_Receiver.</p>
405 <tp:value-ref type="Call_State">Initialising</tp:value-ref>.</p>
459406
460407 <p>Otherwise, this method SHOULD fail with the error NotAvailable.</p>
461408
463410 client (user interface) is handling the channel.</p>
464411
465412 <p>When this method is called, for each <tp:dbus-ref
466 namespace="ofdT.Call" >Content.DRAFT</tp:dbus-ref> whose
467 <tp:dbus-ref namespace="ofdT.Call.Content.DRAFT"
413 namespace="ofdT.Call1" >Content</tp:dbus-ref> whose
414 <tp:dbus-ref namespace="ofdT.Call1.Content"
468415 >Disposition</tp:dbus-ref> is
469 <tp:type>Call_Content_Disposition</tp:type>_Initial, any
416 <tp:value-ref type="Call_Content_Disposition">Initial</tp:value-ref>, any
470417 streams where the <tp:dbus-ref
471 namespace="ofdT.Call.Stream.DRAFT">LocalSendingState</tp:dbus-ref>
472 is <tp:type>Sending_State</tp:type>_Pending_Send will be
473 moved to <tp:type>Sending_State</tp:type>_Sending as if
474 <tp:dbus-ref namespace="ofdT.Call.Stream.DRAFT"
418 namespace="ofdT.Call1.Stream">LocalSendingState</tp:dbus-ref>
419 is <tp:value-ref type="Sending_State">Pending_Send</tp:value-ref> will be
420 moved to <tp:value-ref type="Sending_State">Sending</tp:value-ref> as if
421 <tp:dbus-ref namespace="ofdT.Call1.Stream"
475422 >SetSending</tp:dbus-ref>(True) had been called.</p>
476423 </tp:docstring>
477424
530477 <method name="AddContent" tp:name-for-bindings="Add_Content">
531478 <tp:docstring>
532479 Request that a new <tp:dbus-ref
533 namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref> of type
534 Content_Type is added to the Call. Handlers should check the
480 namespace="ofdT.Call1">Content</tp:dbus-ref> of type
481 Content_Type is added to the Call1. Handlers should check the
535482 value of the <tp:member-ref>MutableContents</tp:member-ref>
536483 property before trying to add another content as it might not
537484 be allowed.
568515 <tp:docstring>
569516 Path to the newly-created <tp:dbus-ref
570517 namespace="org.freedesktop.Telepathy"
571 >Call.Content.DRAFT</tp:dbus-ref> object.
518 >Call1.Content</tp:dbus-ref> object.
572519 </tp:docstring>
573520 </arg>
574521
582529 <tp:docstring>
583530 The media stream type requested is not implemented by the
584531 CM.
532 </tp:docstring>
533 </tp:error>
534 <tp:error name="org.freedesktop.Telepathy.Error.Media.UnsupportedType">
535 <tp:docstring>
536 The media stream type requested is not supported by either the
537 local or remote side.
585538 </tp:docstring>
586539 </tp:error>
587540 <tp:error name="org.freedesktop.Telepathy.Error.NotCapable">
599552 <signal name="ContentAdded"
600553 tp:name-for-bindings="Content_Added">
601554 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
602 <p>Emitted when a new <tp:dbus-ref namespace="ofdT.Call"
603 >Content.DRAFT</tp:dbus-ref> is added to the call.</p>
555 <p>Emitted when a new <tp:dbus-ref namespace="ofdT.Call1"
556 >Content</tp:dbus-ref> is added to the call.</p>
604557 </tp:docstring>
605558 <arg name="Content" type="o">
606559 <tp:docstring>
607 Path to the newly-created <tp:dbus-ref namespace="ofdT.Call"
608 >Content.DRAFT</tp:dbus-ref> object.
560 Path to the newly-created <tp:dbus-ref namespace="ofdT.Call1"
561 >Content</tp:dbus-ref> object.
609562 </tp:docstring>
610563 </arg>
611564 </signal>
612565
613566 <signal name="ContentRemoved" tp:name-for-bindings="Content_Removed">
614567 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
615 <p>Emitted when a <tp:dbus-ref namespace="ofdT.Call"
616 >Content.DRAFT</tp:dbus-ref> is removed from the call.</p>
568 <p>Emitted when a <tp:dbus-ref namespace="ofdT.Call1"
569 >Content</tp:dbus-ref> is removed from the call.</p>
617570 </tp:docstring>
618571 <arg name="Content" type="o">
619572 <tp:docstring>
620 The <tp:dbus-ref namespace="ofdT.Call"
621 >Content.DRAFT</tp:dbus-ref> which was removed.
573 The <tp:dbus-ref namespace="ofdT.Call1"
574 >Content</tp:dbus-ref> which was removed.
575 </tp:docstring>
576 </arg>
577 <arg name="Reason" type="(uuss)" tp:type="Call_State_Reason">
578 <tp:docstring>
579 Why the content was removed.
622580 </tp:docstring>
623581 </arg>
624582 </signal>
627585 tp:name-for-bindings="Contents">
628586 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
629587 <p>The list of <tp:dbus-ref
630 namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref> objects that
588 namespace="ofdT.Call1">Content</tp:dbus-ref> objects that
631589 are part of this call. Change notification is via the
632590 <tp:member-ref>ContentAdded</tp:member-ref> and
633591 <tp:member-ref>ContentRemoved</tp:member-ref> signals.
642600 <p>The allowed transitions are:</p>
643601
644602 <ul>
645 <li>Pending_Initiator → Pending_Receiver (for outgoing calls,
603 <li>Pending_Initiator → Initialising (for outgoing calls,
646604 when <tp:member-ref>Accept</tp:member-ref> is called)</li>
647 <li>Pending_Receiver → Accepted (for incoming calls, when
648 <tp:member-ref>Accept</tp:member-ref> is called; for outgoing
649 calls to a contact, when the remote contact accepts the call;
650 for joining a conference call, when the local user successfully
651 joins the conference)</li>
652 <li>Accepted → Pending_Receiver (when transferred to another
653 contact)</li>
654 <li>any state → Ended (when the call is terminated normally, or
655 when an error occurs)</li>
605 <li>Initialising → Ringing (for outgoing calls, when
606 the remote client indicates that the user has been notified about
607 the call. If the network is known not to provide feedback about whether
608 the remote side is ringing, then the call should immediately be
609 set to Ringing.</li>
610 <li>Initialising → Ringing (for incoming calls, when e.g. the
611 implementation has been initialised far enough that it is sensible
612 to notify the user about the call (to reduce the probability that
613 the user will pick up the call and have it immediately fail).
614 The UI should then alert the user about the call, and call
615 <tp:member-ref>SetRinging</tp:member-ref>)</li>
616 <li>Ringing → Accepted (for outgoing calls to a contact,
617 when the remote contact accepts the call; for incoming calls, when
618 <tp:member-ref>Accept</tp:member-ref> is called.)</li>
619 <li>Accepted → Active (when the local user successfully
620 joins the call/conference, and media is known to be flowing
621 successfully; also, when temporary connection problems are
622 resolved (See below)). If the network is known not to provide
623 feedback about when the call is properly connected, the call
624 should immediately be set to Active.</li>
625 <li>Active → Accepted (when there are temporary connection problems
626 that the CM is aware of and able to recover from)</li>
627 <li>any state → Ended (when the call is terminated
628 normally, or when an error occurs that the CM is unable to recover
629 from)</li>
656630 </ul>
657631
658632 <p>Clients MAY consider unknown values from this enum to be an
660634 specification is declared to be stable.</p>
661635 </tp:docstring>
662636
663 <tp:enumvalue suffix="Unknown" value = "0">
637 <tp:enumvalue suffix="Unknown" value="0">
664638 <tp:docstring>
665639 The call state is not known. This call state MUST NOT appear as a
666640 value of the <tp:member-ref>CallState</tp:member-ref> property, but
668642 unknown.
669643 </tp:docstring>
670644 </tp:enumvalue>
671 <tp:enumvalue suffix="Pending_Initiator" value = "1">
645 <tp:enumvalue suffix="Pending_Initiator" value="1">
672646 <tp:docstring>
673647 The initiator of the call hasn't accepted the call yet. This state
674648 only makes sense for outgoing calls, where it means that the local
677651 called.
678652 </tp:docstring>
679653 </tp:enumvalue>
680 <tp:enumvalue suffix="Pending_Receiver" value = "2">
681 <tp:docstring>
682 The receiver (the contact being called) hasn't accepted the call yet.
683 </tp:docstring>
684 </tp:enumvalue>
685 <tp:enumvalue suffix="Accepted" value = "3">
686 <tp:docstring>
687 The contact being called has accepted the call.
688 </tp:docstring>
689 </tp:enumvalue>
690 <tp:enumvalue suffix="Ended" value = "4">
654 <tp:enumvalue suffix="Initialising" value="2">
655 <tp:docstring>
656 Progress has been made in placing the call, but the
657 contact has not been made aware of the call yet. This corresponds to SIP's
658 status code 183 Session Progress, and should be used for the period
659 where the CM is waiting for the streaming implementation to
660 initialise (before sending the initial INVITE or equivalent) and when the
661 outgoing call has reached a gateway or ICE negotiation is pending.
662 UIs should not produce a dialtone or start ringing if the call is in
663 this state.
664 </tp:docstring>
665 </tp:enumvalue>
666 <tp:enumvalue suffix="Ringing" value="3">
667 <tp:docstring>
668 In the outgoing case: at least one called user has been alerted
669 about the call (a SIP 180 (Ringing) packet or equivalent has been
670 received) but none have answered, so the call cannot go to Accepted
671 (use <tp:value-ref type="Call_Member_Flags">Ringing</tp:value-ref> to determine which
672 members have been informed and which haven't, if you care). UIs
673 SHOULD produce a dialtone for outgoing calls in this state.
674
675 In the incoming case, the local user should be informed of the call
676 as soon as the call reaches this state (and
677 <tp:member-ref>SetRinging</tp:member-ref> should be called
678 to inform the CM that this has happened, so that it can relay this
679 fact to the caller using a SIP 180 (Ringing) packet or equivalent).
680 </tp:docstring>
681 </tp:enumvalue>
682 <tp:enumvalue suffix="Accepted" value="4">
683 <tp:docstring>
684 The contact being called has accepted the call, but the call is not
685 in the Active state (The most common reason for this is that the
686 streaming implementation hasn't connected yet).
687 </tp:docstring>
688 </tp:enumvalue>
689 <tp:enumvalue suffix="Active" value="5">
690 <tp:docstring>
691 The contact being called has accepted the call, and discourse between
692 at least two parties should now be possible.
693 </tp:docstring>
694 </tp:enumvalue>
695 <tp:enumvalue suffix="Ended" value="6">
691696 <tp:docstring>
692697 The call has ended, either via normal termination or an error.
693698 </tp:docstring>
696701
697702 <tp:flags name="Call_Flags" value-prefix="Call_Flag" type="u">
698703 <tp:docstring>
699 A set of flags representing the status of the call as a whole,
700 providing more specific information than the
701 <tp:member-ref>CallState</tp:member-ref>. Many of these flags only make
702 sense in a particular state.
703 </tp:docstring>
704
705 <tp:flag suffix="Locally_Ringing" value="1">
706 <tp:docstring>
707 The local contact has been alerted about the call but has not
708 responded; if possible, the remote contact(s) have been informed of
709 this fact. This flag only makes sense on incoming calls in
710 state <tp:type>Call_State</tp:type>_Pending_Receiver. It SHOULD
711 be set when <tp:member-ref>SetRinging</tp:member-ref> is
712 called successfully, and unset when the state changes.
713 </tp:docstring>
714 </tp:flag>
715
716 <tp:flag suffix="Queued" value="2">
717 <tp:docstring>
718 The contact is temporarily unavailable, and the call has been placed
719 in a queue (e.g. 182 Queued in SIP, or call-waiting in telephony).
720 This flag only makes sense on outgoing 1-1 calls in
721 state <tp:type>Call_State</tp:type>_Pending_Receiver. It SHOULD be
722 set or unset according to informational messages from other
723 contacts.
724 </tp:docstring>
725 </tp:flag>
726
727 <tp:flag suffix="Locally_Held" value="4">
704 A set of flags representing additional information than is available
705 in <tp:member-ref>CallState</tp:member-ref>. Many of these flags only make
706 sense in a particular (or may explain why a call is in a specific
707 state).
708 </tp:docstring>
709 <tp:flag suffix="Locally_Held" value="1">
728710 <tp:docstring>
729711 The call has been put on hold by the local user, e.g. using
730712 the <tp:dbus-ref namespace="ofdT.Channel.Interface"
731713 >Hold</tp:dbus-ref> interface. This flag SHOULD only be set
732714 if there is at least one Content, and all Contents are
733 locally held; it makes sense on calls in state
734 <tp:type>Call_State</tp:type>_Pending_Receiver
735 or <tp:type>Call_State</tp:type>_Accepted.
715 locally held.
736716
737717 <tp:rationale>
738718 Otherwise, in transient situations where some but not all contents
740720 is on hold, which could lead to the user saying something they'll
741721 regret, while under the impression that the other contacts can't
742722 hear them!
723
724 This flag exists as a simplified proxy for <tp:dbus-ref
725 namespace="ofdT.Channel.Interface.Hold"
726 >HoldStateChanged</tp:dbus-ref>,
727 to reduce the number of signals that need to be
728 listened to by a simple UI.
743729 </tp:rationale>
744730 </tp:docstring>
745731 </tp:flag>
746732
747 <tp:flag suffix="Forwarded" value="8">
733 <tp:flag suffix="Locally_Muted" value="2">
734 <tp:docstring>
735 The call has been muted by the local user, e.g. using the
736 <tp:dbus-ref namespace="ofdT.Call1.Interface"
737 >Mute</tp:dbus-ref> interface. This flag SHOULD only
738 be set if there is at least one Content, and all Contents
739 are locally muted (for the same reason as Locally_Held).
740
741 <tp:rationale>
742 This flag exists to provide a simplified verson of <tp:dbus-ref
743 namespace="ofdT.Call1.Interface.Mute"
744 >MuteStateChanged</tp:dbus-ref>,
745 to reduce the number of signals that need to be
746 listened to by a simple UI.
747 </tp:rationale>
748 </tp:docstring>
749 </tp:flag>
750
751 <tp:flag suffix="Locally_Ringing" value="4">
752 <tp:docstring>
753 This flag exists for observability of the
754 <tp:member-ref>SetRinging</tp:member-ref> method (e.g. so that
755 loggers can tell whether the call got as far as alerting the user,
756 or whether something went wrong before then). It should be set when
757 the SetRinging is called, and unset when the call leaves
758 <tp:value-ref type="Call_State">Ringing</tp:value-ref>.
759 </tp:docstring>
760 </tp:flag>
761
762 <tp:flag suffix="Locally_Queued" value="8">
763 <tp:docstring>
764 This flag exists for observability of the
765 <tp:member-ref>SetQueued</tp:member-ref> method. It should be set
766 when the SetQueued is called, and unset when the call leaves
767 <tp:value-ref type="Call_State">Ringing</tp:value-ref>.
768 </tp:docstring>
769 </tp:flag>
770
771 <tp:flag suffix="Forwarded" value="16">
748772 <tp:docstring>
749773 The initiator of the call originally called a contact other than the
750774 current recipient of the call, but the call was then forwarded or
751 diverted. This flag only makes sense on outgoing calls, in state
752 <tp:type>Call_State</tp:type>_Pending_Receiver or
753 <tp:type>Call_State</tp:type>_Accepted. It SHOULD be set or unset
754 according to informational messages from other contacts.
755 </tp:docstring>
756 </tp:flag>
757
758 <tp:flag suffix="In_Progress" value="16">
759 <tp:docstring>
760 Progress has been made in placing the outgoing call, but the
761 contact may not have been made aware of the call yet
762 (so the Ringing state is not appropriate). This corresponds to SIP's
763 status code 183 Session Progress, and could be used when the
764 outgoing call has reached a gateway, for instance.
765 This flag only makes sense on outgoing calls in state
766 <tp:type>Call_State</tp:type>_Pending_Receiver, and SHOULD be set
767 or unset according to informational messages from servers, gateways
768 and other infrastructure.
775 diverted. This flag only makes sense on outgoing calls. It SHOULD be
776 set or unset according to informational messages from other
777 contacts.
769778 </tp:docstring>
770779 </tp:flag>
771780
786795 </tp:docstring>
787796 </tp:flag>
788797
789 <tp:flag suffix="Muted" value="64">
790 <tp:docstring>
791 The call has been muted by the local user, e.g. using the
792 <tp:dbus-ref namespace="ofdT.Call.Content.Interface"
793 >Mute.DRAFT</tp:dbus-ref> interface. This flag SHOULD only
794 be set if there is at least one Content, and all Contents
795 are locally muted; it makes sense on calls in state
796 <tp:type>Call_State</tp:type>_Pending_Receiver or
797 <tp:type>Call_State</tp:type>_Accepted.
798 </tp:docstring>
799 </tp:flag>
800798 </tp:flags>
801799
802800 <property name="CallStateDetails"
814812 <dd>An optional human-readable message sent when the call was ended,
815813 corresponding to the Message argument to the
816814 <tp:member-ref>Hangup</tp:member-ref> method. This is only
817 applicable when the call state is <tp:type>Call_State</tp:type>_Ended.
815 applicable when the call state is <tp:value-ref type="Call_State">Ended</tp:value-ref>.
818816 <tp:rationale>
819817 XMPP Jingle can send such messages.
820818 </tp:rationale>
823821 <dt>queue-message - s</dt>
824822 <dd>An optional human-readable message sent when the local contact
825823 is being held in a queue. This is only applicable when
826 <tp:type>Call_Flags</tp:type>_Queued is in the call flags.
824 <tp:value-ref type="Call_Flags">Locally_Queued</tp:value-ref> is in the call flags.
827825 <tp:rationale>
828826 SIP 182 notifications can have human-readable messages attached.
829827 </tp:rationale>
834832 <tp:member-ref>CallStateReason</tp:member-ref>. This will not
835833 normally be localized or suitable for display to users, and is only
836834 applicable when the call state is
837 <tp:type>Call_State</tp:type>_Ended.</dd>
835 <tp:value-ref type="Call_State">Ended</tp:value-ref>.</dd>
838836
839837 <dt>balance-required - i</dt>
840838 <dd>Optionally included when a call cannot be connected because
897895 </tp:docstring>
898896 </tp:enumvalue>
899897
900 <tp:enumvalue suffix="User_Requested" value="1">
898 <tp:enumvalue suffix="Progress_Made" value="1">
899 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
900 Situation normal. Progress has been made in the setup/teardown of
901 the call (and it didn't require any user interaction).
902 </tp:docstring>
903 </tp:enumvalue>
904
905 <tp:enumvalue suffix="User_Requested" value="2">
901906 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
902907 <p>The change was requested by the contact indicated by the Actor
903908 member of a <tp:type>Call_State_Reason</tp:type> struct.</p>
912917 </tp:docstring>
913918 </tp:enumvalue>
914919
915 <tp:enumvalue suffix="Forwarded" value="2">
920 <tp:enumvalue suffix="Forwarded" value="3">
916921 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
917922 <p>The call was forwarded. If known, the handle of the contact
918923 the call was forwarded to will be indicated by the Actor member
920925 </tp:docstring>
921926 </tp:enumvalue>
922927
923 <tp:enumvalue suffix="No_Answer" value="3">
928 <tp:enumvalue suffix="Rejected" value="4">
924929 <tp:added version="0.21.2"/>
925930 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
926931 <p>The <tp:member-ref>CallState</tp:member-ref> changed from
927 <tp:type>Call_State</tp:type>_Pending_Receiver to
928 <tp:type>Call_State</tp:type>_Ended because the initiator
932 <tp:value-ref type="Call_State">Ringing</tp:value-ref> or
933 <tp:value-ref type="Call_State">Ended</tp:value-ref> (or a content's direction
934 changed) because it was rejected by the remote user.</p>
935 <p>Corresponds to <tp:error-ref>Rejected</tp:error-ref></p>
936 </tp:docstring>
937 </tp:enumvalue>
938
939 <tp:enumvalue suffix="No_Answer" value="5">
940 <tp:added version="0.21.2"/>
941 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
942 <p>The <tp:member-ref>CallState</tp:member-ref> changed from
943 <tp:value-ref type="Call_State">Ringing</tp:value-ref> or
944 <tp:value-ref type="Call_State">Ended</tp:value-ref> because the initiator
929945 ended the call before the receiver accepted it. With an
930946 incoming call this state change reason signifies a missed
931 call.</p>
947 call, or one that was picked up elsewhere before it was
948 picked up here.</p>
949 <p>Corresponds to <tp:error-ref>NoAnswer</tp:error-ref> or
950 <tp:error-ref>PickedUpElsewhere</tp:error-ref></p>
951 </tp:docstring>
952 </tp:enumvalue>
953
954 <tp:enumvalue suffix="Invalid_Contact" value="6">
955 <tp:added version="0.21.2"/>
956 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
957 <p>The <tp:member-ref>CallState</tp:member-ref> changed because one
958 of the addresses does not exist on the network.</p>
959 <p>Corresponds to <tp:error-ref>DoesNotExist</tp:error-ref></p>
960 </tp:docstring>
961 </tp:enumvalue>
962
963 <tp:enumvalue suffix="Permission_Denied" value="7">
964 <tp:added version="0.21.2"/>
965 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
966 <p>The <tp:member-ref>CallState</tp:member-ref> changed because the
967 local user is not authorised.</p>
968 <p>Corresponds to <tp:error-ref>PermissionDenied</tp:error-ref> or
969 <tp:error-ref>InsufficientBalance</tp:error-ref>
970 </p>
971 </tp:docstring>
972 </tp:enumvalue>
973
974 <tp:enumvalue suffix="Busy" value="8">
975 <tp:added version="0.21.2"/>
976 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
977 <p>The <tp:member-ref>CallState</tp:member-ref> changed from
978 <tp:value-ref type="Call_State">Ringing</tp:value-ref>
979 <tp:value-ref type="Call_State">Ended</tp:value-ref> because the receiver is busy
980 (e.g. is already engaged in another call, and has not placed the
981 initiator in a call-waiting queue).</p>
982 <p>Corresponds to <tp:error-ref>Busy</tp:error-ref></p>
983 </tp:docstring>
984 </tp:enumvalue>
985
986 <tp:enumvalue suffix="Internal_Error" value="9">
987 <tp:added version="0.21.2"/>
988 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
989 <p>There has been an unexpected error in either the CM or some other
990 local component.</p>
991 <p>Corresponds to <tp:error-ref>Confused</tp:error-ref> or
992 <tp:error-ref>Media.StreamingError</tp:error-ref>
993 </p>
994 </tp:docstring>
995 </tp:enumvalue>
996
997 <tp:enumvalue suffix="Service_Error" value="10">
998 <tp:added version="0.21.2"/>
999 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
1000 <p>There has been an unexpected error in the server or some other
1001 remote component.</p>
1002 <p>Corresponds to
1003 <tp:error-ref>ServiceConfused</tp:error-ref>
1004 </p>
1005 </tp:docstring>
1006 </tp:enumvalue>
1007
1008 <tp:enumvalue suffix="Network_Error" value="11">
1009 <tp:added version="0.21.2"/>
1010 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
1011 <p>There has been a network error related to the CM or the
1012 signalling part of the call (compare and contrast:
1013 Streaming_Error).</p>
1014 <p>Corresponds to
1015 <tp:error-ref>NetworkError</tp:error-ref></p>
1016 </tp:docstring>
1017 </tp:enumvalue>
1018
1019 <tp:enumvalue suffix="Media_Error" value="12">
1020 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
1021 <p>Some aspect of the content is unsupported so has to be
1022 removed from the call.</p>
1023 <p>Corresponds to <tp:error-ref>Media.UnsupportedType</tp:error-ref>
1024 or <tp:error-ref>Media.CodecsIncompatible</tp:error-ref>
1025 </p>
1026 </tp:docstring>
1027 </tp:enumvalue>
1028
1029 <tp:enumvalue suffix="Connectivity_Error" value="13">
1030 <tp:docstring>
1031 <p>It was not possible for the streaming implementation to connect
1032 to any of the users participating in this call or content.</p>
1033 <p>Corresponds to <tp:error-ref>ConnectionFailed</tp:error-ref> or
1034 <tp:error-ref>ConnectionLost</tp:error-ref></p>
9321035 </tp:docstring>
9331036 </tp:enumvalue>
9341037 </tp:enum>
9511054 <tp:docstring>
9521055 The reason, chosen from a limited set of possibilities defined by
9531056 the Telepathy specification. If
954 <tp:type>Call_State_Change_Reason</tp:type>_User_Requested then
1057 <tp:value-ref type="Call_State_Change_Reason">User_Requested</tp:value-ref> then
9551058 the Actor member will dictate whether it was the local user or
9561059 a remote contact responsible.
9571060 </tp:docstring>
9771080 </tp:rationale>
9781081 </tp:docstring>
9791082 </tp:member>
1083
1084 <tp:member type="s" name="Message">
1085 <tp:docstring>
1086 An optional debug message, to expediate debugging the potentially
1087 many processes involved in a call. This may be communicated across
1088 the network in protocols that support doing so, but it is not
1089 essential.
1090 </tp:docstring>
1091 </tp:member>
9801092 </tp:struct>
9811093
9821094 <property name="CallStateReason" tp:name-for-bindings="Call_State_Reason"
983 type="(uus)" access="read" tp:type="Call_State_Reason">
1095 type="(uuss)" access="read" tp:type="Call_State_Reason">
9841096 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
9851097 <p>The reason for the last change to the
9861098 <tp:member-ref>CallState</tp:member-ref> and/or
10141126 </tp:docstring>
10151127 </arg>
10161128
1017 <arg name="Call_State_Reason" type="(uus)" tp:type="Call_State_Reason">
1129 <arg name="Call_State_Reason" type="(uuss)" tp:type="Call_State_Reason">
10181130 <tp:docstring>
10191131 The new value of the <tp:member-ref>CallStateReason</tp:member-ref>
10201132 property.
10441156
10451157 <p>If this is False, the handler is responsible for doing the actual
10461158 media streaming for at least some contents itself. Those contents
1047 will have the <tp:dbus-ref namespace="ofdT.Call.Content.Interface"
1048 >Media.DRAFT</tp:dbus-ref> interface, to communicate the necessary
1159 will have the <tp:dbus-ref namespace="ofdT.Call1.Content.Interface"
1160 >Media</tp:dbus-ref> interface, to communicate the necessary
10491161 information to a streaming implementation. Connection managers SHOULD
10501162 operate like this, if possible.</p>
10511163
10761188 </tp:rationale>
10771189 </tp:docstring>
10781190
1079 <tp:flag suffix="Ringing" value = "1">
1191 <tp:flag suffix="Ringing" value="1">
10801192 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
10811193 <p>The remote contact's client has told us that the contact has been
10821194 alerted about the call but has not responded.</p>
10891201 </tp:docstring>
10901202 </tp:flag>
10911203
1092 <tp:flag suffix="Held" value = "2">
1204 <tp:flag suffix="Held" value="2">
10931205 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
10941206 <p>The call member has put this call on hold.</p>
10951207
11011213 </tp:docstring>
11021214 </tp:flag>
11031215
1104 <tp:flag suffix="Conference_Host" value="4">
1216 <tp:flag suffix="Muted" value="4">
1217 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
1218 <p>The call member has muted their participation in this call. Note
1219 that many protocols will not signal this flag, so clients should
1220 not rely on it being set.</p>
1221
1222 <tp:rationale>
1223 <p>This is a flag per member, not a flag for the call as a whole,
1224 because in conference calls, any member could mute their own
1225 streams.</p>
1226 </tp:rationale>
1227 </tp:docstring>
1228 </tp:flag>
1229
1230 <tp:flag suffix="Conference_Host" value="8">
11051231 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
11061232 This contact has merged this call into a conference. Note that GSM
11071233 provides a notification when the remote party merges a call into a
11451271 from <tp:member-ref>CallMembers</tp:member-ref>.
11461272 </tp:docstring>
11471273 </arg>
1274 <arg name="Reason" type="(uuss)" tp:type="Call_State_Reason">
1275 <tp:docstring>
1276 A structured reason for the change.
1277 </tp:docstring>
1278 </arg>
11481279 </signal>
11491280
11501281 <property name="CallMembers" tp:name-for-bindings="Call_Members"
11751306 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
11761307 <p>If set on a requested channel, this indicates the transport that
11771308 should be used for this call. Where not applicable, this property
1178 is defined to be <tp:type>Stream_Transport_Type</tp:type>_Unknown,
1309 is defined to be <tp:value-ref type="Stream_Transport_Type">Unknown</tp:value-ref>,
11791310 in particular, on CMs with hardware streaming.</p>
11801311
11811312 <tp:rationale>
11941325 the connection manager should immediately attempt to establish an
11951326 audio stream to the remote contact, making it unnecessary for the
11961327 client to call <tp:dbus-ref
1197 namespace="ofdT.Channel.Type.Call.DRAFT">AddContent</tp:dbus-ref>.</p>
1328 namespace="ofdT.Channel.Type.Call1">AddContent</tp:dbus-ref>.</p>
11981329
11991330 <p>If this property, or InitialVideo, is passed to EnsureChannel
12001331 (as opposed to CreateChannel), the connection manager SHOULD ignore
12091340 <p>If True on an unrequested (incoming) channel, this indicates that
12101341 the remote contact initially requested an audio stream; this does
12111342 not imply that that audio stream is still active (as indicated by
1212 <tp:dbus-ref namespace="ofdT.Channel.Type.Call.DRAFT"
1343 <tp:dbus-ref namespace="ofdT.Channel.Type.Call1"
12131344 >Contents</tp:dbus-ref>).</p>
12141345
12151346 <p>The name of this new content can be decided by using the
13301461 must be requested at the start of the call if video is desired.
13311462 User interfaces may use this pseudo-capability as a hint to
13321463 display separate "Audio call" and "Video call" buttons, rather
1333 than a single "Call" button with the option to add and remove
1464 than a single "Call1" button with the option to add and remove
13341465 video once the call has started for contacts without this flag.
13351466 </p>
13361467 </tp:rationale>
13521483 <tp:hct name="gtalk-p2p">
13531484 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
13541485 <p>The client can implement streaming for streams whose <tp:dbus-ref
1355 namespace="ofdT.Call.Stream.Interface.Media.DRAFT">Transport</tp:dbus-ref>
1356 property is <tp:type>Stream_Transport_Type</tp:type>_GTalk_P2P.</p>
1486 namespace="ofdT.Call1.Stream.Interface.Media">Transport</tp:dbus-ref>
1487 property is <tp:value-ref type="Stream_Transport_Type">GTalk_P2P</tp:value-ref>.</p>
13571488 </tp:docstring>
13581489 </tp:hct>
13591490
13601491 <tp:hct name="ice">
13611492 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
13621493 <p>The client can implement streaming for streams whose <tp:dbus-ref
1363 namespace="ofdT.Call.Stream.Interface.Media.DRAFT">Transport</tp:dbus-ref>
1364 property is <tp:type>Stream_Transport_Type</tp:type>_ICE.</p>
1494 namespace="ofdT.Call1.Stream.Interface.Media">Transport</tp:dbus-ref>
1495 property is <tp:value-ref type="Stream_Transport_Type">ICE</tp:value-ref>.</p>
13651496 </tp:docstring>
13661497 </tp:hct>
13671498
13681499 <tp:hct name="wlm-2009">
13691500 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
13701501 <p>The client can implement streaming for streams whose <tp:dbus-ref
1371 namespace="ofdT.Call.Stream.Interface.Media.DRAFT">Transport</tp:dbus-ref>
1372 property is <tp:type>Stream_Transport_Type</tp:type>_WLM_2009.</p>
1502 namespace="ofdT.Call1.Stream.Interface.Media">Transport</tp:dbus-ref>
1503 property is <tp:value-ref type="Stream_Transport_Type">WLM_2009</tp:value-ref>.</p>
13731504 </tp:docstring>
13741505 </tp:hct>
13751506
13761507 <tp:hct name="shm">
13771508 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
13781509 <p>The client can implement streaming for streams whose <tp:dbus-ref
1379 namespace="ofdT.Call.Stream.Interface.Media.DRAFT">Transport</tp:dbus-ref>
1380 property is <tp:type>Stream_Transport_Type</tp:type>_SHM.</p>
1510 namespace="ofdT.Call1.Stream.Interface.Media">Transport</tp:dbus-ref>
1511 property is <tp:value-ref type="Stream_Transport_Type">SHM</tp:value-ref>.</p>
13811512 </tp:docstring>
13821513 </tp:hct>
13831514
14121543 property:</p>
14131544
14141545 <ul>
1415 <li><code>org.freedesktop.Telepathy.Channel.Type.Call.DRAFT/audio</code></li>
1416 <li><code>org.freedesktop.Telepathy.Channel.Type.Call.DRAFT/audio/speex</code></li>
1417 <li><code>org.freedesktop.Telepathy.Channel.Type.Call.DRAFT/video</code></li>
1418 <li><code>org.freedesktop.Telepathy.Channel.Type.Call.DRAFT/video/theora</code></li>
1419 <li><code>org.freedesktop.Telepathy.Channel.Type.Call.DRAFT/video/h264</code></li>
1546 <li><code>org.freedesktop.Telepathy.Channel.Type.Call1/audio</code></li>
1547 <li><code>org.freedesktop.Telepathy.Channel.Type.Call1/audio/speex</code></li>
1548 <li><code>org.freedesktop.Telepathy.Channel.Type.Call1/video</code></li>
1549 <li><code>org.freedesktop.Telepathy.Channel.Type.Call1/video/theora</code></li>
1550 <li><code>org.freedesktop.Telepathy.Channel.Type.Call1/video/h264</code></li>
14201551 </ul>
14211552
14221553 <p>Clients MAY have media signalling abilities without explicitly
+26
-9
spec/Channel_Type_Text.xml less more
554554 <p>Simple one-to-one chats (such as streams of private messages in
555555 XMPP or IRC) should be represented by a Text channel whose
556556 <tp:dbus-ref namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref>
557 is <tp:type>Handle_Type</tp:type>_Contact. The expected way to
558 request such a channel is to set the ChannelType, TargetHandleType,
559 and either TargetHandle or TargetID in a call to EnsureChannel.</p>
557 is <tp:value-ref type="Handle_Type">Contact</tp:value-ref>. The
558 expected way to request such a channel is to set the <tp:dbus-ref
559 namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>, <tp:dbus-ref
560 namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>,
561 and either <tp:dbus-ref
562 namespace='ofdT.Channel'>TargetHandle</tp:dbus-ref> or <tp:dbus-ref
563 namespace='ofdT.Channel'>TargetID</tp:dbus-ref> in a call to
564 <tp:dbus-ref
565 namespace='ofdT.ChannelDispatcher'>EnsureChannel</tp:dbus-ref>.</p>
560566
561567 <p>Named chat rooms whose identity can be saved and used again later
562568 (IRC channels, Jabber MUCs) are expected to be represented by Text
563 channels with <tp:type>Handle_Type</tp:type>_Room and the <tp:dbus-ref
564 namespace="ofdT.Channel.Interface">Group</tp:dbus-ref>
569 channels with <tp:dbus-ref
570 namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref> =
571 <tp:value-ref type="Handle_Type">Room</tp:value-ref> and the
572 <tp:dbus-ref namespace="ofdT.Channel.Interface">Group</tp:dbus-ref>
565573 interface. In protocols where a chatroom can be used as a continuation
566574 of one or more one-to-one chats, these channels should also have the
567575 <tp:dbus-ref namespace="ofdT.Channel.Interface">Conference</tp:dbus-ref>
570578 <p>Unnamed, transient chat rooms which cannot be rejoined by their
571579 unique identifier (e.g. a conversation on MSN which has, or once had,
572580 three or more participants) are expected to be represented by Text
573 channels with Handle_Type_None (and hence TargetHandle 0), the
581 channels with <tp:dbus-ref
582 namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref> = <tp:value-ref
583 type="Handle_Type">None</tp:value-ref> (and hence <tp:dbus-ref
584 namespace="ofdT.Channel">TargetHandle</tp:dbus-ref> = 0),
574585 <tp:dbus-ref namespace="ofdT.Channel.Interface">Group</tp:dbus-ref>
575586 interface, and optionally the
576587 <tp:dbus-ref namespace="ofdT.Channel.Interface">Conference</tp:dbus-ref>
579590 <p>On protocols like MSN where a conversation with a user is actually
580591 just a nameless chat room starting with exactly two members, to which
581592 more members can be invited, the initial one-to-one conversation
582 SHOULD be represented with Handle_Type_Contact. If a third participant
593 SHOULD be represented with <tp:dbus-ref
594 namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref> =
595 <tp:value-ref type="Handle_Type">Contact</tp:value-ref>. If a third
596 participant
583597 joins or is invited, this SHOULD be represented by signalling
584598 a new <tp:dbus-ref
585599 namespace="ofdT.Channel.Interface">Conference</tp:dbus-ref> channel
605619 <tp:dbus-ref
606620 namespace="ofdT.Connection.Interface.Requests">NewChannels</tp:dbus-ref>
607621 signal. The new channel should resemble the old channel, but have
608 Requested = FALSE regardless of its previous value; the InitiatorHandle
609 and InitiatorID should correspond to the sender of one of the pending
622 <tp:dbus-ref namespace='ofdT.Channel'>Requested</tp:dbus-ref> = FALSE
623 regardless of its previous value; the <tp:dbus-ref
624 namespace='ofdT.Channel'>InitiatorHandle</tp:dbus-ref>
625 and <tp:dbus-ref namespace='ofdT.Channel'>InitiatorID</tp:dbus-ref>
626 should correspond to the sender of one of the pending
610627 messages.</p>
611628
612629 <tp:rationale>
+1
-1
spec/Connection_Interface_Forwarding.xml less more
9191 the group with the self handle as the actor, and
9292 <tp:type>Channel_Group_Change_Reason</tp:type> <code>No_Answer</code> or
9393 <code>Busy</code>, as appropriate. For <tp:dbus-ref
94 namespace='ofdT.Channel.Type'>Call.DRAFT</tp:dbus-ref> channels, the
94 namespace='ofdT.Channel.Type'>Call1</tp:dbus-ref> channels, the
9595 <tp:type>Call_State_Change_Reason</tp:type> <code>Forwarded</code>
9696 should be used.</p>
9797 </tp:docstring>
+11
-0
spec/Media_Stream_Handler.xml less more
722722
723723 <tp:struct name="RTCP_Feedback_Message_Properties">
724724 <tp:added version="0.22.1"/>
725 <tp:changed version="0.23.4">This struct is also used by Call, but
726 in call, the CM should know about RTP profiles, and never use MAXUINT
727 as a default value, because it complicates things unnecessarily.
728 </tp:changed>
725729 <tp:member type="u" name="RTCPMinimumInterval">
726730 <tp:docstring>
727731 The minimum interval between two regular RTCP packets in
728732 milliseconds for this content. If no special value is desired, one
729733 should put MAXUINT (0xFFFFFFFF).
734
735 Implementors and users of Call's <tp:dbus-ref
736 namespace="ofdT.Call1.Content.MediaDescription.Interface"
737 >RTCPFeedback</tp:dbus-ref> should not use the MAXUINT default.
738 Instead, in RTP/AVP, the default should be 5000 (5 seconds).
739 If using the RTP/AVPF profile, it can be set to a lower value,
740 the default being 0.
730741 </tp:docstring>
731742 </tp:member>
732743 <tp:member type="a(sss)" tp:type="RTCP_Feedback_Message[]"
+9
-5
spec/all.xml less more
22 xmlns:xi="http://www.w3.org/2001/XInclude">
33
44 <tp:title>Telepathy D-Bus Interface Specification</tp:title>
5 <tp:version>0.23.3</tp:version>
5 <tp:version>0.23.4</tp:version>
66
77 <tp:copyright>Copyright © 2005-2011 Collabora Limited</tp:copyright>
88 <tp:copyright>Copyright © 2005-2011 Nokia Corporation</tp:copyright>
190190 namespace='ofdT.Channel.Interface'>Hold</tp:dbus-ref> and
191191 <tp:dbus-ref namespace="ofdT.Channel.Interface">DTMF</tp:dbus-ref>
192192 interfaces, which may also appear on <tp:dbus-ref
193 namespace='ofdT.Channel.Type'>Call.DRAFT</tp:dbus-ref> channels.</p>
193 namespace='ofdT.Channel.Type'>Call1</tp:dbus-ref> channels.</p>
194194 </tp:docstring>
195195
196196 <xi:include href="Channel_Interface_Call_State.xml"/>
205205 chat rooms. They are primarily intended for <tp:dbus-ref
206206 namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>, <tp:dbus-ref
207207 namespace='ofdT.Channel.Type'>StreamedMedia</tp:dbus-ref> and
208 <tp:dbus-ref namespace='ofdT.Channel.Type'>Call.DRAFT</tp:dbus-ref>
208 <tp:dbus-ref namespace='ofdT.Channel.Type'>Call1</tp:dbus-ref>
209209 channels, but may also appear on other types of channel.</p>
210210 </tp:docstring>
211211
235235 <tp:section name="Calls">
236236 <xi:include href="Call_Content.xml"/>
237237 <xi:include href="Call_Content_Interface_Media.xml"/>
238 <xi:include href="Call_Content_Interface_Mute.xml"/>
238 <xi:include href="Call_Interface_Mute.xml"/>
239239 <xi:include href="Call_Content_Interface_Video_Control.xml"/>
240 <xi:include href="Call_Content_Codec_Offer.xml"/>
240 <xi:include href="Call_Content_Media_Description.xml"/>
241 <xi:include href="Call_Content_Media_Description_Interface_RTP_Header_Extensions.xml"/>
242 <xi:include href="Call_Content_Media_Description_Interface_RTCP_Feedback.xml"/>
243 <xi:include
244 href="Call_Content_Media_Description_Interface_RTCP_Extended_Reports.xml"/>
241245 <xi:include href="Call_Stream.xml"/>
242246 <xi:include href="Call_Stream_Interface_Media.xml"/>
243247 <xi:include href="Call_Stream_Endpoint.xml"/>
+42
-3
spec/errors.xml less more
385385 </tp:docstring>
386386 </tp:error>
387387
388 <tp:error name="Media.Codecs Incompatible">
389 <tp:added version="0.23.4"/>
390 <tp:docstring>
391 Raised when the local streaming implementation has no codecs in common
392 with the remote side.
393
394 <tp:rationale>
395 This corresponds to
396 <tp:value-ref type="Call_State_Change_Reason">Media_Error</tp:value-ref>.
397 </tp:rationale>
398 </tp:docstring>
399 </tp:error>
400
401 <tp:error name="Media.Unsupported Type">
402 <tp:added version="0.23.4"/>
403 <tp:docstring>
404 The media stream type requested is not supported by either the
405 local or remote side.
406
407 <tp:rationale>
408 This corresponds to
409 <tp:value-ref type="Call_State_Change_Reason">Media_Error</tp:value-ref>.
410 </tp:rationale>
411 </tp:docstring>
412 </tp:error>
413
414 <tp:error name="Media.Streaming Error">
415 <tp:added version="0.23.4"/>
416 <tp:docstring>
417 Raised when the call's streaming implementation has some kind of internal
418 error.
419
420 <tp:rationale>
421 This corresponds to
422 <tp:value-ref type="Call_State_Change_Reason">Internal_Error</tp:value-ref>.
423 </tp:rationale>
424 </tp:docstring>
425 </tp:error>
426
388427 <tp:error name="Connection Refused">
389428 <tp:docstring>
390429 Raised when a connection is refused.
494533 <tp:added version="0.21.2"/>
495534 <tp:docstring>
496535 Raised when an incoming or outgoing <tp:dbus-ref
497 namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref> is
536 namespace="ofdT.Channel.Type">Call1</tp:dbus-ref> is
498537 rejected by the the receiver.
499538 </tp:docstring>
500539 </tp:error>
536575 errors bad-format, invalid-xml, etc., which can't happen unless
537576 the local (or remote) XMPP implementation is faulty. This is
538577 also analogous to
539 <tp:type>Media_Stream_Error</tp:type>_Invalid_CM_Behavior,
578 <tp:value-ref type="Media_Stream_Error">Invalid_CM_Behavior</tp:value-ref>,
540579 <code>TP_DBUS_ERROR_INCONSISTENT</code> in telepathy-glib, and
541580 <code>TELEPATHY_QT4_ERROR_INCONSISTENT</code> in telepathy-qt4.
542581 </tp:rationale>
588627 to place a call or send a message.</p>
589628
590629 <p>The key 'balance-required' MAY be included in
591 <tp:dbus-ref namespace="ofdT.Channel.Type.Call.DRAFT">CallStateDetails</tp:dbus-ref>
630 <tp:dbus-ref namespace="ofdT.Channel.Type.Call1">CallStateDetails</tp:dbus-ref>
592631 or a delivery report's <tp:type>Message_Part</tp:type>
593632 (with the same units and scale as
594633 <tp:dbus-ref namespace="ofdT.Connection.Interface.Balance">AccountBalance</tp:dbus-ref>)
+1
-1
spec/template.xml less more
2121
2222 <interface name="org.freedesktop.Telepathy.Foo.DRAFT"
2323 tp:causes-havoc="experimental">
24 <tp:added version="0.21.UNRELEASED">(draft 1)</tp:added>
24 <tp:added version="0.UNRELEASED">(draft 1)</tp:added>
2525
2626 <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
2727 <p>Foo.</p>
+31
-0
tools/specparser.py less more
303303 n.tagName = 'a'
304304 n.namespaceURI = None
305305 n.setAttribute('href', t.get_url())
306
307 # rewrite <tp:value-ref>
308 for n in node.getElementsByTagNameNS(XMLNS_TP, 'value-ref'):
309 if n.hasAttribute('type'):
310 type_name = n.getAttribute('type')
311 value_name = getText(n)
312 t = spec.lookup_type(type_name)
313 assert isinstance(t, EnumLike), ("%s is not an enum or flags type"
314 % type_name)
315 else:
316 type_name = getText(n)
317 value_name_parts = []
318 while type_name not in spec.types:
319 type_name, _, rest = type_name.rpartition('_')
320 value_name_parts.insert(0, rest)
321 if not type_name:
322 raise ValueError("No substrings of '%s' describe "
323 "a valid type." % getText(n))
324 value_name = '_'.join(value_name_parts)
325 t = spec.lookup_type(type_name)
326 assert isinstance(t, EnumLike), ("%s is not an enum or flags type"
327 % type_name)
328
329 n.tagName = 'a'
330 n.namespaceURI = None
331 n.setAttribute('href', t.get_url())
332 short_names = [val.short_name for val in t.values]
333 if value_name not in short_names:
334 raise ValueError("'%s' is not a valid value of '%s'. "
335 "Valid values are %s" %
336 (value_name, type_name, short_names))
306337
307338 # rewrite <tp:error-ref>
308339 error_ns = spec.spec_namespace + '.Error.'