idnits 2.17.1
draft-ietf-siprec-metadata-07.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 3, 2012) is 4308 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141)
** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866)
== Outdated reference: A later version (-12) exists of
draft-ietf-siprec-architecture-05
Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 SIPREC Ram Mohan. Ravindranath
2 Internet-Draft Cisco Systems, Inc.
3 Intended status: Standards Track Parthasarathi. Ravindran
4 Expires: January 4, 2013 Sonus Networks
5 Paul. Kyzivat
6 Unaffiliated
7 July 3, 2012
9 Session Initiation Protocol (SIP) Recording Metadata
10 draft-ietf-siprec-metadata-07
12 Abstract
14 Session recording is a critical requirement in many communications
15 environments such as call centers and financial trading. In some of
16 these environments, all calls must be recorded for regulatory,
17 compliance, and consumer protection reasons. Recording of a session
18 is typically performed by sending a copy of a media stream to a
19 recording device. This document describes the metadata model as
20 viewed by Session Recording Server(SRS) and the Recording metadata
21 format.
23 Status of this Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at http://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on January 4, 2013.
40 Copyright Notice
42 Copyright (c) 2012 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
59 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
60 4. Metadata Model . . . . . . . . . . . . . . . . . . . . . . . . 5
61 5. Recording Metadata Format . . . . . . . . . . . . . . . . . . 6
62 5.1. XML data format . . . . . . . . . . . . . . . . . . . . . 6
63 5.1.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 7
64 5.1.2. recording . . . . . . . . . . . . . . . . . . . . . . 7
65 6. Recording Metadata classes . . . . . . . . . . . . . . . . . . 7
66 6.1. Recording Session . . . . . . . . . . . . . . . . . . . . 7
67 6.1.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 8
68 6.1.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 8
69 6.1.3. XML element . . . . . . . . . . . . . . . . . . . . . 8
70 6.2. Communication Session Group . . . . . . . . . . . . . . . 9
71 6.2.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 9
72 6.2.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 9
73 6.2.3. XML element . . . . . . . . . . . . . . . . . . . . . 10
74 6.3. Communication Session . . . . . . . . . . . . . . . . . . 10
75 6.3.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 11
76 6.3.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 11
77 6.3.3. XML element . . . . . . . . . . . . . . . . . . . . . 12
78 6.4. CSRSAssociation . . . . . . . . . . . . . . . . . . . . . 12
79 6.4.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 13
80 6.4.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 13
81 6.4.3. XML element . . . . . . . . . . . . . . . . . . . . . 13
82 6.5. Participant . . . . . . . . . . . . . . . . . . . . . . . 13
83 6.5.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 14
84 6.5.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 14
85 6.5.3. XML element . . . . . . . . . . . . . . . . . . . . . 14
86 6.6. ParticipantCSAssociation . . . . . . . . . . . . . . . . . 15
87 6.6.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 15
88 6.6.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 16
89 6.6.3. XML element . . . . . . . . . . . . . . . . . . . . . 16
90 6.7. Media Stream . . . . . . . . . . . . . . . . . . . . . . . 16
91 6.7.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 17
92 6.7.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 17
93 6.7.3. XML element . . . . . . . . . . . . . . . . . . . . . 17
94 6.8. ParticipantStream Association . . . . . . . . . . . . . . 17
95 6.8.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 18
96 6.8.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 18
97 6.8.3. XML element . . . . . . . . . . . . . . . . . . . . . 18
98 6.9. associate-time/disassociate-time . . . . . . . . . . . . . 18
99 6.10. Unique ID format . . . . . . . . . . . . . . . . . . . . . 19
100 7. SIP Recording Metadata Example . . . . . . . . . . . . . . . . 19
101 7.1. Complete SIP Recording Metadata Example . . . . . . . . . 19
102 7.2. Partial Update of Recording metadata XML body . . . . . . 21
103 8. XML Schema definition for Recording metadata . . . . . . . . . 21
104 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
105 9.1. Connection Security . . . . . . . . . . . . . . . . . . . 25
106 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
107 10.1. SIP recording metadata Schema Registration . . . . . . . . 26
108 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 26
109 12. Appendix A: Metadata Model Object Instances . . . . . . . . . 26
110 12.1. Use case 1: Basic Call . . . . . . . . . . . . . . . . . . 26
111 12.2. Use case 2: Hold/Resume . . . . . . . . . . . . . . . . . 27
112 12.3. Use case 3: Basic call with Transfer . . . . . . . . . . . 29
113 12.4. Conference Use Cases . . . . . . . . . . . . . . . . . . . 30
114 12.4.1. Case 1: . . . . . . . . . . . . . . . . . . . . . . . 31
115 12.4.2. Case 2: . . . . . . . . . . . . . . . . . . . . . . . 33
116 12.4.3. Case 3: . . . . . . . . . . . . . . . . . . . . . . . 35
117 12.4.4. Case 4: . . . . . . . . . . . . . . . . . . . . . . . 36
118 13. Appendix B: Metadata XML schema Instances . . . . . . . . . . 37
119 13.1. Use case 1: Basic Call . . . . . . . . . . . . . . . . . . 37
120 13.2. Use case 2: Hold/resume . . . . . . . . . . . . . . . . . 39
121 13.3. Use case 3: Basic Call with transfer . . . . . . . . . . . 41
122 13.4. Use Case 4: Call disconnect . . . . . . . . . . . . . . . 45
123 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
124 14.1. Normative References . . . . . . . . . . . . . . . . . . . 46
125 14.2. Informative References . . . . . . . . . . . . . . . . . . 47
126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
128 1. Introduction
130 Session recording is a critical requirement in many communications
131 environments such as call centers and financial trading. In some of
132 these environments, all calls must be recorded for regulatory,
133 compliance, and consumer protection reasons. Recording of a session
134 is typically performed by sending a copy of a media stream to a
135 recording device. This document focuses on the Recording metadata
136 which describes the communication session. The document describes a
137 metadata model as viewed by Session Recording Server and the
138 Recording metadata format, the requirements for which are described
139 in [RFC6341] and the architecture for which is described in
140 [I-D.ietf-siprec-architecture].
142 2. Terminology
144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
146 document are to be interpreted as described in [RFC2119]. This
147 document only uses these key words when referencing normative
148 statements in existing RFCs."
150 3. Definitions
152 Metadata Model: An abstract representation of metadata using a
153 Unified Modelling Language(UML) class diagram.
155 Metadata classes: Each block in the model represents a class. A
156 class is a construct that is used as a blueprint to create
157 instances(called objects) of itself. The description of each class
158 also has representation of its attributes in a second compartment
159 below the class name.
161 Attributes: Attributes represents the attributes listed in each of
162 the classes. The attributes of a class are listed in the second
163 compartment below the class name. Each instance of class conveys
164 values for these attributes which adds to the recording's Metadata.
166 Linkages: Linkages represents the relationship between the classes in
167 the model. It represents the logical connections betweens classes(or
168 objects) in class diagrams/ object diagrams. The linkages used in
169 the Metadata model of this document are associations.
171 4. Metadata Model
173 Metadata is the information that describes recorded media and the CS
174 to which they relate. Below diagram shows a model for Metadata as
175 viewed by Session Recording Server (SRS).
177 +-------------------------------+
178 | Recording Session (RS) |
179 +-------------------------------+
180 |1..* | 1..*
181 | |
182 | | 0..*
183 | +-----------------+
184 | | Communication |
185 | | Session (CS) |
186 | | Group |
187 | +-----------------+
188 | | 0..1
189 | |
190 |0..* | 1..*
191 +-------------------------------+
192 | Communication Session (CS) |
193 | |
194 +-------------------------------+
195 | 1..* |1..*
196 +-----+ |
197 | | 0..* |0..*
198 | +-------------+ receives +----------------+
199 | | Participant |----------| Media Streams |
200 | | |0..* 0..*| |
201 | | | | |
202 | | | | |
203 | | | sends | |
204 | | |----------| |
205 | | |1.* 0..*| |
206 | +-------------+ +----------------+
207 | | |
208 | | |
209 | +------------------------+------------+
210 | |
211 | |
212 | +------------------+ +----------------------+
213 | |ParticipantCS | | ParticipantStream |
214 +-----------| Association | | Association |
215 | | | |
216 +------------------+ +----------------------+
218 The Metadata model is a class diagram in Unified Modelling
219 Language(UML). The model describes the structure of a metadata in
220 general by showing the classes, their attributes, and the
221 relationships among the classes. Each block in the model above
222 represents a class. The linkages between the classes represents the
223 relationships which can be associations or Composition. The metadata
224 is conveyed from SRC to SRS.
226 The model allows the capture of a snapshot of a recording's Metadata
227 at a given instant in time. Metadata changes to reflect changes in
228 what is being recorded. For example, if in a conference a
229 participant joins SRC sends a snapshot of metadata having that
230 participant information (with attributes like name/AoR pair and
231 associate-time) to the SRS.
233 Some of the metadata is not required to be conveyed explicitly from
234 the SRC to the SRS, if it can be obtained contextually by the
235 SRS(e.g., from SIP or SDP signalling).
237 5. Recording Metadata Format
239 This section gives an overview of Recording Metadata Format. Some
240 data from the metadata model is assumed to be made available to the
241 SRS through Session Description Protocol (SDP)[RFC4566], and
242 therefore this data is not represented in the XML document format
243 specified in this document. SDP attributes describes about different
244 media formats like audio, video. The other metadata attributes like
245 participant details are represented in a new Recording specific XML
246 document namely application/rs-metadata+xml. The SDP label attribute
247 [RFC4574] provides an identifier by which a metadata XML document can
248 refer to a specific media description in the SDP sent from the SRC to
249 the SRS.
251 The XML document format can be used to represent either the complete
252 metadata or a partial update to the metadata. The latter includes
253 only elements that have changed compared to the previously reported
254 metadata.
256 5.1. XML data format
258 Recording Metadata document is an XML document. recording element
259 MUST be present in all recording metadata XML document. recording
260 acts as container for all other elements in this XML document.
262 Recording object is a XML document. It MUST have the XML declaration
263 and it SHOULD contain an encoding declaration in the XML declaration,
264 e.g., "". If the charset
265 parameter of the MIME content type declaration is present and it is
266 different from the encoding declaration, the charset parameter takes
267 precedence.
269 Every application conforming to this specification MUST accept the
270 UTF-8 character encoding to ensure the minimal interoperability.
272 Syntax and semantics error in recording XML document has to be
273 informed to the originator using application specific mechanism.
275 5.1.1. Namespace
277 The namespace URI for elements defined by this specification is a
278 Uniform Resource Namespace (URN) [RFC2141], using the namespace
279 identifier 'ietf' defined by [RFC2648] and extended by [RFC3688].
281 The URN is as follows: urn:ietf:params:xml:ns:recording
283 5.1.2. recording
285 recording element MUST contain an xmlns namespace attribute with
286 value as urn:ietf:params:xml:ns:recording. One recording element
287 MUST be present in the all recording metadata XML document.
289 dataMode element shows whether the XML document is complete document
290 or partial update. The default value is complete.
292 6. Recording Metadata classes
294 This section describes each class of the metadata model, and the
295 attributes of each class. This section also describes how different
296 classes are linked and the XML element for each of them.
298 6.1. Recording Session
299 +-------------------------------+
300 | Recording Session (RS) |
301 +-------------------------------+
302 | |
303 | Start/End Time |
304 | |
305 | |
306 | |
307 +-------------------------------+
308 |1..* | 1..*
309 | |
310 |0..* | 0..*
311 Communication Communication
312 Session Session Group(CS Group)
314 Each instance of a Recording Session class (namely the Recording
315 Session Object) represents a SIP session created between an SRC and
316 SRS for the purpose of recording a Communication Session.
318 6.1.1. Attributes
320 A Recording Session class has the following attributes:
321 o Start/End Time - Represents the Start/End time of a Recording
322 Session object.
324 6.1.2. Linkages
326 Each instance of Recording Session has:
328 o Zero or more instances of Communication Session Group. CSG may be
329 zero because it is optional metadata object. Also the allowance
330 of zero instances is to accommodate persistent recording, where
331 there may be none.
332 o Zero or more instances of Communication Session objects.
334 6.1.3. XML element
336 Recording Session object is represented by recording XML element.
337 That in turn relies on the SIP/SDP session with which the XML
338 document is associated to provide some of the attributes of the
339 Recording Session element.
341 Start and End time value are derivable from Date header(if present in
342 SIP message) in RS. In cases where Date header is not present,
343 Start/End time are derivable from the time at which SRS receives the
344 notification of SIP message to setup RS / disconnect RS.
346 6.2. Communication Session Group
348 Recording Session (RS)
349 | 1..*
350 |
351 | 0..*
352 +-------------------------------+
353 | Communication Session |
354 | Group |
355 +-------------------------------+
356 | Unique-ID |
357 | associate-time |
358 | disassociate-time |
359 | |
360 +-------------------------------+
361 | 0..1
362 |
363 | 1..*
364 Communication Session (CS)
366 One instance of a Communication Session Group class (namely the
367 Communication Session Group object) provides association or linking
368 of Communication Sessions.
370 6.2.1. Attributes
372 A CS Group has the following attributes:
373 o Unique-ID - This Unique-ID is to group different CSs that are
374 related. SRC (or SRS) is responsible for ensuring the uniqueness
375 of Unique-ID in case multiple SRC interacts with the same SRS.
376 The mechanism by which SRC groups the CS is outside the scope of
377 SIPREC.
378 o Associate-time - Associate-time for CS-Group shall be calculated
379 by SRC as the time when a grouping is formed. The rules that
380 determine how a grouping of different Communication Session
381 objects is done by SRC is outside the scope of SIPREC.
382 o Disassociate-time - Disassociate-time for CS-Group shall be
383 calculated by SRC as the time when the grouping ends
385 6.2.2. Linkages
387 The linkages between Communication Session Group class and other
388 classes is association. A communication Session Group is associated
389 with RS and CS in the following manner:
391 o There is one or more Recording Session objects per Communication
392 Session Group.
393 o Each Communication Session Group object has to be associated with
394 one or more RS [Here each RS can be setup by the potentially
395 different SRCs]
396 o There is one or more Communication Sessions per CS Group [e.g.
397 Consult Transfer]
399 6.2.3. XML element
401 Group element is an optional element provides the information about
402 the communication session group
404 Each communication session group (CSG)object is represented using one
405 group element. Each group element has unique Base 64 URN UUID
406 attribute which helps to uniquely identify CSG.
408 6.3. Communication Session
410 Recording Communication
411 Session Session Group(CS Group)
412 |1..* | 0..1
413 | |
414 |0..* | 1..*
415 +-------------------------------+
416 | Communication Session (CS) |
417 | |
418 +-------------------------------+
419 | CS Identifier |
420 | Termination Reason |
421 | Start-time |
422 | Stop-time |
423 +-------------------------------+
424 | |
425 | 0..* |0..*
426 | |
427 | 0..* |0..*
428 Participant Media Stream
430 A Communication Session class and its object in the metadata model
431 represents Communication Session and its properties needed as seen by
432 SRC.
434 6.3.1. Attributes
436 A communication Session class has the following attributes:
438 o Termination Reason - This represents the reason why a CS was
439 terminated. The communication session MAY contain a Call
440 Termination Reason. This MAY be derived from SIP Reason header
441 [RFC3326] of CS.
442 o CS Identifier - This attribute is used to uniquely identify a CS.
443 o Start-time - This optional attribute represents start time of CS
444 as seen by SRC
445 o Stop-time - This optional attribute represents stop time of CS as
446 seen by SRC
448 This document does not specify attributes relating to what should
449 happen to a recording of a CS after it has been delivered to the SRS,
450 e.g., how long to retain the recording, what access controls to
451 apply. The SRS is assumed to behave in accordance with policy. The
452 ability for the SRC to influence this policy is outside the scope of
453 this document. However if there are implementations where SRC has
454 enough information, this could be sent as Extension Data attached to
455 CS
457 6.3.2. Linkages
459 A Communication Session is linked to CS-Group, Participant, Media
460 Stream and Recording Session classes using the association
461 relationship. Association between CS and Participant allows:
463 o CS to have atleast zero or more participants
464 o Participant is associated with zero or more CSs. This includes
465 participants who are not directly part of any CS. An example of
466 such a case is participants in a premixed media stream. The SRC
467 may have knowledge of such Participants, yet not have any
468 signaling relationship with them. This might arise if one
469 participant in CS is a conf focus. To summarize even if SRC does
470 not have direct signalling relationships with all participants in
471 a CS, it should nevertheless create a Participant object for each
472 participant that it knows about.
473 o The model also allows participants in CS that are not participants
474 in the media. An example is the identity of a 3pcc controller
475 that has initiated a CS to two or more participants of the CS.
476 Another example is the identity of a conference focus. Of course
477 a focus is probably in the media, but since it may only be there
478 as a mixer, it may not report itself as a participant in any of
479 the media streams.
481 Association between CS and Media Stream allows:
483 o A CS to have zero or more Streams
484 o A stream can be associated with zero or more CS. An example is
485 multicast MoH stream which might be associated with many CSs.
486 Stream in persistent RS is not required to be associated with any
487 CS before CS is created.
489 Association between CS and RS allows:
491 o Each instance of RS has Zero or more instances of Communication
492 Session objects.
493 o Each CS has to be associated with one more RS [ Here each RS can
494 be potentially setup by different SRCs]
496 6.3.3. XML element
498 Session element provides the information about the communication
499 session
501 Each communication session(CS) object is represented by one session
502 element. Each session element has unique Base 64 URN UUID attribute
503 which helps to uniquely identify CS.
505 Reason element MAY be included to represent the Termination Reason
506 attribute. group-ref element MAY exist to indicate the group where
507 the mentioned session belongs.
509 6.4. CSRSAssociation
511 1..* 0..*
512 Recording Communication
513 Session ----------+---------- Session
514 |
515 |
516 |
517 +-------------------+
518 | CSRSAssociation |
519 +-------------------+
520 | Association-Time |
521 | Disassociaton-Time|
522 +-------------------+
524 A CSRS Association class and its objects has attributes of CS object
525 which are attributes of association of a session to a RS.
527 6.4.1. Attributes
529 CSRS association class has the following attributes:
531 o Associate-time - associate-time is calculated by SRC as the time
532 it sees a CS is associated to RS
533 o Disassociate-time- Disassociate-time is calculated by SRC as the
534 time it see a CS disassociate from a RS.
535 It is possible that a given CS can have multiple associate/
536 disassociate times within given RS.
538 6.4.2. Linkages
540 CSRS association class is linked to CS and RS classes. There are no
541 cardinalties for this linkage.
543 6.4.3. XML element
545 sessionrecordingassoc is the XML element to represent CSRS
546 association object. session URN UUID is used to uniquely identify
547 this element and link with the specific session.
549 6.5. Participant
551 Communication Session (CS)
552 | 0..*
553 |
554 | 0..*
555 +-------------------------------+
556 | Participant |
557 | |
558 +-------------------------------+
559 | AoR / Name Pair list |
560 | |
561 | |
562 +-------------------------------+
563 | 0..* 1..*|
564 receives| |sends
565 | 0..* 0..*|
566 Media Stream
568 A Participant class and its objects has information about a device
569 that is part of a CS and/or contributes/consumes media stream(s)
570 belonging to a CS.
572 6.5.1. Attributes
574 Participant has attributes like:
576 o AoR / Name pair list - This attribute is a list of Name/AoR tuple.
577 An AoR MAY be SIP/SIPS/TEL URI. Name represents Participant
578 name(SIP display name) or DN number ( in case it is known). There
579 are cases where a participant can have more than one AoR [e.g.
580 P-Asserted-identity header [RFC3325] which can have both SIP and
581 TEL URIs]
583 This document does not specify other attributes relating to
584 participant e.g. Participant Role, Participant type. An SRC which
585 has information of these attributes can indicate the same as part of
586 extension data to Participant from SRC to SRS.
588 6.5.2. Linkages
590 The participant class is linked to MS and CS class using association
591 relationship. The association between participant and Media Stream
592 allows:
594 o Participant to receives zero or more media streams
595 o Participant to send zero or more media streams. (Same participant
596 provides multiple streams e.g. audio and video)
597 o Media stream to be received by zero or more participants. Its
598 possible, though perhaps unlikely, that a stream is generated but
599 sent only to the SRC and SRS, not to any participant. E.g. In
600 conferencing where all participants are on hold and the SRC is
601 collocated with the focus. Also a media stream may be received by
602 multiple participants (e.g. Whisper calls, side conversations).
603 o Media stream to be sent by one or more participants (pre-mixed
604 streams).
606 Example of a case where a participant receives Zero or more streams -
607 a Supervisor may have side conversation with Agent, while Agent
608 converses with customer.
610 6.5.3. XML element
612 A participant element represents a Participant object.
614 Participant MUST have a NameID complex element which contains AoR as
615 attribute and Name as element. AOR element is SIP/SIPS URI FQDN or
616 IP address which represents the user. name is an optional element to
617 represent display name.
619 Each participant element has unique ID (Base 64 URN UUID) attribute
620 which helps to uniquely identify participant and session Base 64 URN
621 UUID to associate participant with specific session element. Base 64
622 URN UUID of participant MUST used in the scope of CSG and no new Base
623 64 URN UUID has to be created for the same element (participant,
624 stream) between different CS in the same CSG. In case Base 64 URN
625 UUID has to be used permanent, careful usage of Base 64 URN UUID to
626 original AoR has to be decided by the implementers and it is
627 implementer's choice.
629 6.6. ParticipantCSAssociation
631 1..* 0..*
632 Communication
633 Session ----------+---------- Participant
634 |
635 |
636 |
637 +-------------------+
638 | ParticipantCS |
639 | Association |
640 +-------------------+
641 | Capabilities |
642 | Association-Time |
643 | Disassociaton-Time|
644 +-------------------+
646 A participantCS Association class and its objects has attributes of
647 participant object which are attributes of association of a
648 participant to a Session.
650 6.6.1. Attributes
652 ParticipantCS association class has the following attributes:
654 o Associate-time - associate-time is calculated by SRC as the time
655 it sees a participant is associated to CS
656 o Disassociate-time- Disassociate-time is calculated by SRC as the
657 time it see a participant disassociate from a CS. It is possible
658 that a given participant can have multiple associate/disassociate
659 times within given communication session.
660 o Capabilities - A participant capabilities as defined in [RFC3840]
661 which is an optional attribute that includes the capabilities of a
662 participant in a CS. Each participant shall have Zero or more
663 capabilities. A participant may use different capabilities
664 depending on the role it plays at a particular instance. IOW if a
665 participants moves across different CSs ( due to transfer e.t.c)
666 OR is simultaneously present in different CSs its role may be
667 different and hence the capability used.
668 o "send" or "recv" element in each participant is associating SDP
669 m-lines with the participant. send element indicates that
670 participant is sending the stream of media with the mentioned
671 media description. recv element indicates that participant is
672 receiving the stream and by default all participant will receive
673 the stream. recv element has relevance in case whisper call
674 scenario wherein few of the participant in the session receives
675 the stream and not others.
677 6.6.2. Linkages
679 The participantCS association class is linked to participant and CS
680 classes. There are no cardinalties for this linkage.
682 6.6.3. XML element
684 participantsessionassoc XML element represent participantCS
685 association object. participant and session id is used to uniquely
686 identify this element
688 NOTE: RFC 4235 encoding shall be used to represent capabilities
689 attribute in XML.
691 6.7. Media Stream
693 Participant
694 | 0..* 1..*|
695 receives| |sends
696 | 0..* 0..*|
697 +-------------------------+
698 | Media Stream |
699 | |
700 Communication 1..* 0..* +-------------------------+
701 Session ------------| |
702 | Media Stream Reference |
703 | Content-type |
704 | |
705 +-------------------------+
707 A Media Stream class (and its objects) has the properties of media as
708 seen by SRC and sent to SRS. Different snapshots of media stream
709 object may be sent whenever there is a change in media (e.g. dir
710 change like pause/resume and/or codec change and/or participant
711 change.).
713 6.7.1. Attributes
715 A Media Stream class has the the following attributes:
717 o Media Stream Reference - In implementations this can reference to
718 m-line
719 o Content - The content of an MS element will be described in terms
720 of value from the [RFC4796] registry.
722 The metadata model should include media streams that are not being
723 delivered to the SRS. Examples include cases where SRC offered
724 certain media types but SRS chooses to accept only a subset of them
725 OR an SRC may not even offer a certain media type due it its
726 restrictions to record
728 6.7.2. Linkages
730 A Media Stream is linked to participant and CS classes using the
731 association relationship. The details of association with the
732 Participant are described in the Participant class section. The
733 details of association with CS is mentioned in the CS section.
735 6.7.3. XML element
737 stream element represents a Media Stream object. Stream element
738 indicates SDP media lines associated with the session and
739 participants.
741 This element indicates the SDP m-line properties like label
742 attributes. Label attribute is used to link m-line SDP body using
743 label attribute in SDP m-line.
745 Each stream element has unique Base 64 URN UUID attribute which helps
746 to uniquely identify stream and session Base 64 URN UUID to associate
747 stream with specific session element.
749 The content attribute if an SRC wishes to send is conveyed in RS SDP.
751 6.8. ParticipantStream Association
752 +-------------------+
753 | ParticipantSteam |
754 | Association |
755 +-------------------+ +----------Participant
756 | Association-Time | | 0..*| 1..*|
757 | Disassociaton-Time|---+ recv| |sends
758 | Recv | | 0..*| 0..*|
759 | Send | | | |
760 +-------------------+ | | |
761 +----------Media Stream
763 A ParticipantStream association class and its object has attributes
764 that are attributes of association of a Participant to a Stream.
766 6.8.1. Attributes
768 A participantStream association class has the following attributes:
770 o Associate-Time: This attributes indicates the time a Participant
771 started contributing to a Media Stream
772 o Disassociate-Time: This attribute indicates the time a Participant
773 stopped contributing to a Media Stream
775 6.8.2. Linkages
777 The participantStream association class is linked to participant and
778 Stream classes. There are no cardinalties for this linkage.
780 6.8.3. XML element
782 ParticipantStreamAssoc XML element represents participant to stream
783 association object. participant element is used to uniquely identify
784 this element and related with stream using stream unique URN id..
786 6.9. associate-time/disassociate-time
788 associate-time/disassociate-time contains a string indicating the
789 date and time of the status change of this tuple. The value of this
790 element MUST follow the IMPP datetime format [RFC3339]. Timestamps
791 that contain 'T' or 'Z' MUST use the capitalized forms. At a time,
792 any of the time tuple associate-time or disassociate-time MAY exist
793 in the element namely group, session, participant and not both
794 timestamp at the same time.
796 As a security measure, the timestamp element SHOULD be included in
797 all tuples unless the exact time of the status change cannot be
798 determined.
800 6.10. Unique ID format
802 Unique id is generated in two steps:
803 o UUID is created using [RFC4122])
804 o UUID is encoded using base64 as defined in [RFC4648]
806 The above mentioned unique-id mechanism SHOULD be used for each
807 metadata element.
809 7. SIP Recording Metadata Example
811 7.1. Complete SIP Recording Metadata Example
813 The following example provides all the tuples involved in Recording
814 Metadata XML body.
816
817
818 complete
819
820 2010-12-16T23:41:07Z
821
822
823 sip:alice@atlanta.com
824 FaXHlc+3WruaroDaNE87am==
825
826
827 FOO!
828 bar
829
830
831
832 7+OTCyoxTmqmqyA/1weDAg==
833
834 2010-12-16T23:41:07Z
835
836 FOO!
837 bar
838
839
842
843 Bob B
845
846
847 FOO!
848 bar
849
850
853 2010-12-16T23:41:07Z
854
855
857 i1Pz3to5hGk8fuXl+PbwCw==
858 UAAMm5GRQKSCMVvLyl4rFw==
859 8zc6e0lYTlWIINA6GR+3ag==
860 EiXGlc+4TruqqoDaNE76ag==
861
862
865
866 Paul
867
868
869 FOO!
870 bar
871
872
875 2010-12-16T23:41:07Z
876
877
879 8zc6e0lYTlWIINA6GR+3ag==
880 EiXGlc+4TruqqoDaNE76ag==
881 UAAMm5GRQKSCMVvLyl4rFw==
882 i1Pz3to5hGk8fuXl+PbwCw==
883
884
886
887
888
890
891
892
894
895
896
898
899
900
902 SIP Recording Metadata Example XML body
904 7.2. Partial Update of Recording metadata XML body
906 The following example provides partial update in Recording Metadata
907 XML body for the above example. The example has a snapshot that
908 carries the disassociate-time for a participant from a session.
910
911
912 partial
913
916
917 Bob R
918
919 FOO!
920 bar
921
922
925 2010-12-16T23:41:07Z
926
927
929 Partial update of SIP Recording Example XML body
931 8. XML Schema definition for Recording metadata
933 This section defines XML schema for Recording metadata document
935
936
941
942
943
944
945
946
948
950
952
954
956
960
961
962
963
964
966
968
972
973
975
976
977
978
980
982
986
987
989
990
991
992
994
996
1000
1001
1003
1004
1005
1006
1008
1012
1013
1015
1017
1018
1019
1020
1022
1024
1028
1029
1031
1033
1034
1035
1036
1038
1040
1044
1045
1047
1048
1049
1050
1052
1054
1056
1058
1062
1063
1065
1067
1068
1069
1070
1071
1072
1073
1075
1076
1077
1078
1079
1081
1083
1084
1085
1086
1087
1088
1089
1091
1093 9. Security Considerations
1095 The metadata information sent from SRC to SRS MAY reveal sensitive
1096 information about different participants in a session. For this
1097 reason, it is RECOMMENDED that a SRC use a strong means for
1098 authentication and metadata information protection and that it apply
1099 comprehensive authorization rules when using the metadata format
1100 defined in this document. The following sections will discuss each
1101 of these aspects in more detail.
1103 9.1. Connection Security
1105 It is RECOMMENDED that a SRC authenticate SRS using the normal SIP
1106 authentication mechanisms, such as Digest as defined in Section 22 of
1107 [RFC3261]. The mechanism used for conveying the metadata information
1108 MUST ensure integrity and SHOULD ensure confidentially of the
1109 information. In order to achieve these, an end-to-end SIP encryption
1110 mechanism, such as S/MIME described in [RFC3261], SHOULD be used.
1112 If a strong end-to-end security means (such as above) is not
1113 available, it is RECOMMENDED that a SRC use mutual hop-by-hop
1114 Transport Layer Security (TLS) authentication and encryption
1115 mechanisms described in "SIPS URI Scheme" and "Interdomain Requests"
1116 of [RFC3261].
1118 10. IANA Considerations
1120 This specification registers a new XML namespace, and a new XML
1121 schema.
1123 10.1. SIP recording metadata Schema Registration
1125 URI: urn:ietf:params:xml:ns:recording
1127 Registrant Contact: IETF SIPREC working group, Ram mohan
1128 R(rmohanr@cisco.com)
1130 XML: the XML schema to be registered is contained in Section 6.
1132 Its first line is and its last
1133 line is
1135 11. Acknowledgement
1137 We wish to thank John Elwell(Siemens-Enterprise), Henry Lum(Alcatel-
1138 Lucent), Leon Portman(Nice), De Villers, Andrew Hutton(Siemens-
1139 Enterprise), Deepanshu Gautam(Huawei), Charles Eckel(Cisco), Muthu
1140 Arul(Cisco), Michael Benenson(Cisco), Hadriel Kaplan (ACME), Brian
1141 Rosen(Neustar), Scott Orton(Broadsoft) for their valuable comments
1142 and inputs.
1144 We wish to thank Joe Hildebrand(Cisco), Peter Saint-Andre(Cisco) for
1145 the valuable XML related guidance and Martin Thompson for validating
1146 the XML schema and providing comments on the same.
1148 12. Appendix A: Metadata Model Object Instances
1150 This section describes the metadata model object instances for
1151 different use cases of SIPREC. For the sake of simplicity as the
1152 media streams sent by each of the participants is received by every
1153 other participant in these use cases, it is NOT shown in the object
1154 instance diagrams below. Also for the sake of ease not all
1155 attributes of each object are shown in these instance diagrams.
1157 12.1. Use case 1: Basic Call
1159 Basic call between two Participants A and B. In this use case each
1160 participant sends one Media Stream. For the sake of simplicity
1161 "receives" lines are not shown in this instance diagram. Media
1162 Streams sent by each participant is received all other participants
1163 of that CS.
1165 +-------------------------------+
1166 | Recording Session (RS) |
1167 +-------------------------------+
1168 |
1169 |
1170 |
1171 +----------------+
1172 | Communication |
1173 | Session (CS) |
1174 +----------------+-----------------------+
1175 | Start Time | |
1176 +----------------+ |
1177 | |
1178 |-------------------+ |
1179 | | |
1180 +---------------+ +---------------+ |
1181 | ParticipantA | | ParticipantB | |
1182 | | | | |
1183 +---------------+ +---------------+ |
1184 | | |
1185 sends | | sends |
1186 | | |
1187 +---------------+ +---------------+ |
1188 |Media Stream A1| |Media Stream B1| |
1189 +---------------+ +---------------+ |
1190 |MediaStream Ref| |MediaStream Ref| |
1191 | | | | |
1192 +---------------+ +---------------+ |
1193 | | |
1194 +-----------------------------------+
1196 12.2. Use case 2: Hold/Resume
1198 Basic call between two Participants A and B and with Participant A or
1199 B doing a Hold/Resume. In this use case each participant sends one
1200 Media Stream. After Hold/Resume the properties of Media can change.
1201 For the sake of simplicity "receives" lines are not shown in this
1202 instance diagram. Media Streams sent by each participant is received
1203 all other participants of that CS.
1205 +-------------------------------+
1206 | Recording Session (RS) |
1207 +-------------------------------+
1208 | |
1209 | |
1210 | |
1211 | +-------------------------------+
1212 | | Communication Session (CS) |
1213 | +-----------| Group(CSG) |
1214 | | +-------------------------------+
1215 | | | Unique-id1 |
1216 | | +-------------------------------+
1217 | |
1218 | |
1219 | |
1220 +----------------+
1221 | Communication |
1222 +-| Session (CS) |----------------------------------------------+
1223 | +----------------+ |
1224 | | | |
1225 | +----------------+ |
1226 | | |
1227 | |-------------------+ |
1228 | | | |
1229 | +---------------+ +---------------+ |
1230 | | ParticipantA | | ParticipantB |-----------+ |
1231 | | |--+ | | | |
1232 | +---------------+ | +---------------+ |sends(After |
1233 | | | | | | | Resume) |
1234 | | | | | | +--------------+ |
1235 | sends | | +--+ | sends | |MediaStream B3| |
1236 | | -----+ | | +-----+ +--------------+ |
1237 | +---------------+ | | +---------------+ | |MediaStreamRef|-|
1238 | |Media Stream A1| | | |Media Stream B1| | | | |
1239 | +---------------+ | | +---------------+ | | | |
1240 +-|MediaStreamref | | | |MediaStreamRef | | +--------------+ |
1241 | | | | | |-|-------------------|
1242 +---------------+ | | +---------------+ | |
1243 | | | |
1244 +------------+ |sends |sends (hold) |
1245 | sends |(Resume) | |
1246 | (hold) +-------+ +-------+ |
1247 | | | |
1248 +---------------+ +---------------+ +--------------+ |
1249 |Media Stream A2| |Media Stream A3| |MediaStream B2| |
1250 +---------------+ +---------------+ | | |
1251 |MediaStreamref | |MediaStreamRef | +--------------+ |
1252 | | | | |Codec Params | |
1253 +---------------+ +---------------+ | | |
1254 | | | | |
1255 | | +--------------+ |
1256 | | | |
1257 +------------------------------------------------------+
1259 12.3. Use case 3: Basic call with Transfer
1261 Basic call between two Participants A and B and with Participant A
1262 transfer(consult transfer) to Participant C. In this use case each
1263 participant sends one Media Stream. After transfer the properties of
1264 Participant A Media can change. For the sake of simplicity
1265 "receives" lines are not shown in this instance diagram. Media
1266 Streams sent by each participant is received all other participants
1267 of that CS.
1269 +-------------------------------+
1270 | Recording Session (RS) |-------+
1271 +-------------------------------+ |
1272 | |
1273 | |
1274 | |
1275 +-------------------------------+ |
1276 | Communication Session (CS) | |
1277 | Group(CSG) | |
1278 +-------------------------------+ |
1279 | Unique-id1 | |
1280 +-------------------------------+ |
1281 | |
1282 |----------------------------+
1283 |
1284 |-----------------+
1285 | |
1286 +----------------+ +----------------+
1287 | Communication | | Communication |
1288 | Session (CS)1 | | Session (CS)2 |
1289 +----------------+ +----------------+-----------+
1290 | | | | |
1291 +----------------+ +----------------+ |
1292 | |
1293 |-------------------+ |
1294 | | | |
1295 +---------------+ | +---------------+ |
1296 | ParticipantA | | | ParticipantB | |
1297 | | | | | |
1298 +---------------+ | +---------------+ |
1299 | | | |
1300 sends | | | sends |
1301 | | | |
1302 +---------------+ | +---------------+ |
1303 |Media Stream A1| | |Media Stream B1| |
1304 +---------------+ | +---------------+ |
1305 | | | | | |
1306 | | | | Media Stream | |
1307 | Media Stream |---+---| Ref | |
1308 | Ref | | | |
1309 +---------------+ +---------------+ |
1310 |
1311 |
1312 +----------------------------|
1313 | |
1314 +--------------------------------+ |
1315 | | |
1316 +---------------+ +---------------+ |
1317 | Participant A | | Participant C | |
1318 | (same) | | | |
1319 +---------------+ +---------------+ |
1320 | | |
1321 | sends (After transfer) | sends |
1322 +----------------+ +----------------+|
1323 | Media Stream A2| | Media Stream C1||
1324 +----------------+ +----------------+|
1325 | Media StreamRef| | Media StreamRef||
1326 | | | ||
1327 | | | ||
1328 +----------------+ +----------------+|
1329 | | |
1330 | | |
1331 | | |
1332 +-------------------------------------------+
1334 12.4. Conference Use Cases
1336 Depending on who act as SRC and the information that an SRC has there
1337 can be several ways to model conference use cases. This section has
1338 instance diagrams for the following cases:
1340 o A CS where one of the participant (which is also SRC) is a user in
1341 a conference
1342 o A CS where one of the participant is focus ( which is also SRC)
1343 o A CS where one of the participant is user and the SRC is a
1344 different entity like B2BUA
1345 o A CS where one of the participant is focus and the SRC is a
1346 different entity like B2BUA
1348 NOTE: There MAY be other ways to model the same use cases depending
1349 on what information the SRC has.
1351 12.4.1. Case 1:
1353 This is the usecase where there is a CS with one of the participant
1354 (who is also SRC) as a user in a conference. For the sake of
1355 simplicity the receive lines for each of the participant is not
1356 shown.
1358 +---------------------------------------------------+
1359 | Communication Session |
1360 | +-------------+ +--------------+ |
1361 | | | | | |
1362 | |Participant B| | Participant A| |
1363 | | (User in |--------------| | |
1364 | | conf/SRC) | | | |
1365 | +-------------+ +--------------+ |
1366 | | | | | |
1367 +---------------------------------------------------+
1368 | | | |
1369 | | | |
1370 D E F G (Participants of Conference)
1372 Instance Diagram:
1374 +-------------------------------+
1375 | Recording Session (RS) |--+
1376 +-------------------------------+ |
1377 | |
1378 | |
1379 | |
1380 +-------------------------------+ |
1381 | Communication Session (CS) | |
1382 | Group(CSG) | |
1383 +-------------------------------+ |
1384 | Unique-id1 | |
1385 +-------------------------------+ |
1386 | |
1387 |-----------------------+
1388 |
1389 +----------------+
1390 | Communication |
1391 | Session (CS) |--+----------------+-----+
1392 +----------------+ | | |
1393 | | | | |
1394 +----------------+ | | |
1395 | | | |
1396 | | | |
1397 | | | |
1398 +---------------+ | | |
1399 | ParticipantA | | | |
1400 | | | | |
1401 +---------------+ | | |
1402 | | | |
1403 sends | | | |
1404 | | | |
1405 +---------------+ | | |
1406 |Media Stream A1| | | |
1407 +---------------+ | | |
1408 |MediaStream Ref|-----|----------------+ |
1409 | | | | |
1410 +---------------+ | | |
1411 | | |
1412 | | |
1413 +-------------+ | |
1414 | | |
1415 | | |
1416 +----------------+ | |
1417 | Participant B | | |
1418 | (in conf) | | |
1419 +----------------+ | |
1420 | | |
1421 sends | | |
1422 | | |
1423 +----------------+ | |
1424 | Media Stream B1|---------------------+ |
1425 +----------------+ sends |
1426 | MediaStream Ref| |
1427 | | +-----------------+
1428 +----------------+ |
1429 | |
1430 |sends |
1431 | |
1432 +-----------------+-------------+------------+
1433 | | | |
1434 | | | |
1435 +------------+ +------------+ +------------+ +-------------+
1436 |participantD| |ParticipantE| |ParticipantF| |Participant G|
1437 +------------+ +------------+ +------------+ +-------------+
1439 In this example we have two participants A and B who are part of a
1440 Communication Session(CS). One of the participants B is part of a
1441 conference and also acts as SRC.There can be two cases here. B can
1442 be a participant of the conference or B can be a focus. In this
1443 instance diagram Participant B is a user in a conference. The SRC
1444 (Participant B) subscribes to conference event package to get the
1445 details of other particiants. Participant B(SRC) sends the same
1446 through the metadata to SRS. In this instance diagram the Media
1447 Stream(mixed stream) sent from Participant B has media streams
1448 contributed by conference participants (D,E,F and G). For the sake
1449 of simplicity the "receives" line is not shown here. In this example
1450 the media stream sent by each participant(A or B) of CS is received
1451 by all other participant(A or B).
1453 12.4.2. Case 2:
1455 This is the usecase where there is a CS where one of the participant
1456 is focus ( which is also SRC).
1458 +---------------------------------------------------+
1459 | Communication Session |
1460 | +--------------+ +--------------+ |
1461 | | |--------------| | |
1462 | |Participant C | | Participant A| |
1463 | | (Focus in |------+ | | |
1464 | | conf and SRC)|---+ | +--------------+ |
1465 | +--------------+ | | |
1466 | | | +---------+ |
1467 | | | | |
1468 | +--------------+ | +---------------+ |
1469 | | Participant B| +---+ | Participant D | |
1470 | | | | | | |
1471 | +--------------+ | +---------------+ |
1472 | | |
1473 | +--------------+ |
1474 | |Participant E | |
1475 | | | |
1476 | +--------------+ |
1477 | |
1478 +---------------------------------------------------+
1480 Instance Diagram:
1482 +-------------------------------+
1483 | Recording Session (RS) |
1484 +-------------------------------+
1485 |-------------------------+
1486 | |
1487 | |
1488 +-------------------------------+ |
1489 | Communication Session (CS) | |
1490 | Group(CSG) | |
1491 +-------------------------------+ |
1492 | Unique-id1 | |
1493 +-------------------------------+ |
1494 | |
1495 |-------------------------+
1496 |
1497 +----------------+
1498 | Communication |
1499 | Session (CS) |----------------------+
1500 +----------------+ |
1501 | | |
1502 +----------------+ |
1503 | |
1504 |-------------------+ |
1505 | | | |
1506 +---------------+ | +---------------+ |
1507 | ParticipantA | | | ParticipantB | |
1508 | | | | | |
1509 +---------------+ | +---------------+ |
1510 | | | |
1511 sends | | | sends |
1512 | | | |
1513 +---------------+ | +---------------+ |
1514 |Media Stream A1| | |Media Stream B1| |
1515 +---------------+ | +---------------+ |
1516 |MediaStream Ref| | |MediaStream Ref| |
1517 | |---+---| | |
1518 +---------------+ +---------------+ |
1519 |
1520 +----------------------------------+
1521 | | | |
1522 | | | |
1523 +---------------+ | +---------------+ |
1524 | ParticipantD | | | ParticipantE | |
1525 | | | | | |
1526 +---------------+ | +---------------+ |
1527 | | | |
1528 sends | | | sends |
1529 | | | |
1530 +---------------+ | +---------------+ |
1531 |Media Stream D1| | |Media Stream E1| |
1532 +---------------+ | +---------------+ |
1533 |MediaStream Ref| | |MediaStream Ref| |
1534 | |---+---| | |
1535 +---------------+ +---------------+ |
1536 |
1537 |
1538 +----------+
1539 +-----------------|
1540 | |
1541 | |
1542 +----------------+ |
1543 | Participant C | |
1544 | (focus +src) | |
1545 +----------------+ |
1546 | |
1547 Sends | +-------+
1548 | |
1549 "sends" OR | |
1550 contributed +----------------+
1551 by | Media Stream C1|
1552 Participants+----------------+ "receives" by participants A,B,D,E
1553 A,B,D,E | MediaStream Ref|------------------------------------
1554 ------------| Codec Params |
1555 +----------------+
1557 In this example we have two participants A and B who are part of a
1558 Communication Session(CS). One of the participants (C) is focus of a
1559 conference and also acts as SRC. The SRC (Participant C) being the
1560 Focus of the conference has access to the details of other
1561 particiants. SRC (Participant C) sends the same through the metadata
1562 to SRS. In this instance diagram the Media Stream(mixed stream) sent
1563 by C has media streams contributed by conference participants (A, B,
1564 D and E). Participants A, B,D and E sends Media Streams A1, B1, D1
1565 and E1 respectively. The media stream sent by Participant C(Focus)
1566 is received by all other participants of CS. For the sake of
1567 simplicity the "receives" line is not shown linked to all other
1568 participants.
1570 NOTE: SRC ( Participant C) can send mixed stream or seperate streams
1571 to SRS
1573 12.4.3. Case 3:
1575 A CS where one of the participant is user and the SRC is a different
1576 entity like B2BUA. In this case the SRC may not know that one of the
1577 user is part of conference. Hence the instance diagram will not have
1578 information about the conference participants.
1580 +---------------------------------------------------+
1581 | Communication Session |
1582 | +-------------+ +------+ +--------------+ |
1583 | | | | (SRC)| | | |
1584 | |Participant B|--|B2BUA |----| Participant A| |
1585 | | (User in | +------+ | | |
1586 | | conf) | | | |
1587 | +-------------+ +--------------+ |
1588 | | | | | |
1589 +---------------------------------------------------+
1590 | | | |
1591 | | | |
1592 D E F G (Participants of Conference)
1594 12.4.4. Case 4:
1596 A CS where one of the participant is focus and the SRC is a different
1597 entity like B2BUA. In this case the participant which is focus sends
1598 "isfocus" in SIP message to SRC. The SRC subscribe to conference
1599 event package on seeing this "isfocus". SRC learns the details of
1600 other participants of conference from the conference package and send
1601 the same in metadata to SRS. The instance diagram for this use case
1602 is same as Case 1.
1604 +--------------------------------+
1605 | Conference Event Package |
1606 | |
1607 +--------------------------------+
1608 |
1609 | subscribes
1610 |
1611 +---------------------|-----------------------------+
1612 | Communication |Session |
1613 | +-------------+ +------+ +--------------+ |
1614 | | | | (SRC)| | | |
1615 | |Participant B|--|B2BUA |----| Participant A| |
1616 | | (FOCUS in | +------+ | | |
1617 | | conf) | | | |
1618 | +-------------+ +--------------+ |
1619 | | | | | |
1620 +---------------------------------------------------+
1621 | | | |
1622 | | | |
1623 D E F G (Participants of Conference)
1625 13. Appendix B: Metadata XML schema Instances
1627 This section describes the metadata model XML instances for different
1628 use cases of SIPREC. For the sake of simplicity the complete SIP
1629 messages are NOT shown here.
1631 13.1. Use case 1: Basic Call
1633 Basic call between two Participants A(Ram) and B(Partha) who are part
1634 of one session. In this use case each participant sends two Media
1635 Streams. Media Streams sent by each participant is received all
1636 other participants of that CS in this use-case. Below is the initial
1637 snapshot sent by SRC that has complete metadata. For the sake of
1638 completeness even snippets of SDP is shown. For the sake of
1639 simplicity these use-cases assume the RS stream is unmixed.
1641 Content-Type: application/SDP
1642 ...
1643 m=audio 49170 RTP/AVP 0
1644 a=rtpmap:0 PCMU/8000
1645 a=label:96
1646 a=sendonly
1647 ...
1648 m=video 49174 RTP/AVPF 96
1649 a=rtpmap:96 H.264/90000
1650 a=label:97
1651 a=sendonly
1652 ...
1653 m=audio 51372 RTP/AVP 0
1654 a=rtpmap:0 PCMU/8000
1655 a=label:98
1656 a=sendonly
1657 ...
1658 m=video 49176 RTP/AVPF 96
1659 a=rtpmap:96 H.264/90000
1660 a=label:99
1661 a=sendonly
1662 ....
1663
1664
1665 complete
1666
1667 2010-12-16T23:41:07Z
1668
1669
1670 sip:alice@cisco.com
1671
1672
1673 FOO!
1674 bar
1675
1676
1677
1678 7+OTCyoxTmqmqyA/1weDAg==
1679
1680 2010-12-16T23:41:07Z
1681
1682 FOO!
1683 bar
1684
1685
1688
1689 RamMohan R
1690
1691
1692 FOO!
1693 bar
1694
1695
1698 2010-12-16T23:41:07Z
1699
1700
1702 i1Pz3to5hGk8fuXl+PbwCw==
1703 UAAMm5GRQKSCMVvLyl4rFw==
1704 8zc6e0lYTlWIINA6GR+3ag==
1705 EiXGlc+4TruqqoDaNE76ag==
1706
1707
1710
1711 Parthasarathi R
1712
1713
1714 FOO!
1715 bar
1716
1717
1721 2010-12-16T23:41:07Z
1722
1723
1725 8zc6e0lYTlWIINA6GR+3ag==
1726 EiXGlc+4TruqqoDaNE76ag==
1727 UAAMm5GRQKSCMVvLyl4rFw==
1728 i1Pz3to5hGk8fuXl+PbwCw==
1729
1730
1732
1733
1734
1736
1737
1738
1740
1741
1742
1744
1745
1746
1748 13.2. Use case 2: Hold/resume
1750 Basic call between two Participants A and B. This is the continuation
1751 of above use-case. One of the participants(say A) goes on hold and
1752 then resumes as part of the same session. The metadata snapshot
1753 looks as below
1755 During hold
1756 Content-Type: application/SDP
1757 ...
1758 m=audio 49170 RTP/AVP 0
1759 a=rtpmap:0 PCMU/8000
1760 a=label:96
1761 a=inactive
1762 ...
1763 m=video 49174 RTP/AVPF 96
1764 a=rtpmap:96 H.264/90000
1765 a=label:97
1766 a=inactive
1767 ...
1768 m=audio 51372 RTP/AVP 0
1769 a=rtpmap:0 PCMU/8000
1770 a=label:98
1771 a=sendonly
1772 ...
1773 m=video 49176 RTP/AVPF 96
1774 a=rtpmap:96 H.264/90000
1775 a=label:99
1776 a=sendonly
1777 ....
1779
1780
1781 partial
1782
1785 8zc6e0lYTlWIINA6GR+3ag==
1786 EiXGlc+4TruqqoDaNE76ag==
1787
1788
1791 8zc6e0lYTlWIINA6GR+3ag==
1792 EiXGlc+4TruqqoDaNE76ag==
1793
1795
1797 During resume
1799 The snapshot will look pretty much same as Use-case 1.
1801 13.3. Use case 3: Basic Call with transfer
1803 Basic call between two Participants A and B is connected as in Use-
1804 case 1. Transfer is initiated by one of the participants of by other
1805 entity(3PCC case). SRC sends a snapshot of the participant changes
1806 to SRS. In this instance participant A(Ram) drops out during the
1807 transfer and Participant C(Paul) joins the session. There can be two
1808 cases here, same session continues after transfer or a new session
1809 (e.g. REFER based transfer) is created
1811 Transfer with same session retained - (.e.g. RE-INVITE based
1812 transfer). Participant A drops out and C is added to the same
1813 session. No change to session/group element. C will be new stream
1814 element which maps to RS SDP using the same labels in this instance.
1816 Content-Type: application/SDP
1817 ...
1818 m=audio 49170 RTP/AVP 0
1819 a=rtpmap:0 PCMU/8000
1820 a=label:96
1821 a=sendonly
1822 ...
1823 m=video 49174 RTP/AVPF 96
1824 a=rtpmap:96 H.264/90000
1825 a=label:97
1826 a=sendonly
1827 ...
1828 m=audio 51372 RTP/AVP 0
1829 a=rtpmap:0 PCMU/8000
1830 a=label:98
1831 a=sendonly
1832 ...
1833 m=video 49176 RTP/AVPF 96
1834 a=rtpmap:96 H.264/90000
1835 a=label:99
1836 a=sendonly
1837 ....
1838
1839
1840 partial
1841
1843 8zc6e0lYTlWIINA6GR+3ag==
1844 EiXGlc+4TruqqoDaNE76ag==
1845 60JAJm9UTvik0Ltlih/Gzw==
1846 AcR5FUd3Edi8cACQJy/3JQ==
1847
1848
1851
1852 Paul Kyzivat
1853
1854 60JAJm9UTvik0Ltlih/Gzw==
1855 AcR5FUd3Edi8cACQJy/3JQ==
1856 8zc6e0lYTlWIINA6GR+3ag==
1857 EiXGlc+4TruqqoDaNE76ag==
1858 2010-12-16T23:41:07Z
1859
1860 FOO!
1861 bar
1862
1863
1866 2010-12-16T23:41:07Z
1867
1868
1870 60JAJm9UTvik0Ltlih/Gzw==
1871 AcR5FUd3Edi8cACQJy/3JQ==
1872 8zc6e0lYTlWIINA6GR+3ag==
1873 EiXGlc+4TruqqoDaNE76ag==
1874
1875
1877
1878
1879
1881
1882
1883
1885
1886
1887
1889
1890
1891
1893 Transfer with new session - (.e.g. REFER based transfer). In this
1894 case new session is part of same grouping (done by SRC).
1896 SRC may send an optional snapshot indicating stop for the old
1897 session.
1899
1900
1901 Partial
1902
1903 7+OTCyoxTmqmqyA/1weDAg==
1904
1905 2010-12-16T23:41:07Z
1906
1907 FOO!
1908 bar
1909
1910
1913 2010-12-16T23:41:07Z
1914
1915
1918 2010-12-16T23:41:07Z
1919
1920
1922 SRC sends a snapshot to indicate the participant change and new
1923 session information after transfer. In this example the same RS is
1924 used.
1926 Content-Type: application/SDP
1927 ...
1928 m=audio 49170 RTP/AVP 0
1929 a=rtpmap:0 PCMU/8000
1930 a=label:96
1931 a=sendonly
1932 ...
1933 m=video 49174 RTP/AVPF 96
1934 a=rtpmap:96 H.264/90000
1935 a=label:97
1936 a=sendonly
1937 ...
1938 m=audio 51372 RTP/AVP 0
1939 a=rtpmap:0 PCMU/8000
1940 a=label:98
1941 a=sendonly
1942 ...
1943 m=video 49176 RTP/AVPF 96
1944 a=rtpmap:96 H.264/90000
1945 a=label:99
1946 a=sendonly
1947 ....
1948
1949
1950 partial
1951
1952 7+OTCyoxTmqmqyA/1weDAg==
1953
1954 2010-12-16T23:41:07Z
1955
1956 FOO!
1957 bar
1958
1959
1962
1963
1964 FOO!
1965 bar
1966
1967
1970 2010-12-16T23:32:03Z
1971
1972
1974 8zc6e0lYTlWIINA6GR+3ag==
1975 EiXGlc+4TruqqoDaNE76ag==
1976 60JAJm9UTvik0Ltlih/Gzw==
1977 AcR5FUd3Edi8cACQJy/3JQ==
1978
1979
1982
1983
1984 FOO!
1985 bar
1986
1987
1990 2010-12-16T23:41:07Z
1991
1992
1994 60JAJm9UTvik0Ltlih/Gzw==
1995 AcR5FUd3Edi8cACQJy/3JQ==
1996 8zc6e0lYTlWIINA6GR+3ag==
1997 EiXGlc+4TruqqoDaNE76ag==
1998
1999
2001
2002
2003
2005
2006
2007
2009
2010
2011
2013
2014
2015
2017 13.4. Use Case 4: Call disconnect
2019 This example shows a snapshot of metadata sent by an SRC at CS
2020 disconnect where the participants of CS are Ram and Partha
2021
2022
2023 Partial
2024
2025 7+OTCyoxTmqmqyA/1weDAg==
2026
2027 2010-12-16T23:41:07Z
2028
2029 FOO!
2030 bar
2031
2032
2035
2036 2010-12-16T23:41:07Z
2037
2039
2042
2043 2010-12-16T23:41:07Z
2044
2045
2047 14. References
2049 14.1. Normative References
2051 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2052 Requirement Levels", BCP 14, RFC 2119, March 1997.
2054 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
2056 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
2057 A., Peterson, J., Sparks, R., Handley, M., and E.
2058 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
2059 June 2002.
2061 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
2062 January 2004.
2064 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
2065 Internet: Timestamps", RFC 3339, July 2002.
2067 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
2068 Description Protocol", RFC 4566, July 2006.
2070 [RFC4574] Levin, O. and G. Camarillo, "The Session Description
2071 Protocol (SDP) Label Attribute", RFC 4574, August 2006.
2073 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description
2074 Protocol (SDP) Content Attribute", RFC 4796,
2075 February 2007.
2077 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
2078 "Indicating User Agent Capabilities in the Session
2079 Initiation Protocol (SIP)", RFC 3840, August 2004.
2081 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
2082 Unique IDentifier (UUID) URN Namespace", RFC 4122,
2083 July 2005.
2085 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
2086 Encodings", RFC 4648, October 2006.
2088 14.2. Informative References
2090 [RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use
2091 Cases and Requirements for SIP-Based Media Recording
2092 (SIPREC)", RFC 6341, August 2011.
2094 [I-D.ietf-siprec-architecture]
2095 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An
2096 Architecture for Media Recording using the Session
2097 Initiation Protocol", draft-ietf-siprec-architecture-05
2098 (work in progress), May 2012.
2100 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
2101 August 1999.
2103 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
2104 Header Field for the Session Initiation Protocol (SIP)",
2105 RFC 3326, December 2002.
2107 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
2108 Extensions to the Session Initiation Protocol (SIP) for
2109 Asserted Identity within Trusted Networks", RFC 3325,
2110 November 2002.
2112 Authors' Addresses
2114 Ram Mohan Ravindranath
2115 Cisco Systems, Inc.
2116 Cessna Business Park,
2117 Kadabeesanahalli Village, Varthur Hobli,
2118 Sarjapur-Marathahalli Outer Ring Road
2119 Bangalore, Karnataka 560103
2120 India
2122 Email: rmohanr@cisco.com
2124 Parthasarathi Ravindran
2125 Sonus Networks
2126 Prestige Shantiniketan - Business Precinct
2127 Whitefield Road
2128 Bangalore, Karnataka 560066
2129 India
2131 Email: pravindran@sonusnet.com
2133 Paul Kyzivat
2134 Unaffiliated
2135 Boxborough, MA
2136 USA
2138 Email: pkyzivat@alum.mit.edu