idnits 2.17.1
draft-ietf-siprec-metadata-06.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 (March 12, 2012) is 4427 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-04
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: September 13, 2012 Sonus Networks
5 Paul. Kyzivat
6 Unaffiliated
7 March 12, 2012
9 Session Initiation Protocol (SIP) Recording Metadata
10 draft-ietf-siprec-metadata-06
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 September 13, 2012.
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 . . . . . . . . 25
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 present in all recording metadata XML document. recording acts
260 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 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 +-------------------------------+
422 | |
423 | 0..* |0..*
424 | |
425 | 0..* |0..*
426 Participant Media Stream
428 A Communication Session class and its object in the metadata model
429 represents Communication Session and its properties needed as seen by
430 SRC.
432 6.3.1. Attributes
434 A communication Session class has the following attributes:
436 o Termination Reason - This represents the reason why a CS was
437 terminated. The communication session MAY contain a Call
438 Termination Reason. This MAY be derived from SIP Reason header
439 [RFC3326] of CS.
440 o CS Identifier - This attribute is used to uniquely identify a CS.
442 This document does not specify attributes relating to what should
443 happen to a recording of a CS after it has been delivered to the SRS,
444 e.g., how long to retain the recording, what access controls to
445 apply. The SRS is assumed to behave in accordance with policy. The
446 ability for the SRC to influence this policy is outside the scope of
447 this document. However if there are implementations where SRC has
448 enough information, this could be sent as Extension Data attached to
449 CS
451 6.3.2. Linkages
453 A Communication Session is linked to CS-Group, Participant, Media
454 Stream and Recording Session classes using the association
455 relationship. Association between CS and Participant allows:
457 o CS to have atleast zero or more participants
458 o Participant is associated with zero or more CSs. This includes
459 participants who are not directly part of any CS. An example of
460 such a case is participants in a premixed media stream. The SRC
461 may have knowledge of such Participants, yet not have any
462 signaling relationship with them. This might arise if one
463 participant in CS is a conf focus. To summarize even if SRC does
464 not have direct signalling relationships with all participants in
465 a CS, it should nevertheless create a Participant object for each
466 participant that it knows about.
467 o The model also allows participants in CS that are not participants
468 in the media. An example is the identity of a 3pcc controller
469 that has initiated a CS to two or more participants of the CS.
470 Another example is the identity of a conference focus. Of course
471 a focus is probably in the media, but since it may only be there
472 as a mixer, it may not report itself as a participant in any of
473 the media streams.
475 Association between CS and Media Stream allows:
477 o A CS to have zero or more Streams
478 o A stream can be associated with zero or more CS. An example is
479 multicast MoH stream which might be associated with many CSs.
480 stream in persistent RS is not required to be associated with any
481 CS before CS is created.
483 Association between CS and RS allows:
485 o Each instance of RS has Zero or more instances of Communication
486 Session objects.
487 o Each CS has to be associated with one more RS [ Here each RS can
488 be potentially setup by different SRCs]
490 6.3.3. XML element
492 Session element provides the information about the communication
493 session
495 Each communication session(CS) object is represented by one session
496 element. Each session element has unique Base 64 URN UUID attribute
497 which helps to uniquely identify CS.
499 Reason element MAY be included to represent the Termination Reason
500 attribute. group-ref element MAY exist to indicate the group where
501 the mentioned session belongs.
503 6.4. CSRSAssociation
505 1..* 1..*
506 Recording Communication
507 Session ----------+---------- Session
508 |
509 |
510 |
511 +-------------------+
512 | CSRSAssociation |
513 +-------------------+
514 | Association-Time |
515 | Disassociaton-Time|
516 +-------------------+
518 A CSRS Association class and its objects has attributes of CS object
519 which are attributes of association of a session to a RS
521 6.4.1. Attributes
523 CSRS association class has the following attributes:
525 o Associate-time - associate-time is calculated by SRC as the time
526 it sees a CS is associated to RS
527 o Disassociate-time- Disassociate-time is calculated by SRC as the
528 time it see a CS disassociate from a RS. It is possible that a
529 given CS can have multiple associate/disassociate times within
530 given RS.
532 6.4.2. Linkages
534 CSRS association class is linked to CS and RS classes. There are no
535 cardinalties for this linkage.
537 6.4.3. XML element
539 sessionrecordingassoc is the XML element to represent CSRS
540 association object. session URN UUID is used to uniquely identify
541 this element and link with the specific session.
543 6.5. Participant
545 Communication Session (CS)
546 | 0..*
547 |
548 | 0..*
549 +-------------------------------+
550 | Participant |
551 | |
552 +-------------------------------+
553 | AoR / Name Pair list |
554 | |
555 | |
556 +-------------------------------+
557 | 0..* 1..*|
558 receives| |sends
559 | 0..* 0..*|
560 Media Stream
562 A Participant class and its objects has information about a device
563 that is part of a CS and/or contributes/consumes media stream(s)
564 belonging to a CS.
566 6.5.1. Attributes
568 Participant has attributes like:
570 o AoR / Name pair list - This attribute is a list of Name/AoR tuple.
571 An AoR MAY be SIP/SIPS/TEL URI. Name represents Participant
572 name(SIP display name) or DN number ( in case it is known). There
573 are cases where a participant can have more than one AoR [e.g.
574 P-Asserted-identity header [RFC3325] which can have both SIP and
575 TEL URIs]
577 This document does not specify other attributes relating to
578 participant e.g. Participant Role, Participant type. An SRC which
579 has information of these attributes can indicate the same as part of
580 extension data to Participant from SRC to SRS.
582 6.5.2. Linkages
584 The participant class is linked to MS and CS class using association
585 relationship. The association between participant and Media Stream
586 allows:
588 o Participant to receives zero or more media streams
589 o Participant to send zero or more media streams. (Same participant
590 provides multiple streams e.g. audio and video)
591 o Media stream to be received by zero or more participants. Its
592 possible, though perhaps unlikely, that a stream is generated but
593 sent only to the SRC and SRS, not to any participant. E.g. In
594 conferencing where all participants are on hold and the SRC is
595 collocated with the focus. Also a media stream may be received by
596 multiple participants (e.g. Whisper calls, side conversations).
597 o Media stream to be sent by one or more participants (pre-mixed
598 streams).
600 Example of a case where a participant receives Zero or more streams -
601 a Supervisor may have side conversation with Agent, while Agent
602 converses with customer.
604 6.5.3. XML element
606 A participant element represents a Participant object.
608 Participant MUST have a NameID complex element which contains AoR as
609 attribute and Name as element. AOR element is SIP/SIPS URI FQDN or
610 IP address which represents the user. name is an optional element to
611 represent display name.
613 Each participant element has unique ID (Base 64 URN UUID) attribute
614 which helps to uniquely identify participant and session Base 64 URN
615 UUID to associate participant with specific session element. Base 64
616 URN UUID of participant MUST used in the scope of CSG and no new Base
617 64 URN UUID has to be created for the same element (participant,
618 stream) between different CS in the same CSG. In case Base 64 URN
619 UUID has to be used permanent, careful usage of Base 64 URN UUID to
620 original AoR has to be decided by the implementers and it is
621 implementer's choice.
623 6.6. ParticipantCSAssociation
625 1..* 1..*
626 Communication
627 Session ----------+---------- Participant
628 |
629 |
630 |
631 +-------------------+
632 | ParticipantCS |
633 | Association |
634 +-------------------+
635 | Capabilities |
636 | Association-Time |
637 | Disassociaton-Time|
638 +-------------------+
640 A participantCS Association class and its objects has attributes of
641 participant object which are attributes of association of a
642 participant to a Session.
644 6.6.1. Attributes
646 ParticipantCS association class has the following attributes:
648 o Associate-time - associate-time is calculated by SRC as the time
649 it sees a participant is associated to CS
650 o Disassociate-time- Disassociate-time is calculated by SRC as the
651 time it see a participant disassociate from a CS. It is possible
652 that a given participant can have multiple associate/disassociate
653 times within given communication session.
654 o Capabilities - A participant capabilities as defined in [RFC3840]
655 which is an optional attribute that includes the capabilities of a
656 participant in a CS. Each participant shall have Zero or more
657 capabilities. A participant may use different capabilities
658 depending on the role it plays at a particular instance. IOW if a
659 participants moves across different CSs ( due to transfer e.t.c)
660 OR is simultaneously present in different CSs its role may be
661 different and hence the capability used.
662 o "send" or "recv" element in each participant is associating SDP
663 m-lines with the participant. send element indicates that
664 participant is sending the stream of media with the mentioned
665 media description. recv element indicates that participant is
666 receiving the stream and by default all participant will receive
667 the stream. recv element has relevance in case whisper call
668 scenario wherein few of the participant in the session receives
669 the stream and not others.
671 6.6.2. Linkages
673 The participantCS association class is linked to participant and CS
674 classes. There are no cardinalties for this linkage.
676 6.6.3. XML element
678 participantsessionassoc XML element represent participantCS
679 association object. participant and session id is used to uniquely
680 identify this element
682 NOTE: RFC 4235 encoding shall be used to represent capabilities
683 attribute in XML.
685 6.7. Media Stream
687 Participant
688 | 0..* 1..*|
689 receives| |sends
690 | 0..* 0..*|
691 +-------------------------+
692 | Media Stream |
693 | |
694 Communication 1..* 0..* +-------------------------+
695 Session ------------| |
696 | Media Stream Reference |
697 | Content-type |
698 | |
699 +-------------------------+
701 A Media Stream class (and its objects) has the properties of media as
702 seen by SRC and sent to SRS. Different snapshots of media stream
703 object may be sent whenever there is a change in media (e.g. dir
704 change like pause/resume and/or codec change and/or participant
705 change.).
707 6.7.1. Attributes
709 A Media Stream class has the the following attributes:
711 o Media Stream Reference - In implementations this can reference to
712 m-line
713 o Content - The content of an MS element will be described in terms
714 of value from the [RFC4796] registry.
716 The metadata model should include media streams that are not being
717 delivered to the SRS. Examples include cases where SRC offered
718 certain media types but SRS chooses to accept only a subset of them
719 OR an SRC may not even offer a certain media type due it its
720 restrictions to record
722 6.7.2. Linkages
724 A Media Stream is linked to participant and CS classes using the
725 association relationship. The details of association with the
726 Participant are described in the Participant class section. The
727 details of association with CS is mentioned in the CS section.
729 6.7.3. XML element
731 stream element represents a Media Stream object. Stream element
732 indicates SDP media lines associated with the session and
733 participants.
735 This element indicates the SDP m-line properties like label
736 attributes, media mode. Label attribute is used to link m-line SDP
737 body using label attribute in SDP m-line. The media mode helps in
738 understanding whether the media is mixed or not.
740 Each stream element has unique Base 64 URN UUID attribute which helps
741 to uniquely identify stream and session Base 64 URN UUID to associate
742 stream with specific session element.
744 The content attribute if an SRC wishes to send is conveyed in RS SDP.
746 6.8. ParticipantStream Association
747 +-------------------+
748 | ParticipantSteam |
749 | Association |
750 +-------------------+ +----------Participant
751 | Association-Time | | 0..*| 1..*|
752 | Disassociaton-Time|---+ recv| |sends
753 | Recv | | 0..*| 0..*|
754 | Send | | | |
755 +-------------------+ | | |
756 +----------Media Stream
758 A ParticipantStream association class and its object has attributes
759 that are attributes of association of a Participant to a Stream.
761 6.8.1. Attributes
763 A participantStream association class has the following attributes:
765 o Associate-Time: This attributes indicates the time a Participant
766 started contributing to a Media Stream
767 o Disassociate-Time: This attribute indicates the time a Participant
768 stopped contributing to a Media Stream
770 6.8.2. Linkages
772 The participantStream association class is linked to participant and
773 Stream classes. There are no cardinalties for this linkage.
775 6.8.3. XML element
777 ParticipantStreamAssoc XML element represents participant to stream
778 association object. participant element is used to uniquely identify
779 this element and related with stream using stream unique URN id..
781 6.9. associate-time/disassociate-time
783 associate-time/disassociate-time contains a string indicating the
784 date and time of the status change of this tuple. The value of this
785 element MUST follow the IMPP datetime format [RFC3339]. Timestamps
786 that contain 'T' or 'Z' MUST use the capitalized forms. At a time,
787 any of the time tuple associate-time or disassociate-time MAY exist
788 in the element namely group, session, participant and not both
789 timestamp at the same time.
791 As a security measure, the timestamp element SHOULD be included in
792 all tuples unless the exact time of the status change cannot be
793 determined.
795 6.10. Unique ID format
797 Unique id is generated in two steps:
798 o UUID is created using [RFC4122])
799 o UUID is encoded using base64 as defined in [RFC4648]
801 The above mentioned unique-id mechanism SHOULD be used for each
802 metadata element.
804 7. SIP Recording Metadata Example
806 7.1. Complete SIP Recording Metadata Example
808 The following example provides all the tuples involved in Recording
809 Metadata XML body.
811
812
813 complete
814
815 2010-12-16T23:41:07Z
816
817
818 sip:pravindran@sonusnet.com
819 FaXHlc+3WruaroDaNE87am==
820
821
822 FOO!
823 bar
824
825
826
827 7+OTCyoxTmqmqyA/1weDAg==
828
829 2010-12-16T23:41:07Z
830
831 FOO!
832 bar
833
834
837
838 RamMohan R
840
841
842 FOO!
843 bar
844
845
848 2010-12-16T23:41:07Z
849
850
852 i1Pz3to5hGk8fuXl+PbwCw==
853 UAAMm5GRQKSCMVvLyl4rFw==
854 8zc6e0lYTlWIINA6GR+3ag==
855 EiXGlc+4TruqqoDaNE76ag==
856
857
860
861 Paul Kyzivat
862
863
864 FOO!
865 bar
866
867
870 2010-12-16T23:41:07Z
871
872
874 8zc6e0lYTlWIINA6GR+3ag==
875 EiXGlc+4TruqqoDaNE76ag==
876 UAAMm5GRQKSCMVvLyl4rFw==
877 i1Pz3to5hGk8fuXl+PbwCw==
878
879
881
882
883
885
886
887
889
890
891
893
894
895
897 SIP Recording Metadata Example XML body
899 7.2. Partial Update of Recording metadata XML body
901 The following example provides partial update in Recording Metadata
902 XML body for the above example. The example has a snapshot that
903 carries the disassociate-time for a participant from a session.
905
906
907 partial
908
911
912 Parathasarathi R
913
914 FOO!
915 bar
916
917
920 2010-12-16T23:41:07Z
921
922
924 Partial update of SIP Recording Example XML body
926 8. XML Schema definition for Recording metadata
928 This section defines XML schema for Recording metadata document
930
931
936
937
938
939
940
941
943
945
947
949
951
955
956
957
958
959
961
963
967
968
970
971
972
973
975
977
981
982
984
985
986
987
989
991
995
996
998
999
1000
1001
1003
1007
1008
1010
1012
1013
1014
1015
1017
1019
1023
1024
1026
1028
1029
1030
1031
1033
1035
1039
1040
1042
1043
1044
1045
1047
1049
1051
1053
1057
1058
1060
1062
1063
1064
1065
1066
1067
1068
1070
1071
1072
1073
1074
1075
1077
1078
1079
1080
1081
1082
1083
1085
1087 9. Security Considerations
1089 The metadata information sent from SRC to SRS MAY reveal sensitive
1090 information about different participants in a session. For this
1091 reason, it is RECOMMENDED that a SRC use a strong means for
1092 authentication and metadata information protection and that it apply
1093 comprehensive authorization rules when using the metadata format
1094 defined in this document. The following sections will discuss each
1095 of these aspects in more detail.
1097 9.1. Connection Security
1099 It is RECOMMENDED that a SRC authenticate SRS using the normal SIP
1100 authentication mechanisms, such as Digest as defined in Section 22 of
1101 [RFC3261]. The mechanism used for conveying the metadata information
1102 MUST ensure integrity and SHOULD ensure confidentially of the
1103 information. In order to achieve these, an end-to-end SIP encryption
1104 mechanism, such as S/MIME described in [RFC3261], SHOULD be used.
1106 If a strong end-to-end security means (such as above) is not
1107 available, it is RECOMMENDED that a SRC use mutual hop-by-hop
1108 Transport Layer Security (TLS) authentication and encryption
1109 mechanisms described in "SIPS URI Scheme" and "Interdomain Requests"
1110 of [RFC3261].
1112 10. IANA Considerations
1114 This specification registers a new XML namespace, and a new XML
1115 schema.
1117 10.1. SIP recording metadata Schema Registration
1119 URI: urn:ietf:params:xml:ns:recording
1121 Registrant Contact: IETF SIPREC working group, Ram mohan
1122 R(rmohanr@cisco.com)
1124 XML: the XML schema to be registered is contained in Section 6.
1126 Its first line is and its last
1127 line is
1129 11. Acknowledgement
1131 We wish to thank John Elwell(Siemens-Enterprise), Henry Lum(Alcatel-
1132 Lucent), Leon Portman(Nice), De Villers, Andrew Hutton(Siemens-
1133 Enterprise), Deepanshu Gautam(Huawei), Charles Eckel(Cisco), Muthu
1134 Arul(Cisco), Michael Benenson(Cisco), Hadriel Kaplan (ACME), Brian
1135 Rosen(Neustar), Scott Orton(Broadsoft) for their valuable comments
1136 and inputs.
1138 We wish to thank Joe Hildebrand(Cisco), Peter Saint-Andre(Cisco) for
1139 the valuable XML related guidance and Martin Thompson for validating
1140 the XML schema and providing comments on the same.
1142 12. Appendix A: Metadata Model Object Instances
1144 This section describes the metadata model object instances for
1145 different use cases of SIPREC. For the sake of simplicity as the
1146 media streams sent by each of the participants is received by every
1147 other participant in these use cases, it is NOT shown in the object
1148 instance diagrams below. Also for the sake of ease not all
1149 attributes of each object are shown in these instance diagrams.
1151 12.1. Use case 1: Basic Call
1153 Basic call between two Participants A and B. In this use case each
1154 participant sends one Media Stream. For the sake of simplicity
1155 "receives" lines are not shown in this instance diagram. Media
1156 Streams sent by each participant is received all other participants
1157 of that CS.
1159 +-------------------------------+
1160 | Recording Session (RS) |
1161 +-------------------------------+
1162 |
1163 |
1164 |
1165 +----------------+
1166 | Communication |
1167 | Session (CS) |
1168 +----------------+-----------------------+
1169 | Start Time | |
1170 +----------------+ |
1171 | |
1172 |-------------------+ |
1173 | | |
1174 +---------------+ +---------------+ |
1175 | ParticipantA | | ParticipantB | |
1176 | | | | |
1177 +---------------+ +---------------+ |
1178 | | |
1179 sends | | sends |
1180 | | |
1181 +---------------+ +---------------+ |
1182 |Media Stream A1| |Media Stream B1| |
1183 +---------------+ +---------------+ |
1184 |MediaStream Ref| |MediaStream Ref| |
1185 | | | | |
1186 +---------------+ +---------------+ |
1187 | | |
1188 +-----------------------------------+
1190 12.2. Use case 2: Hold/Resume
1192 Basic call between two Participants A and B and with Participant A or
1193 B doing a Hold/Resume. In this use case each participant sends one
1194 Media Stream. After Hold/Resume the properties of Media can change.
1195 For the sake of simplicity "receives" lines are not shown in this
1196 instance diagram. Media Streams sent by each participant is received
1197 all other participants of that CS.
1199 +-------------------------------+
1200 | Recording Session (RS) |
1201 +-------------------------------+
1202 | |
1203 | |
1204 | |
1205 | +-------------------------------+
1206 | | Communication Session (CS) |
1207 | +-----------| Group(CSG) |
1208 | | +-------------------------------+
1209 | | | Unique-id1 |
1210 | | +-------------------------------+
1211 | |
1212 | |
1213 | |
1214 +----------------+
1215 | Communication |
1216 +-| Session (CS) |----------------------------------------------+
1217 | +----------------+ |
1218 | | | |
1219 | +----------------+ |
1220 | | |
1221 | |-------------------+ |
1222 | | | |
1223 | +---------------+ +---------------+ |
1224 | | ParticipantA | | ParticipantB |-----------+ |
1225 | | |--+ | | | |
1226 | +---------------+ | +---------------+ |sends(After |
1227 | | | | | | | Resume) |
1228 | | | | | | +--------------+ |
1229 | sends | | +--+ | sends | |MediaStream B3| |
1230 | | -----+ | | +-----+ +--------------+ |
1231 | +---------------+ | | +---------------+ | |MediaStreamRef|-|
1232 | |Media Stream A1| | | |Media Stream B1| | | | |
1233 | +---------------+ | | +---------------+ | | | |
1234 +-|MediaStreamref | | | |MediaStreamRef | | +--------------+ |
1235 | | | | | |-|-------------------|
1236 +---------------+ | | +---------------+ | |
1237 | | | |
1238 +------------+ |sends |sends (hold) |
1239 | sends |(Resume) | |
1240 | (hold) +-------+ +-------+ |
1241 | | | |
1242 +---------------+ +---------------+ +--------------+ |
1243 |Media Stream A2| |Media Stream A3| |MediaStream B2| |
1244 +---------------+ +---------------+ | | |
1245 |MediaStreamref | |MediaStreamRef | +--------------+ |
1246 | | | | |Codec Params | |
1247 +---------------+ +---------------+ | | |
1248 | | | | |
1249 | | +--------------+ |
1250 | | | |
1251 +------------------------------------------------------+
1253 12.3. Use case 3: Basic call with Transfer
1255 Basic call between two Participants A and B and with Participant A
1256 transfer(consult transfer) to Participant C. In this use case each
1257 participant sends one Media Stream. After transfer the properties of
1258 Participant A Media can change. For the sake of simplicity
1259 "receives" lines are not shown in this instance diagram. Media
1260 Streams sent by each participant is received all other participants
1261 of that CS.
1263 +-------------------------------+
1264 | Recording Session (RS) |-------+
1265 +-------------------------------+ |
1266 | |
1267 | |
1268 | |
1269 +-------------------------------+ |
1270 | Communication Session (CS) | |
1271 | Group(CSG) | |
1272 +-------------------------------+ |
1273 | Unique-id1 | |
1274 +-------------------------------+ |
1275 | |
1276 |----------------------------+
1277 |
1278 |-----------------+
1279 | |
1280 +----------------+ +----------------+
1281 | Communication | | Communication |
1282 | Session (CS)1 | | Session (CS)2 |
1283 +----------------+ +----------------+-----------+
1284 | | | | |
1285 +----------------+ +----------------+ |
1286 | |
1287 |-------------------+ |
1288 | | | |
1289 +---------------+ | +---------------+ |
1290 | ParticipantA | | | ParticipantB | |
1291 | | | | | |
1292 +---------------+ | +---------------+ |
1293 | | | |
1294 sends | | | sends |
1295 | | | |
1296 +---------------+ | +---------------+ |
1297 |Media Stream A1| | |Media Stream B1| |
1298 +---------------+ | +---------------+ |
1299 | | | | | |
1300 | | | | Media Stream | |
1301 | Media Stream |---+---| Ref | |
1302 | Ref | | | |
1303 +---------------+ +---------------+ |
1304 |
1305 |
1306 +----------------------------|
1307 | |
1308 +--------------------------------+ |
1309 | | |
1310 +---------------+ +---------------+ |
1311 | Participant A | | Participant C | |
1312 | (same) | | | |
1313 +---------------+ +---------------+ |
1314 | | |
1315 | sends (After transfer) | sends |
1316 +----------------+ +----------------+|
1317 | Media Stream A2| | Media Stream C1||
1318 +----------------+ +----------------+|
1319 | Media StreamRef| | Media StreamRef||
1320 | | | ||
1321 | | | ||
1322 +----------------+ +----------------+|
1323 | | |
1324 | | |
1325 | | |
1326 +-------------------------------------------+
1328 12.4. Conference Use Cases
1330 Depending on who act as SRC and the information that an SRC has there
1331 can be several ways to model conference use cases. This section has
1332 instance diagrams for the following cases:
1334 o A CS where one of the participant (which is also SRC) is a user in
1335 a conference
1336 o A CS where one of the participant is focus ( which is also SRC)
1337 o A CS where one of the participant is user and the SRC is a
1338 different entity like B2BUA
1339 o A CS where one of the participant is focus and the SRC is a
1340 different entity like B2BUA
1342 NOTE: There MAY be other ways to model the same use cases depending
1343 on what information the SRC has.
1345 12.4.1. Case 1:
1347 This is the usecase where there is a CS with one of the participant
1348 (who is also SRC) as a user in a conference. For the sake of
1349 simplicity the receive lines for each of the participant is not
1350 shown.
1352 +---------------------------------------------------+
1353 | Communication Session |
1354 | +-------------+ +--------------+ |
1355 | | | | | |
1356 | |Participant B| | Participant A| |
1357 | | (User in |--------------| | |
1358 | | conf/SRC) | | | |
1359 | +-------------+ +--------------+ |
1360 | | | | | |
1361 +---------------------------------------------------+
1362 | | | |
1363 | | | |
1364 D E F G (Participants of Conference)
1366 Instance Diagram:
1368 +-------------------------------+
1369 | Recording Session (RS) |--+
1370 +-------------------------------+ |
1371 | |
1372 | |
1373 | |
1374 +-------------------------------+ |
1375 | Communication Session (CS) | |
1376 | Group(CSG) | |
1377 +-------------------------------+ |
1378 | Unique-id1 | |
1379 +-------------------------------+ |
1380 | |
1381 |-----------------------+
1382 |
1383 +----------------+
1384 | Communication |
1385 | Session (CS) |--+----------------+-----+
1386 +----------------+ | | |
1387 | | | | |
1388 +----------------+ | | |
1389 | | | |
1390 | | | |
1391 | | | |
1392 +---------------+ | | |
1393 | ParticipantA | | | |
1394 | | | | |
1395 +---------------+ | | |
1396 | | | |
1397 sends | | | |
1398 | | | |
1399 +---------------+ | | |
1400 |Media Stream A1| | | |
1401 +---------------+ | | |
1402 |MediaStream Ref|-----|----------------+ |
1403 | | | | |
1404 +---------------+ | | |
1405 | | |
1406 | | |
1407 +-------------+ | |
1408 | | |
1409 | | |
1410 +----------------+ | |
1411 | Participant B | | |
1412 | (in conf) | | |
1413 +----------------+ | |
1414 | | |
1415 sends | | |
1416 | | |
1417 +----------------+ | |
1418 | Media Stream B1|---------------------+ |
1419 +----------------+ sends |
1420 | MediaStream Ref| |
1421 | | +-----------------+
1422 +----------------+ |
1423 | |
1424 |sends |
1425 | |
1426 +-----------------+-------------+------------+
1427 | | | |
1428 | | | |
1429 +------------+ +------------+ +------------+ +-------------+
1430 |participantD| |ParticipantE| |ParticipantF| |Participant G|
1431 +------------+ +------------+ +------------+ +-------------+
1433 In this example we have two participants A and B who are part of a
1434 Communication Session(CS). One of the participants B is part of a
1435 conference and also acts as SRC.There can be two cases here. B can
1436 be a participant of the conference or B can be a focus. In this
1437 instance diagram Participant B is a user in a conference. The SRC
1438 (Participant B) subscribes to conference event package to get the
1439 details of other particiants. Participant B(SRC) sends the same
1440 through the metadata to SRS. In this instance diagram the Media
1441 Stream(mixed stream) sent from Participant B has media streams
1442 contributed by conference participants (D,E,F and G). For the sake
1443 of simplicity the "receives" line is not shown here. In this example
1444 the media stream sent by each participant(A or B) of CS is received
1445 by all other participant(A or B).
1447 12.4.2. Case 2:
1449 This is the usecase where there is a CS where one of the participant
1450 is focus ( which is also SRC).
1452 +---------------------------------------------------+
1453 | Communication Session |
1454 | +--------------+ +--------------+ |
1455 | | |--------------| | |
1456 | |Participant C | | Participant A| |
1457 | | (Focus in |------+ | | |
1458 | | conf and SRC)|---+ | +--------------+ |
1459 | +--------------+ | | |
1460 | | | +---------+ |
1461 | | | | |
1462 | +--------------+ | +---------------+ |
1463 | | Participant B| +---+ | Participant D | |
1464 | | | | | | |
1465 | +--------------+ | +---------------+ |
1466 | | |
1467 | +--------------+ |
1468 | |Participant E | |
1469 | | | |
1470 | +--------------+ |
1471 | |
1472 +---------------------------------------------------+
1474 Instance Diagram:
1476 +-------------------------------+
1477 | Recording Session (RS) |
1478 +-------------------------------+
1479 |-------------------------+
1480 | |
1481 | |
1482 +-------------------------------+ |
1483 | Communication Session (CS) | |
1484 | Group(CSG) | |
1485 +-------------------------------+ |
1486 | Unique-id1 | |
1487 +-------------------------------+ |
1488 | |
1489 |-------------------------+
1490 |
1491 +----------------+
1492 | Communication |
1493 | Session (CS) |----------------------+
1494 +----------------+ |
1495 | | |
1496 +----------------+ |
1497 | |
1498 |-------------------+ |
1499 | | | |
1500 +---------------+ | +---------------+ |
1501 | ParticipantA | | | ParticipantB | |
1502 | | | | | |
1503 +---------------+ | +---------------+ |
1504 | | | |
1505 sends | | | sends |
1506 | | | |
1507 +---------------+ | +---------------+ |
1508 |Media Stream A1| | |Media Stream B1| |
1509 +---------------+ | +---------------+ |
1510 |MediaStream Ref| | |MediaStream Ref| |
1511 | |---+---| | |
1512 +---------------+ +---------------+ |
1513 |
1514 +----------------------------------+
1515 | | | |
1516 | | | |
1517 +---------------+ | +---------------+ |
1518 | ParticipantD | | | ParticipantE | |
1519 | | | | | |
1520 +---------------+ | +---------------+ |
1521 | | | |
1522 sends | | | sends |
1523 | | | |
1524 +---------------+ | +---------------+ |
1525 |Media Stream D1| | |Media Stream E1| |
1526 +---------------+ | +---------------+ |
1527 |MediaStream Ref| | |MediaStream Ref| |
1528 | |---+---| | |
1529 +---------------+ +---------------+ |
1530 |
1531 |
1532 +----------+
1533 +-----------------|
1534 | |
1535 | |
1536 +----------------+ |
1537 | Participant C | |
1538 | (focus +src) | |
1539 +----------------+ |
1540 | |
1541 Sends | +-------+
1542 | |
1543 "sends" OR | |
1544 contributed +----------------+
1545 by | Media Stream C1|
1546 Participants+----------------+ "receives" by participants A,B,D,E
1547 A,B,D,E | MediaStream Ref|------------------------------------
1548 ------------| Codec Params |
1549 +----------------+
1551 In this example we have two participants A and B who are part of a
1552 Communication Session(CS). One of the participants (C) is focus of a
1553 conference and also acts as SRC. The SRC (Participant C) being the
1554 Focus of the conference has access to the details of other
1555 particiants. SRC (Participant C) sends the same through the metadata
1556 to SRS. In this instance diagram the Media Stream(mixed stream) sent
1557 by C has media streams contributed by conference participants (A, B,
1558 D and E). Participants A, B,D and E sends Media Streams A1, B1, D1
1559 and E1 respectively. The media stream sent by Participant C(Focus)
1560 is received by all other participants of CS. For the sake of
1561 simplicity the "receives" line is not shown linked to all other
1562 participants.
1564 NOTE: SRC ( Participant C) can send mixed stream or seperate streams
1565 to SRS
1567 12.4.3. Case 3:
1569 A CS where one of the participant is user and the SRC is a different
1570 entity like B2BUA. In this case the SRC may not know that one of the
1571 user is part of conference. Hence the instance diagram will not have
1572 information about the conference participants.
1574 +---------------------------------------------------+
1575 | Communication Session |
1576 | +-------------+ +------+ +--------------+ |
1577 | | | | (SRC)| | | |
1578 | |Participant B|--|B2BUA |----| Participant A| |
1579 | | (User in | +------+ | | |
1580 | | conf) | | | |
1581 | +-------------+ +--------------+ |
1582 | | | | | |
1583 +---------------------------------------------------+
1584 | | | |
1585 | | | |
1586 D E F G (Participants of Conference)
1588 12.4.4. Case 4:
1590 A CS where one of the participant is focus and the SRC is a different
1591 entity like B2BUA. In this case the participant which is focus sends
1592 "isfocus" in SIP message to SRC. The SRC subscribe to conference
1593 event package on seeing this "isfocus". SRC learns the details of
1594 other participants of conference from the conference package and send
1595 the same in metadata to SRS. The instance diagram for this use case
1596 is same as Case 1.
1598 +--------------------------------+
1599 | Conference Event Package |
1600 | |
1601 +--------------------------------+
1602 |
1603 | subscribes
1604 |
1605 +---------------------|-----------------------------+
1606 | Communication |Session |
1607 | +-------------+ +------+ +--------------+ |
1608 | | | | (SRC)| | | |
1609 | |Participant B|--|B2BUA |----| Participant A| |
1610 | | (FOCUS in | +------+ | | |
1611 | | conf) | | | |
1612 | +-------------+ +--------------+ |
1613 | | | | | |
1614 +---------------------------------------------------+
1615 | | | |
1616 | | | |
1617 D E F G (Participants of Conference)
1619 13. Appendix B: Metadata XML schema Instances
1621 This section describes the metadata model XML instances for different
1622 use cases of SIPREC. For the sake of simplicity the complete SIP
1623 messages are NOT shown here.
1625 13.1. Use case 1: Basic Call
1627 Basic call between two Participants A(Ram) and B(Partha) who are part
1628 of one session. In this use case each participant sends two Media
1629 Streams. Media Streams sent by each participant is received all
1630 other participants of that CS in this use-case. Below is the initial
1631 snapshot sent by SRC that has complete metadata. For the sake of
1632 completeness even snippets of SDP is shown. For the sake of
1633 simplicity these use-cases assume the RS stream is unmixed.
1635 Content-Type: application/SDP
1636 ...
1637 m=audio 49170 RTP/AVP 0
1638 a=rtpmap:0 PCMU/8000
1639 a=label:96
1640 a=sendonly
1641 ...
1642 m=video 49174 RTP/AVPF 96
1643 a=rtpmap:96 H.264/90000
1644 a=label:97
1645 a=sendonly
1646 ...
1647 m=audio 51372 RTP/AVP 0
1648 a=rtpmap:0 PCMU/8000
1649 a=label:98
1650 a=sendonly
1651 ...
1652 m=video 49176 RTP/AVPF 96
1653 a=rtpmap:96 H.264/90000
1654 a=label:99
1655 a=sendonly
1656 ....
1657
1658
1659 complete
1660
1661 2010-12-16T23:41:07Z
1662
1663
1664 sip:alice@cisco.com
1665
1666
1667 FOO!
1668 bar
1669
1670
1671
1672 7+OTCyoxTmqmqyA/1weDAg==
1673
1674 2010-12-16T23:41:07Z
1675
1676 FOO!
1677 bar
1678
1679
1682
1683 RamMohan R
1684
1685
1686 FOO!
1687 bar
1688
1689
1692 2010-12-16T23:41:07Z
1693
1694
1696 i1Pz3to5hGk8fuXl+PbwCw==
1697 UAAMm5GRQKSCMVvLyl4rFw==
1698 8zc6e0lYTlWIINA6GR+3ag==
1699 EiXGlc+4TruqqoDaNE76ag==
1700
1701
1704
1705 Parthasarathi R
1706
1707
1708 FOO!
1709 bar
1710
1711
1715 2010-12-16T23:41:07Z
1716
1717
1719 8zc6e0lYTlWIINA6GR+3ag==
1720 EiXGlc+4TruqqoDaNE76ag==
1721 UAAMm5GRQKSCMVvLyl4rFw==
1722 i1Pz3to5hGk8fuXl+PbwCw==
1723
1724
1726
1727
1728
1730
1731
1732
1734
1735
1736
1738
1739
1740
1742 13.2. Use case 2: Hold/resume
1744 Basic call between two Participants A and B. This is the continuation
1745 of above use-case. One of the participants(say A) goes on hold and
1746 then resumes as part of the same session. The metadata snapshot
1747 looks as below
1749 During hold
1750 Content-Type: application/SDP
1751 ...
1752 m=audio 49170 RTP/AVP 0
1753 a=rtpmap:0 PCMU/8000
1754 a=label:96
1755 a=inactive
1756 ...
1757 m=video 49174 RTP/AVPF 96
1758 a=rtpmap:96 H.264/90000
1759 a=label:97
1760 a=inactive
1761 ...
1762 m=audio 51372 RTP/AVP 0
1763 a=rtpmap:0 PCMU/8000
1764 a=label:98
1765 a=sendonly
1766 ...
1767 m=video 49176 RTP/AVPF 96
1768 a=rtpmap:96 H.264/90000
1769 a=label:99
1770 a=sendonly
1771 ....
1773
1774
1775 partial
1776
1779 8zc6e0lYTlWIINA6GR+3ag==
1780 EiXGlc+4TruqqoDaNE76ag==
1781
1782
1785 8zc6e0lYTlWIINA6GR+3ag==
1786 EiXGlc+4TruqqoDaNE76ag==
1787
1789
1791 During resume
1793 The snapshot will look pretty much same as Use-case 1.
1795 13.3. Use case 3: Basic Call with transfer
1797 Basic call between two Participants A and B is connected as in Use-
1798 case 1. Transfer is initiated by one of the participants of by other
1799 entity(3PCC case). SRC sends a snapshot of the participant changes
1800 to SRS. In this instance participant A(Ram) drops out during the
1801 transfer and Participant C(Paul) joins the session. There can be two
1802 cases here, same session continues after transfer or a new session
1803 (e.g. REFER based transfer) is created
1805 Transfer with same session retained - (.e.g. RE-INVITE based
1806 transfer). Participant A drops out and C is added to the same
1807 session. No change to session/group element. C will be new stream
1808 element which maps to RS SDP using the same labels in this instance.
1810 Content-Type: application/SDP
1811 ...
1812 m=audio 49170 RTP/AVP 0
1813 a=rtpmap:0 PCMU/8000
1814 a=label:96
1815 a=sendonly
1816 ...
1817 m=video 49174 RTP/AVPF 96
1818 a=rtpmap:96 H.264/90000
1819 a=label:97
1820 a=sendonly
1821 ...
1822 m=audio 51372 RTP/AVP 0
1823 a=rtpmap:0 PCMU/8000
1824 a=label:98
1825 a=sendonly
1826 ...
1827 m=video 49176 RTP/AVPF 96
1828 a=rtpmap:96 H.264/90000
1829 a=label:99
1830 a=sendonly
1831 ....
1832
1833
1834 partial
1835
1837 8zc6e0lYTlWIINA6GR+3ag==
1838 EiXGlc+4TruqqoDaNE76ag==
1839 60JAJm9UTvik0Ltlih/Gzw==
1840 AcR5FUd3Edi8cACQJy/3JQ==
1841
1842
1845
1846 Paul Kyzivat
1847
1848 60JAJm9UTvik0Ltlih/Gzw==
1849 AcR5FUd3Edi8cACQJy/3JQ==
1850 8zc6e0lYTlWIINA6GR+3ag==
1851 EiXGlc+4TruqqoDaNE76ag==
1852 2010-12-16T23:41:07Z
1853
1854 FOO!
1855 bar
1856
1857
1860 2010-12-16T23:41:07Z
1861
1862
1864 60JAJm9UTvik0Ltlih/Gzw==
1865 AcR5FUd3Edi8cACQJy/3JQ==
1866 8zc6e0lYTlWIINA6GR+3ag==
1867 EiXGlc+4TruqqoDaNE76ag==
1868
1869
1871
1872
1873
1875
1876
1877
1879
1880
1881
1883
1884
1885
1887 Transfer with new session - (.e.g. REFER based transfer). In this
1888 case new session is part of same grouping (done by SRC).
1890 SRC may send an optional snapshot indicating stop for the old
1891 session.
1893
1894
1895 Partial
1896
1897 7+OTCyoxTmqmqyA/1weDAg==
1898
1899 2010-12-16T23:41:07Z
1900
1901 FOO!
1902 bar
1903
1904
1907 2010-12-16T23:41:07Z
1908
1909
1912 2010-12-16T23:41:07Z
1913
1914
1916 SRC sends a snapshot to indicate the participant change and new
1917 session information after transfer. In this example the same RS is
1918 used.
1920 Content-Type: application/SDP
1921 ...
1922 m=audio 49170 RTP/AVP 0
1923 a=rtpmap:0 PCMU/8000
1924 a=label:96
1925 a=sendonly
1926 ...
1927 m=video 49174 RTP/AVPF 96
1928 a=rtpmap:96 H.264/90000
1929 a=label:97
1930 a=sendonly
1931 ...
1932 m=audio 51372 RTP/AVP 0
1933 a=rtpmap:0 PCMU/8000
1934 a=label:98
1935 a=sendonly
1936 ...
1937 m=video 49176 RTP/AVPF 96
1938 a=rtpmap:96 H.264/90000
1939 a=label:99
1940 a=sendonly
1941 ....
1942
1943
1944 partial
1945
1946 7+OTCyoxTmqmqyA/1weDAg==
1947
1948 2010-12-16T23:41:07Z
1949
1950 FOO!
1951 bar
1952
1953
1956
1957
1958 FOO!
1959 bar
1960
1961
1964 2010-12-16T23:32:03Z
1965
1966
1968 8zc6e0lYTlWIINA6GR+3ag==
1969 EiXGlc+4TruqqoDaNE76ag==
1970 60JAJm9UTvik0Ltlih/Gzw==
1971 AcR5FUd3Edi8cACQJy/3JQ==
1972
1973
1976
1977
1978 FOO!
1979 bar
1980
1981
1984 2010-12-16T23:41:07Z
1985
1986
1988 60JAJm9UTvik0Ltlih/Gzw==
1989 AcR5FUd3Edi8cACQJy/3JQ==
1990 8zc6e0lYTlWIINA6GR+3ag==
1991 EiXGlc+4TruqqoDaNE76ag==
1992
1993
1995
1996
1997
1999
2000
2001
2003
2004
2005
2007
2008
2009
2011 13.4. Use Case 4: Call disconnect
2013 This example shows a snapshot of metadata sent by an SRC at CS
2014 disconnect where the participants of CS are Ram and Partha
2015
2016
2017 Partial
2018
2019 7+OTCyoxTmqmqyA/1weDAg==
2020
2021 2010-12-16T23:41:07Z
2022
2023 FOO!
2024 bar
2025
2026
2029
2030 2010-12-16T23:41:07Z
2031
2033
2036
2037 2010-12-16T23:41:07Z
2038
2039
2041 14. References
2043 14.1. Normative References
2045 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2046 Requirement Levels", BCP 14, RFC 2119, March 1997.
2048 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
2050 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
2051 A., Peterson, J., Sparks, R., Handley, M., and E.
2052 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
2053 June 2002.
2055 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
2056 January 2004.
2058 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
2059 Internet: Timestamps", RFC 3339, July 2002.
2061 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
2062 Description Protocol", RFC 4566, July 2006.
2064 [RFC4574] Levin, O. and G. Camarillo, "The Session Description
2065 Protocol (SDP) Label Attribute", RFC 4574, August 2006.
2067 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description
2068 Protocol (SDP) Content Attribute", RFC 4796,
2069 February 2007.
2071 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
2072 "Indicating User Agent Capabilities in the Session
2073 Initiation Protocol (SIP)", RFC 3840, August 2004.
2075 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
2076 Unique IDentifier (UUID) URN Namespace", RFC 4122,
2077 July 2005.
2079 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
2080 Encodings", RFC 4648, October 2006.
2082 14.2. Informative References
2084 [RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use
2085 Cases and Requirements for SIP-Based Media Recording
2086 (SIPREC)", RFC 6341, August 2011.
2088 [I-D.ietf-siprec-architecture]
2089 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An
2090 Architecture for Media Recording using the Session
2091 Initiation Protocol", draft-ietf-siprec-architecture-04
2092 (work in progress), March 2012.
2094 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
2095 August 1999.
2097 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
2098 Header Field for the Session Initiation Protocol (SIP)",
2099 RFC 3326, December 2002.
2101 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
2102 Extensions to the Session Initiation Protocol (SIP) for
2103 Asserted Identity within Trusted Networks", RFC 3325,
2104 November 2002.
2106 Authors' Addresses
2108 Ram Mohan Ravindranath
2109 Cisco Systems, Inc.
2110 Cessna Business Park,
2111 Kadabeesanahalli Village, Varthur Hobli,
2112 Sarjapur-Marathahalli Outer Ring Road
2113 Bangalore, Karnataka 560103
2114 India
2116 Email: rmohanr@cisco.com
2118 Parthasarathi Ravindran
2119 Sonus Networks
2120 Prestige Shantiniketan - Business Precinct
2121 Whitefield Road
2122 Bangalore, Karnataka 560066
2123 India
2125 Email: pravindran@sonusnet.com
2127 Paul Kyzivat
2128 Unaffiliated
2129 Boxborough, MA
2130 USA
2132 Email: pkyzivat@alum.mit.edu