idnits 2.17.1
draft-ietf-siprec-metadata-04.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 (September 1, 2011) is 4619 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-02
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: March 4, 2012 Sonus Networks
5 Paul. Kyzivat
6 Unaffiliated
7 September 1, 2011
9 Session Initiation Protocol (SIP) Recording Metadata
10 draft-ietf-siprec-metadata-04
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 March 4, 2012.
40 Copyright Notice
42 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . 7
62 5.1. XML data format . . . . . . . . . . . . . . . . . . . . . 7
63 5.1.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 8
64 5.1.2. recording . . . . . . . . . . . . . . . . . . . . . . 8
65 6. Recording Metadata classes . . . . . . . . . . . . . . . . . . 8
66 6.1. Recording Session . . . . . . . . . . . . . . . . . . . . 8
67 6.1.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 9
68 6.1.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 9
69 6.1.3. XML element . . . . . . . . . . . . . . . . . . . . . 9
70 6.2. Communication Session Group . . . . . . . . . . . . . . . 10
71 6.2.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 10
72 6.2.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 10
73 6.2.3. XML element . . . . . . . . . . . . . . . . . . . . . 11
74 6.3. Communication Session . . . . . . . . . . . . . . . . . . 11
75 6.3.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 12
76 6.3.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 12
77 6.3.3. XML element . . . . . . . . . . . . . . . . . . . . . 13
78 6.4. Participant . . . . . . . . . . . . . . . . . . . . . . . 13
79 6.4.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 14
80 6.4.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 14
81 6.4.3. XML element . . . . . . . . . . . . . . . . . . . . . 15
82 6.5. Media Stream . . . . . . . . . . . . . . . . . . . . . . . 15
83 6.5.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 16
84 6.5.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 17
85 6.5.3. XML element . . . . . . . . . . . . . . . . . . . . . 17
86 6.6. Extension Data . . . . . . . . . . . . . . . . . . . . . . 17
87 6.6.1. Linkages . . . . . . . . . . . . . . . . . . . . . . . 17
88 6.6.2. XML element . . . . . . . . . . . . . . . . . . . . . 17
89 6.7. associate-time/disassociate-time . . . . . . . . . . . . . 18
90 6.8. Unique ID format . . . . . . . . . . . . . . . . . . . . . 18
91 7. SIP Recording Metadata Example . . . . . . . . . . . . . . . . 18
92 7.1. Complete SIP Recording Metadata Example . . . . . . . . . 18
93 7.2. Partial Update of Recording metadata XML body . . . . . . 20
94 8. XML Schema definition for Recording metadata . . . . . . . . . 20
95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
96 9.1. Connection Security . . . . . . . . . . . . . . . . . . . 23
97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
98 10.1. SIP recording metadata Schema Registration . . . . . . . . 24
99 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24
100 12. Appendix A: Metadata Model Object Instances . . . . . . . . . 24
101 12.1. Use case 1: Basic Call . . . . . . . . . . . . . . . . . . 24
102 12.2. Use case 2: Hold/Resume . . . . . . . . . . . . . . . . . 25
103 12.3. Use case 3: Basic call with Transfer . . . . . . . . . . . 27
104 12.4. Conference Use Cases . . . . . . . . . . . . . . . . . . . 28
105 12.4.1. Case 1: . . . . . . . . . . . . . . . . . . . . . . . 29
106 12.4.2. Case 2: . . . . . . . . . . . . . . . . . . . . . . . 31
107 12.4.3. Case 3: . . . . . . . . . . . . . . . . . . . . . . . 33
108 12.4.4. Case 4: . . . . . . . . . . . . . . . . . . . . . . . 34
109 13. Appendix B: Metadata XML schema Instances . . . . . . . . . . 35
110 13.1. Use case 1: Basic Call . . . . . . . . . . . . . . . . . . 35
111 13.2. Use case 2: Hold/resume . . . . . . . . . . . . . . . . . 37
112 13.3. Use case 3: Basic Call with transfer . . . . . . . . . . . 39
113 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
114 14.1. Normative References . . . . . . . . . . . . . . . . . . . 43
115 14.2. Informative References . . . . . . . . . . . . . . . . . . 44
116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
118 1. Introduction
120 Session recording is a critical requirement in many communications
121 environments such as call centers and financial trading. In some of
122 these environments, all calls must be recorded for regulatory,
123 compliance, and consumer protection reasons. Recording of a session
124 is typically performed by sending a copy of a media stream to a
125 recording device. This document focuses on the Recording metadata
126 which describes the communication session. The document describes a
127 metadata model as viewed by Session Recording Server and the
128 Recording metadata format, the requirements for which are described
129 in [RFC6341] and the architecture for which is described in
130 [I-D.ietf-siprec-architecture].
132 2. Terminology
134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
136 document are to be interpreted as described in [RFC2119]. This
137 document only uses these key words when referencing normative
138 statements in existing RFCs."
140 3. Definitions
142 Metadata Model: The Metadata model is a class diagram in Unified
143 Modelling Language(UML). The model is a structure diagram that
144 describes the structure of a recording's Metadata by showing the
145 classes, their attributes, and the relationships among the classes.
146 Each block in the model above represents a class. The linkages
147 between the classes represents the relationships between the classes.
148 Object diagrams represents instance diagrams of the class diagram and
149 conveys snapshot of metadata.
151 Metadata classes: Each block in the model represents a class. In the
152 metadata model each class is represented as a block having the block
153 name. The description of each class also has representation of its
154 attributes in a second compartment below the class name. Each
155 instance of a class(namely the object) contributes some information
156 to the recording's Metadata.
158 Attributes: Attributes represents the attributes listed in each of
159 the classes. The attributes of a class are listed in the second
160 compartment below the class name. Each instance of class conveys
161 values for these attributes which adds to the recording's Metadata.
163 Linkages: Linkages represents the relationship between the classes in
164 the model. It represents the logical connections betweens classes(or
165 objects) in class diagrams/ object diagrams. The linkages can be
166 associations or composition in the Metadata model of this document.
167 An association represents a family of links. Binary associations
168 (with two ends) are normally represented as a line, with each end
169 connected to a class/object box. An association can be named, and
170 the ends of an association can be adorned with role names, ownership
171 indicators, multiplicity, visibility, and other properties. For
172 instance, in the metadata model we have "sends" association between
173 participant and media stream classes.The relation composition
174 represents owns/holds relationship to show classes contained in
175 another class. For instance, extension data class is contained in
176 one of the other class(like stream or participant or any of the other
177 in the model).The UML graphical representation of a composition
178 relationship is a filled diamond shape on the containing class end of
179 the tree of lines that connect contained class(es) to the containing
180 class.
182 XML element: An XML element represent one XML schema complexType
183 element (xs:complexType) of XML schema
185 XML attributes: An XML attribute represent one XML schema element
186 (xs:element) of XML schema
188 4. Metadata Model
190 Metadata is the information that describes recorded media and the CS
191 to which they relate. Below diagram shows a model for Metadata as
192 viewed by Session Recording Server (SRS).
194 +-------------------------------+ 1
195 | Recording Session (RS) |---------------+
196 +-------------------------------+ |
197 |1..* | 1..* |
198 | | |
199 | | 0..* |
200 | +-----------------+ |
201 | | Communication | |
202 | | Session (CS) | 1 |
203 | | Group |--------------|
204 | +-----------------+ |
205 | | 0..1 |
206 | | |
207 |0..* | 1..* |
208 +-------------------------------+ |
209 | Communication Session (CS) | 1 |
210 | |---------------|
211 +-------------------------------+ | +------------+
212 | 1..* |1..* | | |
213 | | | 0..* |Extension |
214 | 2..* |0..* |/\_____| Data |
215 +-------------+ receives +----------------+ |\/ | |
216 | Participant |----------| Media Streams | | +------------+
217 | |0..* 0..*| | |
218 | | | | |
219 | | | | |
220 | | sends | | |
221 | |----------| | |
222 | |1.* 0..*| | |
223 +-------------+ +----------------+ |
224 | | |
225 |1 |1 |
226 | | |
227 +----------------------------------------+
229 The Metadata model is a class diagram in Unified Modelling
230 Language(UML). The model is a structure diagram that describes the
231 structure of a recording's Metadata by showing the classes, their
232 attributes, and the relationships among the classes. Each block in
233 the model above represents a class. The linkages between the classes
234 represents the relationships which can be associations or
235 Composition. Session Recording Client (SRC) MAY initiate the
236 Recording Session. Here, Recording Session is a completely
237 independent from the Communication Session that is being recorded at
238 both the SIP dialog level and at the session level. The metadata
239 MUST be conveyed from SRC to SRS.
241 The model allows the capture of a snapshot of a recording's Metadata
242 at a given instant in time. Metadata changes to reflect changes in
243 what is being recorded. For example, if the call is transferred from
244 one participant to another, then the SRC conveys the changes in the
245 model ( In this instance change of participant and the properties of
246 the new media stream) to the SRS.
248 Some of the metadata is not required to be conveyed explicitly from
249 the SRC to the SRS, if it can be obtained contextually by the SRS.
250 For instance, the timing of RS object changes(like Start / Stop time)
251 may not be explicitly conveyed from the SRC to the SRS (The Date
252 header in RS dialog SIP message provides the timing, but it is
253 optional). In such cases the time a change occurred may be assumed
254 to be the same as the time when notification of the change is
255 received by the SRS. This is not true in cases where SRS requests a
256 snapshot of metadata from SRC.
258 5. Recording Metadata Format
260 This section gives an overview of Recording Metadata Format. Some
261 data from the metadata model is assumed to be made available to the
262 SRS through Session Description Protocol (SDP)[RFC4566], and
263 therefore this data is not represented in the XML document format
264 specified in this document. SDP attributes describes about different
265 media formats like audio, video. The other metadata attributes like
266 participant details are represented in a new Recording specific XML
267 document namely application/rs-metadata+xml. The SDP label attribute
268 [RFC4574] provides an identifier by which a metadata XML document can
269 refer to a specific media description in the SDP sent from the SRC to
270 the SRS.
272 The XML document format can be used to represent either the complete
273 metadata or a partial update to the metadata. The latter includes
274 only elements that have changed compared to the previously reported
275 metadata.
277 5.1. XML data format
279 Recording Metadata document is an XML document. recording element
280 MUST present in all recording metadata XML document. recording acts
281 as container for all other elements in this XML document.
283 Recording object is a XML document. It MUST have the XML declaration
284 and it SHOULD contain an encoding declaration in the XML declaration,
285 e.g., "". If the charset
286 parameter of the MIME content type declaration is present and it is
287 different from the encoding declaration, the charset parameter takes
288 precedence.
290 Every application conforming to this specification MUST accept the
291 UTF-8 character encoding to ensure the minimal interoperability.
293 Syntax and semantics error in recording XML document has to be
294 informed to the originator using application specific mechanism.
296 5.1.1. Namespace
298 The namespace URI for elements defined by this specification is a
299 Uniform Resource Namespace (URN) [RFC2141], using the namespace
300 identifier 'ietf' defined by [RFC2648] and extended by [RFC3688].
302 The URN is as follows: urn:ietf:params:xml:ns:recording
304 5.1.2. recording
306 recording element MUST contain an xmlns namespace attribute with
307 value as urn:ietf:params:xml:ns:recording. One recording element
308 MUST present in the all recording metadata XML document.
310 dataMode element shows whether the XML document is complete document
311 or partial update. The default value is complete.
313 6. Recording Metadata classes
315 This section describes each class of the metadata model, and the
316 attributes of each class. This section also describes how different
317 classes are linked and the XML element for each of them.
319 6.1. Recording Session
320 +-------------------------------+
321 | Recording Session (RS) |
322 +-------------------------------+
323 | | +-----------------+
324 | Start/End Time | 1 0..* | |
325 | |/\__________|Extension Data |
326 | |\/ | |
327 | | +-----------------+
328 +-------------------------------+
329 |1..* | 1..*
330 | |
331 |0..* | 0..*
332 Communication Communication
333 Session Session Group(CS Group)
335 Each instance of a Recording Session class (namely the Recording
336 Session Object) represents a SIP session created between an SRC and
337 SRS for the purpose of recording a Communication Session.
339 6.1.1. Attributes
341 A Recording Session class has the following attributes:
342 o Start/End Time - Represents the Start/End time of a Recording
343 Session object.
345 6.1.2. Linkages
347 Each instance of Recording Session has:
349 o Zero or more instances of Communication Session Group. CSG may be
350 zero because it is optional metadata object. Also the allowance
351 of zero instances is to accommodate persistent recording, where
352 there may be none.
353 o Zero or more instances of Communication Session objects.
355 6.1.3. XML element
357 Recording Session object is represented by recording XML element.
358 That in turn relies on the SIP/SDP session with which the XML
359 document is associated to provide some of the attributes of the
360 Recording Session element.
362 Start and End time value are derivable from Date header(if present in
363 SIP message) in RS. In cases where Date header is not present,
364 Start/End time are derivable from the time at which SRS receives the
365 notification of SIP message to setup RS / disconnect RS.
367 6.2. Communication Session Group
369 Recording Session (RS)
370 | 1..*
371 |
372 | 0..*
373 +-------------------------------+
374 | Communication Session |
375 | Group |
376 +-------------------------------+
377 | Unique-ID | +----------------+
378 | associate-time | 1 0..* | |
379 | disassociate-time |/\_________|Extension Data |
380 | |\/ | |
381 +-------------------------------+ +----------------+
382 | 0..1
383 |
384 | 1..*
385 Communication Session (CS)
387 One instance of a Communication Session Group class (namely the
388 Communication Session Group object) provides association or linking
389 of Communication Sessions.
391 6.2.1. Attributes
393 A CS Group has the following attributes:
394 o Unique-ID - This Unique-ID is to group different CSs that are
395 related. SRC (or SRS) is responsible for ensuring the uniqueness
396 of Unique-ID in case multiple SRC interacts with the same SRS.
397 The mechanism by which SRC groups the CS is outside the scope of
398 SIPREC.
399 o Associate-time - Associate-time for CS-Group shall be calculated
400 by SRC as the time when a grouping is formed. The rules that
401 determine how a grouping of different Communication Session
402 objects is done by SRC is outside the scope of SIPREC.
403 o Disassociate-time - Disassociate-time for CS-Group shall be
404 calculated by SRC as the time when the grouping ends
406 6.2.2. Linkages
408 The linkages between Communication Session Group class and other
409 classes is association. A communication Session Group is associated
410 with RS and CS in the following manner:
412 o There is one or more Recording Session objects per Communication
413 Session Group.
414 o Each Communication Session Group object has to be associated with
415 one or more RS [Here each RS can be setup by the potentially
416 different SRCs]
417 o There is one or more Communication Sessions per CS Group [e.g.
418 Consult Transfer]
420 6.2.3. XML element
422 Group element is an optional element provides the information about
423 the communication session group
425 Each communication session group (CSG)object is represented using one
426 group element. Each group element has unique URN UUID attribute
427 which helps to uniquely identify CSG.
429 6.3. Communication Session
431 Recording Communication
432 Session Session Group(CS Group)
433 |1..* | 0..1
434 | |
435 |0..* | 1..*
436 +-------------------------------+ +-----------------+
437 | Communication Session (CS) | 1 0..* | |
438 | |/\_____________|Extension Data |
439 +-------------------------------+\/ | |
440 | CS Identifier | +-----------------+
441 | Termination Reason |
442 | Start Time |
443 | End Time |
444 +-------------------------------+
445 | |
446 | 1..* |1..*
447 | |
448 | 2..* |0..*
449 Participant Media Stream
451 A Communication Session class and its object in the metadata model
452 represents Communication Session and its properties needed as seen by
453 SRC.
455 6.3.1. Attributes
457 A communication Session class has the following attributes:
459 o Termination Reason - This represents the reason why a CS was
460 terminated. The communication session MAY contain a Call
461 Termination Reason. This MAY be derived from SIP Reason header of
462 CS.
463 o CS Identifier - This attribute is used to uniquely identify a CS.
464 o Start Time - This optional attribute represents CS start time
465 o End Time - This optional attribute represents CS end time
467 This document does not specify attributes relating to what should
468 happen to a recording of a CS after it has been delivered to the SRS,
469 e.g., how long to retain the recording, what access controls to
470 apply. The SRS is assumed to behave in accordance with policy. The
471 ability for the SRC to influence this policy is outside the scope of
472 this document. However if there are implementations where SRC has
473 enough information, this could be sent as Extension Data attached to
474 CS
476 6.3.2. Linkages
478 A Communication Session is linked to CS-Group, Participant, Media
479 Stream and Recording Session classes using the association
480 relationship. Association between CS and Participant allows:
482 o CS to have atleast two or more participants
483 o Participant is associated with one or more CS's. This includes
484 participants who are not directly part of any CS. An example of
485 such a case is participants in a premixed media stream. The SRC
486 may have knowledge of such Participants, yet not have any
487 signaling relationship with them. This might arise if one
488 participant in CS is a conf focus. To summarize even if SRC does
489 not have direct signalling relationships with all participants in
490 a CS, it should nevertheless create a Participant object for each
491 participant that it knows about
492 o The model also allows participants in CS that are not participants
493 in the media. An example is the identity of a 3pcc controller
494 that has initiated a CS to two or more participants of the CS.
495 Another example is the identity of a conference focus. Of course
496 a focus is probably in the media, but since it may only be there
497 as a mixer, it may not report itself as a participant in any of
498 the media streams.
500 Association between CS and Media Stream allows:
502 o A CS to have zero or more Streams
503 o A stream can be associated with 1 or more CS. An example is
504 multicast MoH stream which might be associated with many CSs.
506 Association between CS and RS allows:
508 o Each instance of RS has Zero or more instances of Communication
509 Session objects.
510 o Each CS has to be associated with one more RS [ Here each RS can
511 be potentially setup by different SRCs]
513 6.3.3. XML element
515 Session element provides the information about the communication
516 session
518 Each communication session(CS) object is represented by one session
519 element. Each session element has unique URN UUID attribute which
520 helps to uniquely identify CS.
522 Reason element MAY be included to represent the Termination Reason
523 attribute. group-ref element MAY exist to indicate the group where
524 the mentioned session belongs.
526 6.4. Participant
528 Communication Session (CS)
529 | 1..*
530 |
531 | 2..*
532 +-------------------------------+
533 | Participant |
534 | |
535 +-------------------------------+
536 | AoR list | +-----------------+
537 | Name | 1 0..* | |
538 | Associate time |/\__________|Extension Data |
539 | Disassociate time |\/ | |
540 | Capabilities | | |
541 +-------------------------------+ +-----------------+
542 | 0..* 1..*|
543 receives| |sends
544 | 0..* 0..*|
545 Media Stream
547 A Participant class and its objects has information about a device
548 that is part of a CS and/or contributes/consumes media stream(s)
549 belonging to a CS.
551 6.4.1. Attributes
553 Participant has attributes like:
555 o AoR list - Has list of AoRs. An AoR MAY be SIP/SIPS/TEL URI.
556 There are cases where a participant can have more than one AoR [
557 e.g. P-Asserted-ID which can have both SIP and TEL URIs]
558 o Name - This attribute represents Participant name(SIP display
559 name) or DN number ( in case it is known)
560 o Associate-time - associate-time is calculated by SRC as the time
561 it sees a participant is associated to CS
562 o Disassociate-time- Disassociate-time is calculated by SRC as the
563 time it see a participant disassociate from a CS. It is possible
564 that a given participant can have multiple associate/disassociate
565 times within given communication session.
566 o Capabilities - A participant capabilities as defined in RFC 3840
567 [RFC3840] is an optional attribute that includes the capabilities
568 of a participant in a CS. This attribute is an attribute of
569 association of participant to CS. Each participant shall have
570 Zero or more capabilities. A participant may use different
571 capabilities depending on the role it plays at a particular
572 instance. IOW if a participants moves across different CSs ( due
573 to transfer e.t.c) OR is simultaneously present in different CSs
574 its role may be different and hence the capability used.
576 NOTE: How to represent capabilities attribute in XML is an open item.
578 This document does not specify other attributes relating to
579 participant e.g. Participant Role, Participant type. An SRC which
580 has information of these attributes can indicate the same as part of
581 extension data to Participant from SRC to SRS.
583 6.4.2. Linkages
585 The participant class is linked to MS and CS class using association
586 relationship. The association between participant and Media Stream
587 allows:
589 o Participant to receives zero or more media streams
590 o Participant to send zero or more media streams. (Same participant
591 provides multiple streams e.g. audio and video)
592 o Media stream to be received by zero or more participants. Its
593 possible, though perhaps unlikely, that a stream is generated but
594 sent only to the SRC and SRS, not to any participant. E.g. In
595 conferencing where all participants are on hold and the SRC is
596 collocated with the focus. Also a media stream may be received by
597 multiple participants (e.g. Whisper calls, side conversations).
598 o Media stream to be sent by one or more participants (pre-mixed
599 streams).
601 Example of a case where a participant receives Zero or more streams -
602 a Supervisor may have side conversation with Agent, while Agent
603 converses with customer.
605 6.4.3. XML element
607 A participant element represents a Participant object.
609 There MUST be atleast 2 participant for any given session. "send" or
610 "recv" element in each participant is associating SDP m-lines with
611 the participant. send element indicates that participant is sending
612 the stream of media with the mentioned media description. recv
613 element indicates that participant is receiving the stream and by
614 default all participant will receive the stream. recv element has
615 relevance in case whisper call scenario wherein few of the
616 participant in the session receives the stream and not others.
618 Participant MUST have AOR element which contains SIP/SIPS URI to
619 identify the participant. AOR element is SIP/SIPS URI FQDN or IP
620 address which represents the user. name is an optional element to
621 represent display name.
623 Each participant element has unique URN UUID attribute which helps to
624 uniquely identify participant and session URN UUID to associate
625 participant with specific session element. URN UUID of participant
626 *MUST* used in the scope of CSG and no new URN UUID has to be created
627 for the same element (participant, stream) between different CS in
628 the same CSG. In case URN UUID has to be used permanent, careful
629 usage of URN UUID to original AoR has to be decided by the
630 implementers and it is implementer's choice.
632 6.5. Media Stream
633 Participant
634 | 0..* 1..*|
635 receives| |sends
636 | 0..* 0..*|
637 +-------------------------+
638 | Media Stream |
639 | |
640 Communication 1..* 0..* +-------------------------+
641 Session ------------| | +----------+
642 | Media Stream Reference |1 0..* | |
643 | Content-type |/\______|Extension |
644 | CSRC |\/ | Data |
645 +-------------------------+ +----------+
647 A Media Stream class (and its objects) has the properties of media as
648 seen by SRC and sent to SRS. Different snapshots of media stream
649 object may be sent whenever there is a change in media (e.g. dir
650 change like pause/resume and/or codec change and/or participant
651 change.).
653 6.5.1. Attributes
655 A Media Stream class has the the following attributes:
657 o Media Stream Reference - In implementations this can reference to
658 m-line
659 o Content - The content of an MS element will be described in terms
660 of value from the RFC 4796 [RFC4796] registry.
661 o CSRC - The linkage between the participants to its contributing
662 media stream in a mixed RS stream is provided by CSRC attribute.
663 Not all SRC may have the capability to determine this and hence
664 this is a optional attribute. Having this info can allow the SRS
665 to determine which participants are part(contributors) of
666 particular parts of the mixed stream.
668 NOTE: How CSRC can be represented in XML is still an open item. CSRC
669 attribute is an attribute of media stream to participant association.
670 Another open items if there is a need for multiple CSRCs. A
671 participant may have multiple CSRCs - potentially a different one for
672 each stream in which it participates.
674 The metadata model should include media streams that are not being
675 delivered to the SRS. Examples include cases where SRC offered
676 certain media types but SRS chooses to accept only a subset of them
677 OR an SRC may not even offer a certain media type due it its
678 restrictions to record
680 6.5.2. Linkages
682 A Media Stream is linked to participant and CS classes using the
683 association relationship. The details of association with the
684 Participant are described in the Participant class section. The
685 details of association with CS is mentioned in the CS section.
687 6.5.3. XML element
689 stream element represents a Media Stream object. Stream element
690 indicates SDP media lines associated with the session and
691 participants.
693 This element indicates the SDP m-line properties like label
694 attributes, media mode. Label attribute is used to link m-line SDP
695 body using label attribute in SDP m-line. The media mode helps in
696 understanding whether the media is mixed or not.
698 Each stream element has unique URN UUID attribute which helps to
699 uniquely identify stream and session URN UUID to associate stream
700 with specific session element.
702 The content attribute if an SRC wishes to send is conveyed in RS SDP.
704 6.6. Extension Data
706 A recording metadata object contains additional data not specified as
707 part of siprec. This is intended to accommodate future standards
708 track extensions, as well as vendor and user specific extensions.
709 The mechanism MUST provide a means of unambiguously distinguishing
710 such extension data.
712 6.6.1. Linkages
714 Extension data class is linked to other classes using the composition
715 relationship. An extension data class ( and its objects) is
716 contained/owned by another Metadata class. Each instance of Metadata
717 class(except extension data class itself) has
719 o Zero or more instances of Extension data class
720 o Each Extension data class is contained/owned by a Metadata class
721 other than itself
723 6.6.2. XML element
725 Extensiondata element provides the mechanism by which namespace/
726 element MAY be extended with standard or proprietary information.
728 extensiondata element MUST include any other XML namespace. Multiple
729 namespace MAY exists under extensiondata. extensiondata element exist
730 in each level like recording, session, participant, stream to provide
731 extensiondata specific to each element. extensiondata element MUST be
732 part of parent element for which the additional information is sent
733 and hence no Unique ID is needed.
735 6.7. associate-time/disassociate-time
737 associate-time/disassociate-time contains a string indicating the
738 date and time of the status change of this tuple. The value of this
739 element MUST follow the IMPP datetime format [RFC3339]. Timestamps
740 that contain 'T' or 'Z' MUST use the capitalized forms. At a time,
741 any of the time tuple associate-time or disassociate-time MAY exist
742 in the element namely group, session, participant and not both
743 timestamp at the same time.
745 As a security measure, the timestamp element SHOULD be included in
746 all tuples unless the exact time of the status change cannot be
747 determined.
749 6.8. Unique ID format
751 UUID encoded more densely than the UUID URN (e.g. radix64 of the
752 binary uuid form defined in RFC 4122 [RFC4122]) SHOULD be used as a
753 format for Unique ID. How to represent this id in XML is still an
754 open item.
756 7. SIP Recording Metadata Example
758 7.1. Complete SIP Recording Metadata Example
760 The following example provides all the tuples involved in Recording
761 Metadata XML body.
763
764
765 complete
766
767 2010-12-16T23:41:07Z
768
769
770
771 sip:alice@cisco.com
772
773
774 FOO!
775 bar
776
777
778
779
780 urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302
781
782 2010-12-16T23:41:07Z
783
784 FOO!
785 bar
786
787
788
791 sip:partha@blr.cisco.com
792 urn:uuid:8b53f3de-da39-4846-93c7-ee5e5f8f6f0b
793 urn:uuid:50000c9b-9191-40a4-8231-5bcbca5e2b17
794 urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a
795 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a
796 2010-12-16T23:41:07Z
797
798 FOO!
799 bar
800
801
803
806 sip:paul@box.cisco.com
807 urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a
808 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a
809 urn:uuid:50000c9b-9191-40a4-8231-5bcbca5e2b17
810 urn:uuid:8b53f3de-da39-4846-93c7-ee5e5f8f6f0b
811 2010-12-16T23:41:07Z
812
813 FOO!
814 bar
815
816
817
819 1
820
821
822
824
825
826
828
829
830
832
833
834
836 SIP Recording Metadata Example XML body
838 7.2. Partial Update of Recording metadata XML body
840 The following example provides partial update in Recording Metadata
841 XML body for the above example. The example illustrate the
842 disassociate-time for a participant from a session.
844
845
846 partial
847
850 sip:partha@blr.cisco.com
851 2010-12-16T23:41:07Z
852
853 FOO!
854 bar
855
856
857
859 Partial update of SIP Recording Example XML body
861 8. XML Schema definition for Recording metadata
863 This section defines XML schema for Recording metadata document
865
866
871
872
873
874
875
876
878
880
882
884
886
888
889
890
891
892
894
896
898
899
901
902
903
904
906
908
910
912
915
916
918
919
920
921
923
925
927
929
931
933
935
936
938
940
941
942
943
945
947
949
950
952
954
955
956
957
961
962
964
966
967
968
969
971
972
973
974
977
978
979
980
981
982
983
984
985
987 9. Security Considerations
989 The metadata information sent from SRC to SRS MAY reveal sensitive
990 information about different participants in a session. For this
991 reason, it is RECOMMENDED that a SRC use a strong means for
992 authentication and metadata information protection and that it apply
993 comprehensive authorization rules when using the metadata format
994 defined in this document. The following sections will discuss each
995 of these aspects in more detail.
997 9.1. Connection Security
999 It is RECOMMENDED that a SRC authenticate SRS using the normal SIP
1000 authentication mechanisms, such as Digest as defined in Section 22 of
1001 [RFC3261]. The mechanism used for conveying the metadata information
1002 MUST ensure integrity and SHOULD ensure confidentially of the
1003 information. In order to achieve these, an end-to-end SIP encryption
1004 mechanism, such as S/MIME described in [RFC3261], SHOULD be used.
1006 If a strong end-to-end security means (such as above) is not
1007 available, it is RECOMMENDED that a SRC use mutual hop-by-hop
1008 Transport Layer Security (TLS) authentication and encryption
1009 mechanisms described in "SIPS URI Scheme" and "Interdomain Requests"
1010 of [RFC3261].
1012 10. IANA Considerations
1014 This specification registers a new XML namespace, and a new XML
1015 schema.
1017 10.1. SIP recording metadata Schema Registration
1019 URI: urn:ietf:params:xml:ns:recording
1021 Registrant Contact: IETF SIPREC working group, Ram mohan
1022 R(rmohanr@cisco.com)
1024 XML: the XML schema to be registered is contained in Section 6.
1026 Its first line is and its last
1027 line is
1029 11. Acknowledgement
1031 We wish to thank John Elwell(Siemens-Enterprise), Henry Lum(Alcatel-
1032 Lucent), Leon Portman(Nice), De Villers, Andrew Hutton(Siemens-
1033 Enterprise), Deepanshu Gautam(Huawei), Charles Eckel(Cisco), Muthu
1034 Arul(Cisco), Michael Benenson(Cisco), Hadriel Kaplan (ACME), Brian
1035 Rosen(Neustar), Scott Orton(Broadsoft) for their valuable comments
1036 and inputs.
1038 We wish to thank Joe Hildebrand(Cisco), Peter Saint-Andre(Cisco) for
1039 the valuable XML related guidance and Martin Thompson for validating
1040 the XML schema and providing comments on the same.
1042 12. Appendix A: Metadata Model Object Instances
1044 This section describes the metadata model object instances for
1045 different use cases of SIPREC. For the sake of simplicity as the
1046 media streams sent by each of the participants is received by every
1047 other participant in these use cases, it is NOT shown in the object
1048 instance diagrams below. Also for the sake of ease not all
1049 attributes of each object are shown in these instance diagrams.
1051 12.1. Use case 1: Basic Call
1053 Basic call between two Participants A and B. In this use case each
1054 participant sends one Media Stream. For the sake of simplicity
1055 "receives" lines are not shown in this instance diagram. Media
1056 Streams sent by each participant is received all other participants
1057 of that CS.
1059 +-------------------------------+
1060 | Recording Session (RS) |
1061 +-------------------------------+
1062 |
1063 |
1064 |
1065 +----------------+
1066 | Communication |
1067 | Session (CS) |
1068 +----------------+-----------------------+
1069 | Start Time | |
1070 +----------------+ |
1071 | |
1072 |-------------------+ |
1073 | | |
1074 +---------------+ +---------------+ |
1075 | ParticipantA | | ParticipantB | |
1076 | | | | |
1077 +---------------+ +---------------+ |
1078 | | |
1079 sends | | sends |
1080 | | |
1081 +---------------+ +---------------+ |
1082 |Media Stream A1| |Media Stream B1| |
1083 +---------------+ +---------------+ |
1084 |MediaStream Ref| |MediaStream Ref| |
1085 | | | | |
1086 +---------------+ +---------------+ |
1087 | | |
1088 +-----------------------------------+
1090 12.2. Use case 2: Hold/Resume
1092 Basic call between two Participants A and B and with Participant A or
1093 B doing a Hold/Resume. In this use case each participant sends one
1094 Media Stream. After Hold/Resume the properties of Media can change.
1095 For the sake of simplicity "receives" lines are not shown in this
1096 instance diagram. Media Streams sent by each participant is received
1097 all other participants of that CS.
1099 +-------------------------------+
1100 | Recording Session (RS) |
1101 +-------------------------------+
1102 | |
1103 | |
1104 | |
1105 | +-------------------------------+
1106 | | Communication Session (CS) |
1107 | +-----------| Group(CSG) |
1108 | | +-------------------------------+
1109 | | | Unique-id1 |
1110 | | +-------------------------------+
1111 | |
1112 | |
1113 | |
1114 +----------------+
1115 | Communication |
1116 +-| Session (CS) |----------------------------------------------+
1117 | +----------------+ |
1118 | | | |
1119 | +----------------+ |
1120 | | |
1121 | |-------------------+ |
1122 | | | |
1123 | +---------------+ +---------------+ |
1124 | | ParticipantA | | ParticipantB |-----------+ |
1125 | | |--+ | | | |
1126 | +---------------+ | +---------------+ |sends(After |
1127 | | | | | | | Resume) |
1128 | | | | | | +--------------+ |
1129 | sends | | +--+ | sends | |MediaStream B3| |
1130 | | -----+ | | +-----+ +--------------+ |
1131 | +---------------+ | | +---------------+ | |MediaStreamRef|-|
1132 | |Media Stream A1| | | |Media Stream B1| | | | |
1133 | +---------------+ | | +---------------+ | | | |
1134 +-|MediaStreamref | | | |MediaStreamRef | | +--------------+ |
1135 | | | | | |-|-------------------|
1136 +---------------+ | | +---------------+ | |
1137 | | | |
1138 +------------+ |sends |sends (hold) |
1139 | sends |(Resume) | |
1140 | (hold) +-------+ +-------+ |
1141 | | | |
1142 +---------------+ +---------------+ +--------------+ |
1143 |Media Stream A2| |Media Stream A3| |MediaStream B2| |
1144 +---------------+ +---------------+ | | |
1145 |MediaStreamref | |MediaStreamRef | +--------------+ |
1146 | | | | |Codec Params | |
1147 +---------------+ +---------------+ | | |
1148 | | | | |
1149 | | +--------------+ |
1150 | | | |
1151 +------------------------------------------------------+
1153 12.3. Use case 3: Basic call with Transfer
1155 Basic call between two Participants A and B and with Participant A
1156 transfer(consult transfer) to Participant C. In this use case each
1157 participant sends one Media Stream. After transfer the properties of
1158 Participant A Media can change. For the sake of simplicity
1159 "receives" lines are not shown in this instance diagram. Media
1160 Streams sent by each participant is received all other participants
1161 of that CS.
1163 +-------------------------------+
1164 | Recording Session (RS) |-------+
1165 +-------------------------------+ |
1166 | |
1167 | |
1168 | |
1169 +-------------------------------+ |
1170 | Communication Session (CS) | |
1171 | Group(CSG) | |
1172 +-------------------------------+ |
1173 | Unique-id1 | |
1174 +-------------------------------+ |
1175 | |
1176 |----------------------------+
1177 |
1178 |-----------------+
1179 | |
1180 +----------------+ +----------------+
1181 | Communication | | Communication |
1182 | Session (CS)1 | | Session (CS)2 |
1183 +----------------+ +----------------+-----------+
1184 | | | | |
1185 +----------------+ +----------------+ |
1186 | |
1187 |-------------------+ |
1188 | | | |
1189 +---------------+ | +---------------+ |
1190 | ParticipantA | | | ParticipantB | |
1191 | | | | | |
1192 +---------------+ | +---------------+ |
1193 | | | |
1195 sends | | | sends |
1196 | | | |
1197 +---------------+ | +---------------+ |
1198 |Media Stream A1| | |Media Stream B1| |
1199 +---------------+ | +---------------+ |
1200 | | | | | |
1201 | | | | Media Stream | |
1202 | Media Stream |---+---| Ref | |
1203 | Ref | | | |
1204 +---------------+ +---------------+ |
1205 |
1206 |
1207 +----------------------------|
1208 | |
1209 +--------------------------------+ |
1210 | | |
1211 +---------------+ +---------------+ |
1212 | Participant A | | Participant C | |
1213 | (same) | | | |
1214 +---------------+ +---------------+ |
1215 | | |
1216 | sends (After transfer) | sends |
1217 +----------------+ +----------------+|
1218 | Media Stream A2| | Media Stream C1||
1219 +----------------+ +----------------+|
1220 | Media StreamRef| | Media StreamRef||
1221 | | | ||
1222 | | | ||
1223 +----------------+ +----------------+|
1224 | | |
1225 | | |
1226 | | |
1227 +-------------------------------------------+
1229 12.4. Conference Use Cases
1231 Depending on who act as SRC and the information that an SRC has there
1232 can be several ways to model conference use cases. This section has
1233 instance diagrams for the following cases:
1235 o A CS where one of the participant (which is also SRC) is a user in
1236 a conference
1237 o A CS where one of the participant is focus ( which is also SRC)
1238 o A CS where one of the participant is user and the SRC is a
1239 different entity like B2BUA
1241 o A CS where one of the participant is focus and the SRC is a
1242 different entity like B2BUA
1244 NOTE: There MAY be other ways to model the same use cases depending
1245 on what information the SRC has.
1247 12.4.1. Case 1:
1249 This is the usecase where there is a CS with one of the participant
1250 (who is also SRC) as a user in a conference. For the sake of
1251 simplicity the receive lines for each of the participant is not
1252 shown.
1254 +---------------------------------------------------+
1255 | Communication Session |
1256 | +-------------+ +--------------+ |
1257 | | | | | |
1258 | |Participant B| | Participant A| |
1259 | | (User in |--------------| | |
1260 | | conf/SRC) | | | |
1261 | +-------------+ +--------------+ |
1262 | | | | | |
1263 +---------------------------------------------------+
1264 | | | |
1265 | | | |
1266 D E F G (Participants of Conference)
1268 Instance Diagram:
1270 +-------------------------------+
1271 | Recording Session (RS) |--+
1272 +-------------------------------+ |
1273 | |
1274 | |
1275 | |
1276 +-------------------------------+ |
1277 | Communication Session (CS) | |
1278 | Group(CSG) | |
1279 +-------------------------------+ |
1280 | Unique-id1 | |
1281 +-------------------------------+ |
1282 | |
1283 |-----------------------+
1284 |
1285 +----------------+
1286 | Communication |
1287 | Session (CS) |--+----------------+-----+
1288 +----------------+ | | |
1289 | | | | |
1290 +----------------+ | | |
1291 | | | |
1292 | | | |
1293 | | | |
1294 +---------------+ | | |
1295 | ParticipantA | | | |
1296 | | | | |
1297 +---------------+ | | |
1298 | | | |
1299 sends | | | |
1300 | | | |
1301 +---------------+ | | |
1302 |Media Stream A1| | | |
1303 +---------------+ | | |
1304 |MediaStream Ref|-----|----------------+ |
1305 | | | | |
1306 +---------------+ | | |
1307 | | |
1308 | | |
1309 +-------------+ | |
1310 | | |
1311 | | |
1312 +----------------+ | |
1313 | Participant B | | |
1314 | (in conf) | | |
1315 +----------------+ | |
1316 | | |
1317 sends | | |
1318 | | |
1319 +----------------+ | |
1320 | Media Stream B1|---------------------+ |
1321 +----------------+ sends |
1322 | MediaStream Ref| |
1323 | | +-----------------+
1324 +----------------+ |
1325 | |
1326 |sends |
1327 | |
1328 +-----------------+-------------+------------+
1329 | | | |
1330 | | | |
1331 +------------+ +------------+ +------------+ +-------------+
1332 |participantD| |ParticipantE| |ParticipantF| |Participant G|
1333 +------------+ +------------+ +------------+ +-------------+
1334 In this example we have two participants A and B who are part of a
1335 Communication Session(CS). One of the participants B is part of a
1336 conference and also acts as SRC.There can be two cases here. B can
1337 be a participant of the conference or B can be a focus. In this
1338 instance diagram Participant B is a user in a conference. The SRC
1339 (Participant B) subscribes to conference event package to get the
1340 details of other particiants. Participant B(SRC) sends the same
1341 through the metadata to SRS. In this instance diagram the Media
1342 Stream(mixed stream) sent from Participant B has media streams
1343 contributed by conference participants (D,E,F and G). For the sake
1344 of simplicity the "receives" line is not shown here. In this example
1345 the media stream sent by each participant(A or B) of CS is received
1346 by all other participant(A or B).
1348 12.4.2. Case 2:
1350 This is the usecase where there is a CS where one of the participant
1351 is focus ( which is also SRC).
1353 +---------------------------------------------------+
1354 | Communication Session |
1355 | +--------------+ +--------------+ |
1356 | | |--------------| | |
1357 | |Participant C | | Participant A| |
1358 | | (Focus in |------+ | | |
1359 | | conf and SRC)|---+ | +--------------+ |
1360 | +--------------+ | | |
1361 | | | +---------+ |
1362 | | | | |
1363 | +--------------+ | +---------------+ |
1364 | | Participant B| +---+ | Participant D | |
1365 | | | | | | |
1366 | +--------------+ | +---------------+ |
1367 | | |
1368 | +--------------+ |
1369 | |Participant E | |
1370 | | | |
1371 | +--------------+ |
1372 | |
1373 +---------------------------------------------------+
1375 Instance Diagram:
1377 +-------------------------------+
1378 | Recording Session (RS) |
1379 +-------------------------------+
1380 |-------------------------+
1381 | |
1382 | |
1383 +-------------------------------+ |
1384 | Communication Session (CS) | |
1385 | Group(CSG) | |
1386 +-------------------------------+ |
1387 | Unique-id1 | |
1388 +-------------------------------+ |
1389 | |
1390 |-------------------------+
1391 |
1392 +----------------+
1393 | Communication |
1394 | Session (CS) |----------------------+
1395 +----------------+ |
1396 | | |
1397 +----------------+ |
1398 | |
1399 |-------------------+ |
1400 | | | |
1401 +---------------+ | +---------------+ |
1402 | ParticipantA | | | ParticipantB | |
1403 | | | | | |
1404 +---------------+ | +---------------+ |
1405 | | | |
1406 sends | | | sends |
1407 | | | |
1408 +---------------+ | +---------------+ |
1409 |Media Stream A1| | |Media Stream B1| |
1410 +---------------+ | +---------------+ |
1411 |MediaStream Ref| | |MediaStream Ref| |
1412 | |---+---| | |
1413 +---------------+ +---------------+ |
1414 |
1415 +----------------------------------+
1416 | | | |
1417 | | | |
1418 +---------------+ | +---------------+ |
1419 | ParticipantD | | | ParticipantE | |
1420 | | | | | |
1421 +---------------+ | +---------------+ |
1422 | | | |
1423 sends | | | sends |
1424 | | | |
1425 +---------------+ | +---------------+ |
1426 |Media Stream D1| | |Media Stream E1| |
1427 +---------------+ | +---------------+ |
1428 |MediaStream Ref| | |MediaStream Ref| |
1429 | |---+---| | |
1430 +---------------+ +---------------+ |
1431 |
1432 |
1433 +----------+
1434 +-----------------|
1435 | |
1436 | |
1437 +----------------+ |
1438 | Participant C | |
1439 | (focus +src) | |
1440 +----------------+ |
1441 | |
1442 Sends | +-------+
1443 | |
1444 "sends" OR | |
1445 contributed +----------------+
1446 by | Media Stream C1|
1447 Participants+----------------+ "receives" by participants A,B,D,E
1448 A,B,D,E | MediaStream Ref|------------------------------------
1449 ------------| Codec Params |
1450 +----------------+
1452 In this example we have two participants A and B who are part of a
1453 Communication Session(CS). One of the participants (C) is focus of a
1454 conference and also acts as SRC. The SRC (Participant C) being the
1455 Focus of the conference has access to the details of other
1456 particiants. SRC (Participant C) sends the same through the metadata
1457 to SRS. In this instance diagram the Media Stream(mixed stream) sent
1458 by C has media streams contributed by conference participants (A, B,
1459 D and E). Participants A, B,D and E sends Media Streams A1, B1, D1
1460 and E1 respectively. The media stream sent by Participant C(Focus)
1461 is received by all other participants of CS. For the sake of
1462 simplicity the "receives" line is not shown linked to all other
1463 participants.
1465 NOTE: SRC ( Participant C) can send mixed stream or seperate streams
1466 to SRS
1468 12.4.3. Case 3:
1470 A CS where one of the participant is user and the SRC is a different
1471 entity like B2BUA. In this case the SRC may not know that one of the
1472 user is part of conference. Hence the instance diagram will not have
1473 information about the conference participants.
1475 +---------------------------------------------------+
1476 | Communication Session |
1477 | +-------------+ +------+ +--------------+ |
1478 | | | | (SRC)| | | |
1479 | |Participant B|--|B2BUA |----| Participant A| |
1480 | | (User in | +------+ | | |
1481 | | conf) | | | |
1482 | +-------------+ +--------------+ |
1483 | | | | | |
1484 +---------------------------------------------------+
1485 | | | |
1486 | | | |
1487 D E F G (Participants of Conference)
1489 12.4.4. Case 4:
1491 A CS where one of the participant is focus and the SRC is a different
1492 entity like B2BUA. In this case the participant which is focus sends
1493 "isfocus" in SIP message to SRC. The SRC subscribe to conference
1494 event package on seeing this "isfocus". SRC learns the details of
1495 other participants of conference from the conference package and send
1496 the same in metadata to SRS. The instance diagram for this use case
1497 is same as Case 1.
1499 +--------------------------------+
1500 | Conference Event Package |
1501 | |
1502 +--------------------------------+
1503 |
1504 | subscribes
1505 |
1506 +---------------------|-----------------------------+
1507 | Communication |Session |
1508 | +-------------+ +------+ +--------------+ |
1509 | | | | (SRC)| | | |
1510 | |Participant B|--|B2BUA |----| Participant A| |
1511 | | (FOCUS in | +------+ | | |
1512 | | conf) | | | |
1513 | +-------------+ +--------------+ |
1514 | | | | | |
1515 +---------------------------------------------------+
1516 | | | |
1517 | | | |
1518 D E F G (Participants of Conference)
1520 13. Appendix B: Metadata XML schema Instances
1522 This section describes the metadata model XML instances for different
1523 use cases of SIPREC. For the sake of simplicity the complete SIP
1524 messages are NOT shown here.
1526 13.1. Use case 1: Basic Call
1528 Basic call between two Participants A(Ram) and B(Partha) who are part
1529 of one session. In this use case each participant sends two Media
1530 Streams. Media Streams sent by each participant is received all
1531 other participants of that CS in this use-case. Below is the initial
1532 snapshot sent by SRC that has complete metadata. For the sake of
1533 completeness even snippets of SDP is shown. For the sake of
1534 simplicity these use-cases assume the RS stream is unmixed.
1536 Content-Type: application/SDP
1537 ...
1538 m=audio 49170 RTP/AVP 0
1539 a=rtpmap:0 PCMU/8000
1540 a=label:96
1541 a=sendonly
1542 ...
1543 m=video 49174 RTP/AVPF 96
1544 a=rtpmap:96 H.264/90000
1545 a=label:97
1546 a=sendonly
1547 ...
1548 m=audio 51372 RTP/AVP 0
1549 a=rtpmap:0 PCMU/8000
1550 a=label:98
1551 a=sendonly
1552 ...
1553 m=video 49176 RTP/AVPF 96
1554 a=rtpmap:96 H.264/90000
1555 a=label:99
1556 a=sendonly
1557 ....
1558
1559
1560 complete
1561
1562 2010-12-16T23:41:07Z
1563
1564
1565
1566 sip:alice@cisco.com
1568
1569
1570 FOO!
1571 bar
1572
1573
1574
1575
1576 urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302
1577
1578 2010-12-16T23:41:07Z
1579
1580 FOO!
1581 bar
1582
1583
1584
1587 sip:ram@blr.cisco.com
1588 urn:uuid:8b53f3de-da39-4846-93c7-ee5e5f8f6f0b
1589 urn:uuid:50000c9b-9191-40a4-8231-5bcbca5e2b17
1590 urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a
1591 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a
1592 2010-12-16T23:41:07Z
1593
1594 FOO!
1595 bar
1596
1597
1599
1602 sip:partha@blr.sonus.com
1603 urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a
1604 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a
1605 urn:uuid:50000c9b-9191-40a4-8231-5bcbca5e2b17
1606 urn:uuid:8b53f3de-da39-4846-93c7-ee5e5f8f6f0b
1607 2010-12-16T23:41:07Z
1608
1609 FOO!
1610 bar
1611
1612
1613
1615
1617
1618
1620
1621
1622
1624
1625
1626
1628
1629
1630
1632 13.2. Use case 2: Hold/resume
1634 Basic call between two Participants A and B. This is the continuation
1635 of above use-case. One of the participants(say A) goes on hold and
1636 then resumes as part of the same session. The metadata snapshot
1637 looks as below
1639 During hold
1640 Content-Type: application/SDP
1641 ...
1642 m=audio 49170 RTP/AVP 0
1643 a=rtpmap:0 PCMU/8000
1644 a=label:96
1645 a=inactive
1646 ...
1647 m=video 49174 RTP/AVPF 96
1648 a=rtpmap:96 H.264/90000
1649 a=label:97
1650 a=inactive
1651 ...
1652 m=audio 51372 RTP/AVP 0
1653 a=rtpmap:0 PCMU/8000
1654 a=label:98
1655 a=sendonly
1656 ...
1657 m=video 49176 RTP/AVPF 96
1658 a=rtpmap:96 H.264/90000
1659 a=label:99
1660 a=sendonly
1661 ....
1663
1664
1665 partial
1666
1669 sip:ram@blr.cisco.com
1670 urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a
1671 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a
1672
1673
1676 sip:partha@blr.cisco.com
1677 urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a
1678 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a
1679
1680
1682 During resume
1684 The snapshot will look pretty much same as Use-case 1.
1686 13.3. Use case 3: Basic Call with transfer
1688 Basic call between two Participants A and B is connected as in Use-
1689 case 1. Transfer is initiated by one of the participants of by other
1690 entity(3PCC case). SRC sends a snapshot of the participant changes
1691 to SRS. In this instance participant A(Ram) drops out during the
1692 transfer and Participant C(Paul) joins the session. There can be two
1693 cases here, same session continues after transfer or a new session
1694 (e.g. REFER based transfer) is created
1696 Transfer with same session retained - (.e.g. RE-INVITE based
1697 transfer). Participant A drops out and C is added to the same
1698 session. No change to session/group element. C will be new stream
1699 element which maps to RS SDP using the same labels in this instance.
1701 Content-Type: application/SDP
1702 ...
1703 m=audio 49170 RTP/AVP 0
1704 a=rtpmap:0 PCMU/8000
1705 a=label:96
1706 a=sendonly
1707 ...
1708 m=video 49174 RTP/AVPF 96
1709 a=rtpmap:96 H.264/90000
1710 a=label:97
1711 a=sendonly
1712 ...
1713 m=audio 51372 RTP/AVP 0
1714 a=rtpmap:0 PCMU/8000
1715 a=label:98
1716 a=sendonly
1717 ...
1718 m=video 49176 RTP/AVPF 96
1719 a=rtpmap:96 H.264/90000
1720 a=label:99
1721 a=sendonly
1722 ....
1723
1724
1725 partial
1726
1729 sip:partha@blr.sonus.com
1730 urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a
1731 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a
1732 urn:uuid:eb424026-6f54-4ef8-a4d0-bb658a1fc6cf
1733 urn:uuid:01c47915-4777-11d8-bc70-0090272ff725
1734
1736
1739 sip:paul@box.mit.com
1740 urn:uuid:eb424026-6f54-4ef8-a4d0-bb658a1fc6cf
1741 urn:uuid:01c47915-4777-11d8-bc70-0090272ff725
1742 urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a
1743 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a
1744 2010-12-16T23:41:07Z
1745
1746 FOO!
1747 bar
1748
1749
1751
1753
1754
1755
1757
1758
1759
1761
1762
1763
1765
1766
1767
1769 Transfer with new session - (.e.g. REFER based transfer). In this
1770 case new session is part of same grouping (done by SRC).
1772 SRC may send an optional snapshot indicating stop for the old
1773 session.
1775
1776
1777 Partial
1778
1779 urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302
1780
1781 2010-12-16T23:41:07Z
1782
1783 FOO!
1784 bar
1785
1786
1787
1790 2010-12-16T23:41:07Z
1791
1793
1796 sip:partha@blr.sonus.com
1797 2010-12-16T23:41:07Z
1798
1800
1802 SRC sends a snapshot to indicate the participant change and new
1803 session information after transfer. In this example the same RS is
1804 used.
1806 Content-Type: application/SDP
1807 ...
1808 m=audio 49170 RTP/AVP 0
1809 a=rtpmap:0 PCMU/8000
1810 a=label:96
1811 a=sendonly
1812 ...
1813 m=video 49174 RTP/AVPF 96
1814 a=rtpmap:96 H.264/90000
1815 a=label:97
1816 a=sendonly
1817 ...
1818 m=audio 51372 RTP/AVP 0
1819 a=rtpmap:0 PCMU/8000
1820 a=label:98
1821 a=sendonly
1822 ...
1823 m=video 49176 RTP/AVPF 96
1824 a=rtpmap:96 H.264/90000
1825 a=label:99
1826 a=sendonly
1827 ....
1828
1829
1830 partial
1831
1832 urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302
1833
1834 2010-12-16T23:41:07Z
1835
1836 FOO!
1837 bar
1838
1839
1840
1843 sip:partha@blr.sonus.com
1844 urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a
1845 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a
1846 urn:uuid:eb424026-6f54-4ef8-a4d0-bb658a1fc6cf
1847 urn:uuid:01c47915-4777-11d8-bc70-0090272ff725
1848 2010-12-16T23:32:03Z
1849
1850 FOO!
1851 bar
1852
1853
1855
1858 sip:paul@box.mit.com
1859 urn:uuid:eb424026-6f54-4ef8-a4d0-bb658a1fc6cf
1860 urn:uuid:01c47915-4777-11d8-bc70-0090272ff725
1861 urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a
1862 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a
1863 2010-12-16T23:41:07Z
1864
1865 FOO!
1866 bar
1867
1868
1869
1871
1872
1873
1875
1876
1877
1879
1880
1881
1883
1884
1885
1887 14. References
1889 14.1. Normative References
1891 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1892 Requirement Levels", BCP 14, RFC 2119, March 1997.
1894 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
1896 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
1897 A., Peterson, J., Sparks, R., Handley, M., and E.
1898 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
1899 June 2002.
1901 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1902 January 2004.
1904 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
1905 Internet: Timestamps", RFC 3339, July 2002.
1907 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
1908 Description Protocol", RFC 4566, July 2006.
1910 [RFC4574] Levin, O. and G. Camarillo, "The Session Description
1911 Protocol (SDP) Label Attribute", RFC 4574, August 2006.
1913 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description
1914 Protocol (SDP) Content Attribute", RFC 4796,
1915 February 2007.
1917 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
1918 "Indicating User Agent Capabilities in the Session
1919 Initiation Protocol (SIP)", RFC 3840, August 2004.
1921 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
1922 Unique IDentifier (UUID) URN Namespace", RFC 4122,
1923 July 2005.
1925 14.2. Informative References
1927 [RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use
1928 Cases and Requirements for SIP-Based Media Recording
1929 (SIPREC)", RFC 6341, August 2011.
1931 [I-D.ietf-siprec-architecture]
1932 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An
1933 Architecture for Media Recording using the Session
1934 Initiation Protocol", draft-ietf-siprec-architecture-02
1935 (work in progress), April 2011.
1937 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
1938 August 1999.
1940 Authors' Addresses
1942 Ram Mohan Ravindranath
1943 Cisco Systems, Inc.
1944 Cessna Business Park,
1945 Kadabeesanahalli Village, Varthur Hobli,
1946 Sarjapur-Marathahalli Outer Ring Road
1947 Bangalore, Karnataka 560103
1948 India
1950 Email: rmohanr@cisco.com
1952 Parthasarathi Ravindran
1953 Sonus Networks
1954 Prestige Shantiniketan - Business Precinct
1955 Whitefield Road
1956 Bangalore, Karnataka 560066
1957 India
1959 Email: pravindran@sonusnet.com
1960 Paul Kyzivat
1961 Unaffiliated
1962 Boxborough, MA
1963 USA
1965 Email: pkyzivat@alum.mit.edu