idnits 2.17.1
draft-ietf-siprec-metadata-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 6, 2011) is 4678 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 Parthasarathi. Ravindran
3 Intended status: Standards Track Paul. Kyzivat
4 Expires: January 7, 2012 Cisco Systems, Inc.
5 July 6, 2011
7 Session Initiation Protocol (SIP) Recording Metadata
8 draft-ietf-siprec-metadata-02
10 Abstract
12 Session recording is a critical requirement in many communications
13 environments such as call centers and financial trading. In some of
14 these environments, all calls must be recorded for regulatory,
15 compliance, and consumer protection reasons. Recording of a session
16 is typically performed by sending a copy of a media stream to a
17 recording device. This document describes the metadata model as
18 viewed by Session Recording Server(SRS) and the Recording metadata
19 format.
21 Status of this Memo
23 This Internet-Draft is submitted in full conformance with the
24 provisions of BCP 78 and BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF). Note that other groups may also distribute
28 working documents as Internet-Drafts. The list of current Internet-
29 Drafts is at http://datatracker.ietf.org/drafts/current/.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 This Internet-Draft will expire on January 7, 2012.
38 Copyright Notice
40 Copyright (c) 2011 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (http://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
53 Table of Contents
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
57 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
58 4. Metadata Model . . . . . . . . . . . . . . . . . . . . . . . . 5
59 5. Recording Metadata Format . . . . . . . . . . . . . . . . . . 6
60 5.1. XML data format . . . . . . . . . . . . . . . . . . . . . 6
61 5.1.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 7
62 5.1.2. recording . . . . . . . . . . . . . . . . . . . . . . 7
63 6. Recording Metadata elements . . . . . . . . . . . . . . . . . 7
64 6.1. Recording Session . . . . . . . . . . . . . . . . . . . . 7
65 6.1.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 8
66 6.1.2. Associations . . . . . . . . . . . . . . . . . . . . . 8
67 6.2. Communication Session Group . . . . . . . . . . . . . . . 8
68 6.2.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 9
69 6.2.2. Associations . . . . . . . . . . . . . . . . . . . . . 9
70 6.2.3. XML element . . . . . . . . . . . . . . . . . . . . . 9
71 6.3. Communication Session . . . . . . . . . . . . . . . . . . 10
72 6.3.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 10
73 6.3.2. Associations . . . . . . . . . . . . . . . . . . . . . 11
74 6.3.3. XML element . . . . . . . . . . . . . . . . . . . . . 12
75 6.4. Participant . . . . . . . . . . . . . . . . . . . . . . . 12
76 6.4.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 12
77 6.4.2. Associations . . . . . . . . . . . . . . . . . . . . . 13
78 6.4.3. XML element . . . . . . . . . . . . . . . . . . . . . 13
79 6.5. Media Stream . . . . . . . . . . . . . . . . . . . . . . . 14
80 6.5.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 14
81 6.5.2. Associations . . . . . . . . . . . . . . . . . . . . . 15
82 6.5.3. XML element . . . . . . . . . . . . . . . . . . . . . 15
83 6.6. Extension Data . . . . . . . . . . . . . . . . . . . . . . 15
84 6.6.1. Composition . . . . . . . . . . . . . . . . . . . . . 15
85 6.6.2. XML element . . . . . . . . . . . . . . . . . . . . . 15
86 6.7. start-time/stop-time . . . . . . . . . . . . . . . . . . . 16
87 7. SIP Recording Metadata Example . . . . . . . . . . . . . . . . 16
88 7.1. Complete SIP Recording Metadata Example . . . . . . . . . 16
89 7.2. Partial Update of Recording metadata XML body . . . . . . 18
90 8. XML Schema definition for Recording metadata . . . . . . . . . 18
91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
92 9.1. Connection Security . . . . . . . . . . . . . . . . . . . 21
93 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
94 10.1. SIP recording metadata Schema Registration . . . . . . . . 22
96 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 22
97 12. Appendix A: Metadata Model Object Instances . . . . . . . . . 22
98 12.1. Use case 1: Basic Call . . . . . . . . . . . . . . . . . . 22
99 12.2. Use case 2: Basic Call with hold/resume . . . . . . . . . 23
100 12.3. Use case 3: Basic call with Transfer . . . . . . . . . . . 25
101 12.4. Conference Use Cases . . . . . . . . . . . . . . . . . . . 26
102 12.4.1. Case 1: . . . . . . . . . . . . . . . . . . . . . . . 27
103 12.4.2. Case 2: . . . . . . . . . . . . . . . . . . . . . . . 29
104 12.4.3. Case 3: . . . . . . . . . . . . . . . . . . . . . . . 31
105 12.4.4. Case 4: . . . . . . . . . . . . . . . . . . . . . . . 32
106 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
107 13.1. Normative References . . . . . . . . . . . . . . . . . . . 33
108 13.2. Informative References . . . . . . . . . . . . . . . . . . 33
109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
111 1. Introduction
113 Session recording is a critical requirement in many communications
114 environments such as call centers and financial trading. In some of
115 these environments, all calls must be recorded for regulatory,
116 compliance, and consumer protection reasons. Recording of a session
117 is typically performed by sending a copy of a media stream to a
118 recording device. This document focuses on the Recording metadata
119 which describes the communication session. The document describes a
120 metadata model as viewed by Session Recording Server and the
121 Recording metadata format, the requirements for which are described
122 in [I-D.ietf-siprec-req] and the architecture for which is described
123 in [I-D.ietf-siprec-architecture].
125 2. Terminology
127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
129 document are to be interpreted as described in [RFC2119]. This
130 document only uses these key words when referencing normative
131 statements in existing RFCs."
133 3. Definitions
135 Metadata element: A metadata element represent one block/class of
136 metadata model.
138 Metadata attributes: Metadata attributes represents the attributes
139 listed in each of the blocks of metadata model
141 Metadata Composition: Composition represents owns/holds relationship
142 to show Metadata elements contained in another Metadata element
144 Metadata Associations: Metadata associations represents the
145 associations between different Metadata elements in the model. It
146 uses UML notation.
148 XML element: An XML element represent one XML schema complexType
149 element (xs:complexType) of XML schema
151 XML attributes: An XML attribute represent one XML schema element
152 (xs:element) of XML schema
154 4. Metadata Model
156 Metadata is the information that describes recorded media and the CS
157 to which they relate. Below diagram shows a model for Metadata as
158 viewed by Session Recording Server (SRS).
160 +-------------------------------+ 1
161 | Recording Session (RS) |---------------+
162 +-------------------------------+ |
163 |1..* | 1..* |
164 | | |
165 | | 0..* |
166 | +-----------------+ |
167 | | Communication | |
168 | | Session (CS) | 1 |
169 | | Group |--------------|
170 | +-----------------+ |
171 | | 0..1 |
172 | | |
173 |0..* | 1..* |
174 +-------------------------------+ |
175 | Communication Session (CS) | 1 |
176 | |---------------|
177 +-------------------------------+ | +------------+
178 | 1..* |1..* | | |
179 | | | 0..* |Extension |
180 | 2..* |0..* |/\_____| Data |
181 +-------------+ receives +----------------+ |\/ | |
182 | Participant |----------| Media Streams | | +------------+
183 | |0..* 0..*| | |
184 | | | | |
185 | | | | |
186 | | sends | | |
187 | |----------| | |
188 | |1.* 0..*| | |
189 +-------------+ +----------------+ |
190 | | |
191 |1 |1 |
192 | | |
193 +----------------------------------------+
195 Session Recording Client (SRC) MAY initiate the Recording Session.
197 Here, Recording Session is a completely independent from the
198 Communication Session that is being recorded at both the SIP dialog
199 level and at the session level. The metadata MUST be conveyed from
200 SRC to SRS. The metadata MUST be conveyed within the Recording
201 Session Dialog.
203 Note that the metadata model captures changes that occur over the
204 duration of the recording session. For example, if the call is
205 transferred from one participant to another, then the SRC MUST convey
206 a change of participant and the properties of the new media stream to
207 the SRS.
209 Some of the metadata is not required to be conveyed explicitly from
210 the SRC to the SRS, if it can be obtained contextually by the SRS.
211 For instance, the timing of RS block changes(like Start / Stop time)
212 may not be explicitly conveyed from the SRC to the SRS (The Date
213 header in RS dialog SIP message MAY provide the timing, but it is
214 optional). In such cases the time a change occurred may be assumed
215 to be the same as the time when notification of the change is
216 received by the SRS.
218 5. Recording Metadata Format
220 This section gives an overview of Recording Metadata Format. The
221 media related details of metadata MUST be passed across using session
222 description protocol (SDP) [RFC4566]. SDP attributes describes about
223 different media formats like audio, video. The other metadata
224 attributes like participant details MUST be passed across in new
225 Recording specific XML document namely application/rs-metadata+xml.
226 The linkage between application/rs-metadata+xml XML schema and
227 metadata SDP is done using the SDP label attribute (a=label:xxx)
228 referenced in [RFC4574].
230 Metadata is passed across in Recording Session(RS) incrementally
231 whenever there is a change in CS.
233 5.1. XML data format
235 Recording Metadata document is an XML document which will be embedded
236 as a message body. recording element MUST present in all recording
237 metadata XML document. recording acts as container for all other
238 elements in this XML document.
240 Recording object is a XML document. It MUST have the XML declaration
241 and it SHOULD contain an encoding declaration in the XML declaration,
242 e.g., "". If the charset
243 parameter of the MIME content type declaration is present and it is
244 different from the encoding declaration, the charset parameter takes
245 precedence.
247 Every application conforming to this specification MUST accept the
248 UTF-8 character encoding to ensure the minimal interoperability.
250 Syntax and semantics error in recording XML document has to be
251 informed to the originator using application specific mechanism.
253 5.1.1. Namespace
255 The namespace URI for elements defined by this specification is a
256 Uniform Resource Namespace (URN) [RFC2141], using the namespace
257 identifier 'ietf' defined by [RFC2648] and extended by [RFC3688].
259 The URN is as follows: urn:ietf:params:xml:ns:recording
261 5.1.2. recording
263 recording element MUST contain an xmlns namespace attribute with
264 value as urn:ietf:params:xml:ns:siprec. One recording element MUST
265 present in the all recording metadata XML document.
267 dataMode element shows whether the XML document is complete document
268 or partial update. The default value is complete.
270 6. Recording Metadata elements
272 This section describes each element of the metadata model, and the
273 attributes of each element. This section also describes how
274 different elements are associated and the XML element for each of
275 them.
277 6.1. Recording Session
278 +-------------------------------+
279 | Recording Session (RS) |
280 +-------------------------------+
281 | | +-----------------+
282 | Start/End Time | 1 0..* | |
283 | |/\__________|Extension Data |
284 | |\/ | |
285 | | +-----------------+
286 +-------------------------------+
287 |1..* | 1..*
288 | |
289 |0..* | 0..*
290 Communication Communication
291 Session Session Group(CS Group)
293 A Recording Session element represents a SIP session created between
294 an SRC and SRS for the purpose of recording a Communication Session.
295 This element is represented by a SIP RS dialog and hence there is no
296 need for this element to be reflected in metadata XML.
298 6.1.1. Attributes
300 A Recording Session element MAY have attributes like:
301 o Start/End Time - Start and End time value MUST be derived from
302 Date header(if present in SIP message) in RS. In cases where Date
303 header is not present, Start/End time MAY be set to the time at
304 which SRS receives the notification of SIP message to setup RS /
305 disconnect RS.
307 6.1.2. Associations
309 One instance of Recording Session MUST have:
311 o Zero or more instances of Communication Session Group. CSG may be
312 zero because it is optional metadata block. Also the allowance of
313 zero instances is to accommodate persistent recording, where there
314 may be none.
315 o Zero or more instances of Communication Session blocks.
316 o Each CS Group MUST be associated with one or more Recording
317 Sessions [Here each RS can be setup by the potentially different
318 SRCs.]
320 6.2. Communication Session Group
321 Recording Session (RS)
322 | 1..*
323 |
324 | 0..*
325 +-------------------------------+
326 | Communication Session |
327 | Group |
328 +-------------------------------+
329 | Unique-ID | +----------------+
330 | | 1 0..* | |
331 | |/\_________|Extension Data |
332 | |\/ | |
333 +-------------------------------+ +----------------+
334 | 0..1
335 |
336 | 1..*
337 Communication Session (CS)
339 A Communication Session Group provides association or linking of
340 Communication Sessions.
342 6.2.1. Attributes
344 A CS Group MUST have a Unique-ID attribute. This Unique-ID is to
345 group different CSs that are related. SRC (or MAY be SRS) MUST
346 ensure the uniqueness of Unique-ID in case multiple SRC interacts
347 with the same SRS. The mechanism by which SRC groups the CS is
348 outside the scope of SIPREC.
350 6.2.2. Associations
352 A communication Session Group MUST be associated with RS and CS in
353 the following manner:
355 o There can be one or more Recording Session elements per
356 Communication Session Group.
357 o Each Communication Session Group MUST be associated with one or
358 more RS [Here each RS can be setup by the potentially different
359 SRCs]
360 o There MAY be one or more Communication Sessions per CS Group [e.g.
361 Consult Transfer]
362 o Each CS MAY be associated to zero or one CS-Group
364 6.2.3. XML element
366 Group element is an optional element provides the information about
367 the communication session group
368 Each communication session group (CSG) is represented using one group
369 element. Each group element has unique URN UUID attribute which
370 helps to uniquely identify CSG.
372 6.3. Communication Session
374 Recording Communication
375 Session Session Group(CS Group)
376 |1..* | 0..1
377 | |
378 |0..* | 1..*
379 +-------------------------------+ +-----------------+
380 | Communication Session (CS) | 1 0..* | |
381 | |/\_____________|Extension Data |
382 +-------------------------------+\/ | |
383 | CS Identifier | +-----------------+
384 | Termination Reason |
385 | Start Time |
386 | End Time |
387 +-------------------------------+
388 | |
389 | 1..* |1..*
390 | |
391 | 2..* |0..*
392 Participant Media Stream
394 A Communication Session block/element in the metadata model
395 represents Communication Session and its properties needed as seen by
396 SRC.
398 6.3.1. Attributes
400 A communication Session block MUST have the following attributes:
402 o Termination Reason - This represents the reason why a CS was
403 terminated. The communication session MAY contain a Call
404 Termination Reason. This MAY be derived from SIP Reason header of
405 CS.
406 o CS Identifier - This attribute is used to uniquely identify a CS.
407 o Start Time - This optional attribute represents CS start time
408 o End Time - This optional attribute represents CS end time
410 Attributes like Retention (represent the value/duration for which
411 Media streams of the CS needs to be retained), Force Deletion, Access
412 Information e.t.c that are primarily related to policy will not be
413 passed in metadata from SRC to SRS. However if there are
414 implementations where SRC has enough information, this could be sent
415 as Extension Data attached to CS
417 6.3.2. Associations
419 A Communication Session MUST be associated to CS-Group, Participant,
420 Media Stream and Recording Session blocks. Cardinalities between CS
421 and Participant allows:
423 o CS to have atleast two or more participants
424 o Participant MUST be associated with one or more CS's. This may
425 even includes participants who are not directly part of any CS.
426 An example of such a case is participants in a premixed media
427 stream. The SRC may have knowledge of such Participants, yet not
428 have any signaling relationship with them. This might arise if
429 one participant in CS is a conf focus. Another use case is if one
430 UA in CS works in 3pcc mode to acquire an MoH media stream, this
431 might be reflected as unique source for media stream without
432 having a reported signaling relationship to it. In all these
433 cases if SRC can learn enough information about the Participant,
434 they MUST be associated with CS.
435 o The model also allows participants in CS that are not participants
436 in the media. An example is the identity of a 3pcc controller
437 that has initiated a CS to two or more participants of the CS.
438 Another example is the identity of a conference focus. Of course
439 a focus is probably in the media, but since it may only be there
440 as a mixer, it may not report itself as a participant in any of
441 the media streams.
443 Cardinalities between CS and Media Stream allows:
445 o A CS to have zero or more Streams
446 o A stream can be associated with 1 or more CS. An example is
447 multicast MoH stream which might be associated with many CSs.
448 Also if we were to consider a B2BUA to have a separate CS on each
449 "side" then they might share a stream.(Though more likely this
450 would be treated as a single CS.)
452 Cardinalities between CS and RS allows:
454 o One instance of RS MUST have Zero or more instances of
455 Communication Session blocks.
456 o Each CS MUST be associated with one more RS [ Here each RS can be
457 potentially setup by different SRCs]
459 6.3.3. XML element
461 Session element provides the information about the communication
462 session
464 Each communication session(CS) has one session element. Each session
465 element has unique URN UUID attribute which helps to uniquely
466 identify CS.
468 Reason element MAY be included to indicate the reason for
469 termination. group-ref element MAY exist to indicate the group where
470 the mentioned session belongs.
472 6.4. Participant
474 Communication Session (CS)
475 | 1..*
476 |
477 | 2..*
478 +-------------------------------+
479 | Participant |
480 | |
481 +-------------------------------+
482 | AoR list | +-----------------+
483 | Name | 1 0..* | |
484 | Participant Type |/\__________|Extension Data |
485 | |\/ | |
486 +-------------------------------+ +-----------------+
487 | 0..* 1..*|
488 receives| |sends
489 | 0..* 0..*|
490 Media Stream
492 A Participant block has information about a device that is part of a
493 CS and/or contributes/consumes media stream(s) belonging to a CS.
495 6.4.1. Attributes
497 Participant has attributes like:
499 o AoR list - Has list of AoRs. An AoR MAY be SIP/SIPS/TEL URI.
500 There MAY be cases where a participant can have more than one AoR
501 [ e.g. P-Asserted-ID which can have both SIP and TEL URIs]
503 o Name - This attribute represents Participant name(SIP display
504 name) or DN number ( in case it is known)
506 Other attributes [ like Participant Role, Participant type ] MAY be
507 carried as part of extension data to Participant from SRC to SRS.
509 6.4.2. Associations
511 Cardinalities between participant and Media Stream allows:
513 o Participant to receives zero or more media streams
514 o Participant to send zero or more media streams. (Same participant
515 provides multiple streams e.g. audio and video)
516 o Media stream to be received by zero or more participants. Its
517 possible, though perhaps unlikely, that a stream is generated but
518 sent only to the SRC and SRS, not to any participant. E.g. In
519 conferencing where all participants are on hold and the SRC is
520 collocated with the focus. Also a media stream may be received by
521 multiple participants (e.g. Whisper calls, side conversations).
522 o Media stream to be sent by one or more participants (pre-mixed
523 streams).
525 Example of a case where a participant may receive Zero or more
526 streams - a Supervisor may have side conversation with Agent, while
527 Agent converses with customer.
529 6.4.3. XML element
531 Participant element provides information regarding the specific
532 participant involved in the recording
534 There MUST be atleast 2 participant for any given session. "send" or
535 "receive" element in each participant is associating SDP m-lines with
536 the participant. send element indicates that participant is sending
537 the stream of media with the mentioned media description. recv
538 element indicates that participant is receiving the stream and by
539 default all participant will receive the stream. recv element has
540 relevance in case whisper call scenario wherein few of the
541 participant in the session receives the stream and not others.
543 Participant MUST have AOR element which contains SIP/SIPS URI to
544 identify the participant. AOR element is SIP/SIPS URI FQDN or IP
545 address which represents the user. name is an optional element to
546 represent display name.
548 Each participant element has unique URN UUID attribute which helps to
549 uniquely identify participant and session URN UUID to associate
550 participant with specific session element. URN UUID of participant
551 *MUST* used in the scope of CSG and no new URN UUID has to be created
552 for the same element (participant, stream) between different CS in
553 the same CSG. In case URN UUID has to be used permanent, careful
554 usage of URN UUID to original AoR has to be decided by the
555 implementers and it is implementer's choice.
557 6.5. Media Stream
559 Participant
560 | 0..* 1..*|
561 receives| |sends
562 | 0..* 0..*|
563 +-------------------------+
564 | Media Stream |
565 | |
566 Communication 1..* 0..* +-------------------------+
567 Session ------------| Start Time | +----------+
568 | End Time |1 0..* | |
569 | Media Stream Reference |/\______|Extension |
570 | Content |\/ | Data |
571 +-------------------------+ +----------+
573 A Media Stream block MUST have properties of media as seen by SRC and
574 sent to SRS. Different instances of Media Stream block would be
575 created whenever there is a change in media (e.g. dir change like
576 pause/resume and/or codec change and/or participant change.).
578 6.5.1. Attributes
580 A Media Stream block MUST have the following attributes:
582 o Start Time - Represents Media Start time at SRC.
583 o End Time - Represents Media End time at SRC. This is an optional
584 attribute and MAY be included after a stream ends
585 o Media Stream Reference - In implementations this can reference to
586 m-line
587 o Content - The content of an MS element will be described in terms
588 of value from the RFC 4796 [RFC4796] registry.
590 NOTE: how the content attribute is conveyed (in metadata XML or in RS
591 SDP) is still open.
593 The metadata model should include media streams that are not being
594 delivered to the SRS. Examples include cases where SRC offered
595 certain media types but SRS chooses to accept only a subset of them
596 OR an SRC may not even offer a certain media type due it its
597 restrictions to record
599 6.5.2. Associations
601 A Media Stream MUST be associated with Participant and CS. The
602 details of association with the Participant are described in the
603 Participant block section. The details of association with CS is
604 mentioned in the CS section.
606 6.5.3. XML element
608 Stream element indicates SDP media lines associated with the session
609 and participants.
611 This element indicates the SDP m-line properties like label
612 attributes, media mode. Label attribute is used to link m-line SDP
613 body using label attribute in SDP m-line. The media mode helps in
614 understanding whether the media is mixed or not.
616 Each stream element has unique URN UUID attribute which helps to
617 uniquely identify stream and session URN UUID to associate stream
618 with specific session element. The open item here is whether to use
619 URN UUID (global id) or xml:id (local id).
621 6.6. Extension Data
623 A recording metadata object contains additional data not specified as
624 part of siprec. This is intended to accommodate future standards
625 track extensions, as well as vendor and user specific extensions.
626 The mechanism MUST provide a means of unambiguously distinguishing
627 such extension data.
629 6.6.1. Composition
631 Extension data element MUST be contained/owned by a Metadata element.
632 Each instance of Metadata element(except extension data element
633 itself) MAY have
635 o Zero or more instances of Extension data element
636 o Each Extension data element MUST be contained/owned by an Metadata
637 element other than itself
639 6.6.2. XML element
641 Extensiondata element provides the mechanism by which namespace/
642 element MAY be extended with standard or proprietary information.
644 extensiondata element MUST include any other XML namespace. Multiple
645 namespace MAY exists under extensiondata. extensiondata element exist
646 in each level like recording, session, participant, stream to provide
647 extensiondata specific to each element. extensiondata element MUST be
648 part of parent element for which the additional information is sent
649 and hence no Unique ID is needed.
651 6.7. start-time/stop-time
653 start-time/stop-time contains a string indicating the date and time
654 of the status change of this tuple. The value of this element MUST
655 follow the IMPP datetime format [RFC3339]. Timestamps that contain
656 'T' or 'Z' MUST use the capitalized forms. At a time, any of the
657 time tuple start-time or stop-time MAY exist in the element namely
658 group, session, participant, stream and not both timestamp at the
659 same time.
661 As a security measure, the timestamp element SHOULD be included in
662 all tuples unless the exact time of the status change cannot be
663 determined.
665 NOTE: Open item on whether start/stop attribute is needed for all
666 Metadata elements
668 7. SIP Recording Metadata Example
670 7.1. Complete SIP Recording Metadata Example
672 The following example provides all the tuples involved in Recording
673 Metadata XML body.
675
676
677
678 2010-12-16T23:41:07Z
679
680
681
682 sip:alice@cisco.com
683
684
685 FOO!
686 bar
687
688
689
690
691 urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302
692
693 2010-12-16T23:41:07Z
694
695 FOO!
696 bar
697
698
699
702 sip:partha@blr.cisco.com
703 urn:uuid:8b53f3de-da39-4846-93c7-ee5e5f8f6f0b
704 urn:uuid:50000c9b-9191-40a4-8231-5bcbca5e2b17
705 2010-12-16T23:41:07Z
706
707 FOO!
708 bar
709
710
712
715 sip:paul@box.cisco.com
716 urn:uuid:50000c9b-9191-40a4-8231-5bcbca5e2b17
717 urn:uuid:8b53f3de-da39-4846-93c7-ee5e5f8f6f0b
718 2010-12-16T23:41:07Z
719
720 FOO!
721 bar
722
723
724
726 2010-12-16T23:41:07Z
727
728
729
731 2010-12-16T23:41:07Z
732
733
734
736 2010-12-16T23:41:07Z
737
738
739
741 2010-12-16T23:41:07Z
742
743
744
746 SIP Recording Metadata Example XML body
748 7.2. Partial Update of Recording metadata XML body
750 The following example provides partial update in Recording Metadata
751 XML body for the above example. The example illustrate the stop time
752 of the specific stream.
754
755
756 partial
757
759
760
761
763
764
765
767
768
769
771
772
773
775 Partial update of SIP Recording Example XML body
777 8. XML Schema definition for Recording metadata
779 This section defines XML schema for Recording metadata document
781
782
788
789
791
792
793
794
796
798
800
802
804
805
806
807
808
810
812
813
815
816
817
818
820
822
824
826
827
829
830
831
832
834
837
839
841
843
845
846
848
850
851
852
853
855
857
859
861
863
864
866
868
869
870
871
875
876
878
880
881
882
883
886
887
888
889
892
893
894
895
896
897
899
900
902 9. Security Considerations
904 The metadata information sent from SRC to SRS MAY reveal sensitive
905 information about different participants in a session. For this
906 reason, it is RECOMMENDED that a SRC use a strong means for
907 authentication and metadata information protection and that it apply
908 comprehensive authorization rules when using the metadata format
909 defined in this document. The following sections will discuss each
910 of these aspects in more detail.
912 9.1. Connection Security
914 It is RECOMMENDED that a SRC authenticate SRS using the normal SIP
915 authentication mechanisms, such as Digest as defined in Section 22 of
916 [RFC3261]. The mechanism used for conveying the metadata information
917 MUST ensure integrity and SHOULD ensure confidentially of the
918 information. In order to achieve these, an end-to-end SIP encryption
919 mechanism, such as S/MIME described in [RFC3261], SHOULD be used.
921 If a strong end-to-end security means (such as above) is not
922 available, it is RECOMMENDED that a SRC use mutual hop-by-hop
923 Transport Layer Security (TLS) authentication and encryption
924 mechanisms described in "SIPS URI Scheme" and "Interdomain Requests"
925 of [RFC3261].
927 10. IANA Considerations
929 This specification registers a new XML namespace, and a new XML
930 schema.
932 10.1. SIP recording metadata Schema Registration
934 URI: urn:ietf:params:xml:ns:recording
936 Registrant Contact: IETF SIPREC working group, Ram mohan
937 R(rmohanr@cisco.com)
939 XML: the XML schema to be registered is contained in Section 6.
941 Its first line is and its last
942 line is
944 11. Acknowledgement
946 We wish to thank John Elwell(Siemens-Enterprise), Henry Lum(Alcatel-
947 Lucent), Leon Portman(Nice), De Villers, Andrew Hutton(Siemens-
948 Enterprise), Deepanshu Gautam(Huawei), Charles Eckel(Cisco), Muthu
949 Arul(Cisco), Michael Benenson(Cisco), Hadriel Kaplan (ACME), Brian
950 Rosen(Neustar), Scott Orton(Broadsoft) for their valuable comments
951 and inputs.
953 We wish to thank Joe Hildebrand(Cisco), Peter Saint-Andre(Cisco) for
954 the valuable XML related guidance.
956 12. Appendix A: Metadata Model Object Instances
958 This section describes the metadata model object instances for
959 different use cases of SIPREC. For the sake of simplicity as the
960 media streams sent by each of the participants is received by every
961 other participant in these use cases, it is NOT shown in the object
962 instance diagrams below. Also for the sake of ease not all
963 attributes of each block are shown in these instance diagrams.
965 12.1. Use case 1: Basic Call
967 Basic call between two Participants A and B. In this use case each
968 participant sends one Media Stream. For the sake of simplicity
969 "receives" lines are not shown in this instance diagram. Media
970 Streams sent by each participant is received all other participants
971 of that CS.
973 +-------------------------------+
974 | Recording Session (RS) |
975 +-------------------------------+
976 |
977 |
978 |
979 +----------------+
980 | Communication |
981 | Session (CS) |
982 +----------------+-----------------------+
983 | Start Time | |
984 +----------------+ |
985 | |
986 |-------------------+ |
987 | | |
988 +---------------+ +---------------+ |
989 | ParticipantA | | ParticipantB | |
990 | | | | |
991 +---------------+ +---------------+ |
992 | | |
993 sends | | sends |
994 | | |
995 +---------------+ +---------------+ |
996 |Media Stream A1| |Media Stream B1| |
997 +---------------+ +---------------+ |
998 |MediaStream Ref| |MediaStream Ref| |
999 |Start Time | |Start Time | |
1000 +---------------+ +---------------+ |
1001 | | |
1002 +-----------------------------------+
1004 12.2. Use case 2: Basic Call with hold/resume
1006 Basic call between two Participants A and B and with Participant A or
1007 B doing a Hold/Resume. In this use case each participant sends one
1008 Media Stream. After Hold/Resume the properties of Media can change.
1009 For the sake of simplicity "receives" lines are not shown in this
1010 instance diagram. Media Streams sent by each participant is received
1011 all other participants of that CS.
1013 +-------------------------------+
1014 | Recording Session (RS) |
1015 +-------------------------------+
1016 | |
1017 | |
1018 | |
1019 | +-------------------------------+
1020 | | Communication Session (CS) |
1021 | +-----------| Group(CSG) |
1022 | | +-------------------------------+
1023 | | | Unique-id1 |
1024 | | +-------------------------------+
1025 | |
1026 | |
1027 | |
1028 +----------------+
1029 | Communication |
1030 +-| Session (CS) |----------------------------------------------+
1031 | +----------------+ |
1032 | | | |
1033 | +----------------+ |
1034 | | |
1035 | |-------------------+ |
1036 | | | |
1037 | +---------------+ +---------------+ |
1038 | | ParticipantA | | ParticipantB |-----------+ |
1039 | | |--+ | | | |
1040 | +---------------+ | +---------------+ |sends(After |
1041 | | | | | | | Resume) |
1042 | | | | | | +--------------+ |
1043 | sends | | +--+ | sends | |MediaStream B3| |
1044 | | -----+ | | +-----+ +--------------+ |
1045 | +---------------+ | | +---------------+ | |MediaStreamRef|-|
1046 | |Media Stream A1| | | |Media Stream B1| | | Start Time | |
1047 | +---------------+ | | +---------------+ | | | |
1048 +-|MediaStreamref | | | |MediaStreamRef | | +--------------+ |
1049 |Start Time | | | |Start Time |-|-------------------|
1050 +---------------+ | | +---------------+ | |
1051 | | | |
1052 +------------+ |sends |sends (hold) |
1053 | sends |(Resume) | |
1054 | (hold) +-------+ +-------+ |
1055 | | | |
1056 +---------------+ +---------------+ +--------------+ |
1057 |Media Stream A2| |Media Stream A3| |MediaStream B2| |
1058 +---------------+ +---------------+ | | |
1059 |MediaStreamref | |MediaStreamRef | +--------------+ |
1060 |End Time | |Start Time | |Codec Params | |
1061 +---------------+ +---------------+ |end Time | |
1062 | | | | |
1063 | | +--------------+ |
1064 | | | |
1065 +------------------------------------------------------+
1067 12.3. Use case 3: Basic call with Transfer
1069 Basic call between two Participants A and B and with Participant A
1070 transfer(consult transfer) to Participant C. In this use case each
1071 participant sends one Media Stream. After transfer the properties of
1072 Participant A Media can change. For the sake of simplicity
1073 "receives" lines are not shown in this instance diagram. Media
1074 Streams sent by each participant is received all other participants
1075 of that CS.
1077 +-------------------------------+
1078 | Recording Session (RS) |-------+
1079 +-------------------------------+ |
1080 | |
1081 | |
1082 | |
1083 +-------------------------------+ |
1084 | Communication Session (CS) | |
1085 | Group(CSG) | |
1086 +-------------------------------+ |
1087 | Unique-id1 | |
1088 +-------------------------------+ |
1089 | |
1090 |----------------------------+
1091 |
1092 |-----------------+
1093 | |
1094 +----------------+ +----------------+
1095 | Communication | | Communication |
1096 | Session (CS)1 | | Session (CS)2 |
1097 +----------------+ +----------------+-----------+
1098 | | | | |
1099 +----------------+ +----------------+ |
1100 | |
1101 |-------------------+ |
1102 | | | |
1103 +---------------+ | +---------------+ |
1104 | ParticipantA | | | ParticipantB | |
1105 | | | | | |
1106 +---------------+ | +---------------+ |
1107 | | | |
1108 sends | | | sends |
1109 | | | |
1110 +---------------+ | +---------------+ |
1111 |Media Stream A1| | |Media Stream B1| |
1112 +---------------+ | +---------------+ |
1113 | | | | | |
1114 | | | | Media Stream | |
1115 | Media Stream |---+---| Ref | |
1116 | Ref | | | |
1117 +---------------+ +---------------+ |
1118 |
1119 |
1120 +----------------------------|
1121 | |
1122 +--------------------------------+ |
1123 | | |
1124 +---------------+ +---------------+ |
1125 | Participant A | | Participant C | |
1126 | (same) | | | |
1127 +---------------+ +---------------+ |
1128 | | |
1129 | sends (After transfer) | sends |
1130 +----------------+ +----------------+|
1131 | Media Stream A2| | Media Stream C1||
1132 +----------------+ +----------------+|
1133 | Media StreamRef| | Media StreamRef||
1134 | | | ||
1135 | | | ||
1136 +----------------+ +----------------+|
1137 | | |
1138 | | |
1139 | | |
1140 +-------------------------------------------+
1142 12.4. Conference Use Cases
1144 Depending on who act as SRC and the information that an SRC has there
1145 can be several ways to model conference use cases. This section has
1146 instance diagrams for the following cases:
1148 o A CS where one of the participant (which is also SRC) is a user in
1149 a conference
1150 o A CS where one of the participant is focus ( which is also SRC)
1151 o A CS where one of the participant is user and the SRC is a
1152 different entity like B2BUA
1153 o A CS where one of the participant is focus and the SRC is a
1154 different entity like B2BUA
1156 NOTE: There MAY be other ways to model the same use cases depending
1157 on what information the SRC has.
1159 12.4.1. Case 1:
1161 This is the usecase where there is a CS with one of the participant
1162 (who is also SRC) as a user in a conference. For the sake of
1163 simplicity the receive lines for each of the participant is not
1164 shown.
1166 +---------------------------------------------------+
1167 | Communication Session |
1168 | +-------------+ +--------------+ |
1169 | | | | | |
1170 | |Participant B| | Participant A| |
1171 | | (User in |--------------| | |
1172 | | conf/SRC) | | | |
1173 | +-------------+ +--------------+ |
1174 | | | | | |
1175 +---------------------------------------------------+
1176 | | | |
1177 | | | |
1178 D E F G (Participants of Conference)
1180 Instance Diagram:
1182 +-------------------------------+
1183 | Recording Session (RS) |--+
1184 +-------------------------------+ |
1185 | |
1186 | |
1187 | |
1188 +-------------------------------+ |
1189 | Communication Session (CS) | |
1190 | Group(CSG) | |
1191 +-------------------------------+ |
1192 | Unique-id1 | |
1193 +-------------------------------+ |
1194 | |
1195 |-----------------------+
1196 |
1197 +----------------+
1198 | Communication |
1199 | Session (CS) |--+----------------+-----+
1200 +----------------+ | | |
1201 | | | | |
1202 +----------------+ | | |
1203 | | | |
1204 | | | |
1205 | | | |
1206 +---------------+ | | |
1207 | ParticipantA | | | |
1208 | | | | |
1209 +---------------+ | | |
1210 | | | |
1211 sends | | | |
1212 | | | |
1213 +---------------+ | | |
1214 |Media Stream A1| | | |
1215 +---------------+ | | |
1216 |MediaStream Ref|-----|----------------+ |
1217 | | | | |
1218 +---------------+ | | |
1219 | | |
1220 | | |
1221 +-------------+ | |
1222 | | |
1223 | | |
1224 +----------------+ | |
1225 | Participant B | | |
1226 | (in conf) | | |
1227 +----------------+ | |
1228 | | |
1229 sends | | |
1230 | | |
1231 +----------------+ | |
1232 | Media Stream B1|---------------------+ |
1233 +----------------+ sends |
1234 | MediaStream Ref| |
1235 | | +-----------------+
1236 +----------------+ |
1237 | |
1238 |sends |
1239 | |
1240 +-----------------+-------------+------------+
1241 | | | |
1242 | | | |
1243 +------------+ +------------+ +------------+ +-------------+
1244 |participantD| |ParticipantE| |ParticipantF| |Participant G|
1245 +------------+ +------------+ +------------+ +-------------+
1247 In this example we have two participants A and B who are part of a
1248 Communication Session(CS). One of the participants B is part of a
1249 conference and also acts as SRC.There can be two cases here. B can
1250 be a participant of the conference or B can be a focus. In this
1251 instance diagram Participant B is a user in a conference. The SRC
1252 (Participant B) subscribes to conference event package to get the
1253 details of other particiants. Participant B(SRC) sends the same
1254 through the metadata to SRS. In this instance diagram the Media
1255 Stream(mixed stream) sent from Participant B has media streams
1256 contributed by conference participants (D,E,F and G). For the sake
1257 of simplicity the "receives" line is not shown here. In this example
1258 the media stream sent by each participant(A or B) of CS is received
1259 by all other participant(A or B).
1261 12.4.2. Case 2:
1263 This is the usecase where there is a CS where one of the participant
1264 is focus ( which is also SRC).
1266 +---------------------------------------------------+
1267 | Communication Session |
1268 | +--------------+ +--------------+ |
1269 | | |--------------| | |
1270 | |Participant C | | Participant A| |
1271 | | (Focus in |------+ | | |
1272 | | conf and SRC)|---+ | +--------------+ |
1273 | +--------------+ | | |
1274 | | | +---------+ |
1275 | | | | |
1276 | +--------------+ | +---------------+ |
1277 | | Participant B| +---+ | Participant D | |
1278 | | | | | | |
1279 | +--------------+ | +---------------+ |
1280 | | |
1281 | +--------------+ |
1282 | |Participant E | |
1283 | | | |
1284 | +--------------+ |
1285 | |
1286 +---------------------------------------------------+
1288 Instance Diagram:
1290 +-------------------------------+
1291 | Recording Session (RS) |
1292 +-------------------------------+
1293 |-------------------------+
1294 | |
1295 | |
1296 +-------------------------------+ |
1297 | Communication Session (CS) | |
1298 | Group(CSG) | |
1299 +-------------------------------+ |
1300 | Unique-id1 | |
1301 +-------------------------------+ |
1302 | |
1303 |-------------------------+
1304 |
1305 +----------------+
1306 | Communication |
1307 | Session (CS) |----------------------+
1308 +----------------+ |
1309 | | |
1310 +----------------+ |
1311 | |
1312 |-------------------+ |
1313 | | | |
1314 +---------------+ | +---------------+ |
1315 | ParticipantA | | | ParticipantB | |
1316 | | | | | |
1317 +---------------+ | +---------------+ |
1318 | | | |
1319 sends | | | sends |
1320 | | | |
1321 +---------------+ | +---------------+ |
1322 |Media Stream A1| | |Media Stream B1| |
1323 +---------------+ | +---------------+ |
1324 |MediaStream Ref| | |MediaStream Ref| |
1325 | |---+---| | |
1326 +---------------+ +---------------+ |
1327 |
1328 +----------------------------------+
1329 | | | |
1330 | | | |
1331 +---------------+ | +---------------+ |
1332 | ParticipantD | | | ParticipantE | |
1333 | | | | | |
1334 +---------------+ | +---------------+ |
1335 | | | |
1336 sends | | | sends |
1337 | | | |
1338 +---------------+ | +---------------+ |
1339 |Media Stream D1| | |Media Stream E1| |
1340 +---------------+ | +---------------+ |
1341 |MediaStream Ref| | |MediaStream Ref| |
1342 | |---+---| | |
1343 +---------------+ +---------------+ |
1344 |
1345 |
1346 +----------+
1347 +-----------------|
1348 | |
1349 | |
1350 +----------------+ |
1351 | Participant C | |
1352 | (focus +src) | |
1353 +----------------+ |
1354 | |
1355 Sends | +-------+
1356 | |
1357 "sends" OR | |
1358 contributed +----------------+
1359 by | Media Stream C1|
1360 Participants+----------------+ "receives" by participants A,B,D,E
1361 A,B,D,E | MediaStream Ref|------------------------------------
1362 ------------| Codec Params |
1363 +----------------+
1365 In this example we have two participants A and B who are part of a
1366 Communication Session(CS). One of the participants (C) is focus of a
1367 conference and also acts as SRC. The SRC (Participant C) being the
1368 Focus of the conference has access to the details of other
1369 particiants. SRC (Participant C) sends the same through the metadata
1370 to SRS. In this instance diagram the Media Stream(mixed stream) sent
1371 by C has media streams contributed by conference participants (A, B,
1372 D and E). Participants A, B,D and E sends Media Streams A1, B1, D1
1373 and E1 respectively. The media stream sent by Participant C(Focus)
1374 is received by all other participants of CS. For the sake of
1375 simplicity the "receives" line is not shown linked to all other
1376 participants.
1378 NOTE: SRC ( Participant C) can send mixed stream or seperate streams
1379 to SRS
1381 12.4.3. Case 3:
1383 A CS where one of the participant is user and the SRC is a different
1384 entity like B2BUA. In this case the SRC may not know that one of the
1385 user is part of conference. Hence the instance diagram will not have
1386 information about the conference participants.
1388 +---------------------------------------------------+
1389 | Communication Session |
1390 | +-------------+ +------+ +--------------+ |
1391 | | | | (SRC)| | | |
1392 | |Participant B|--|B2BUA |----| Participant A| |
1393 | | (User in | +------+ | | |
1394 | | conf) | | | |
1395 | +-------------+ +--------------+ |
1396 | | | | | |
1397 +---------------------------------------------------+
1398 | | | |
1399 | | | |
1400 D E F G (Participants of Conference)
1402 12.4.4. Case 4:
1404 A CS where one of the participant is focus and the SRC is a different
1405 entity like B2BUA. In this case the participant which is focus sends
1406 "isfocus" in SIP message to SRC. The SRC subscribe to conference
1407 event package on seeing this "isfocus". SRC learns the details of
1408 other participants of conference from the conference package and send
1409 the same in metadata to SRS. The instance diagram for this use case
1410 is same as Case 1.
1412 +--------------------------------+
1413 | Conference Event Package |
1414 | |
1415 +--------------------------------+
1416 |
1417 | subscribes
1418 |
1419 +---------------------|-----------------------------+
1420 | Communication |Session |
1421 | +-------------+ +------+ +--------------+ |
1422 | | | | (SRC)| | | |
1423 | |Participant B|--|B2BUA |----| Participant A| |
1424 | | (FOCUS in | +------+ | | |
1425 | | conf) | | | |
1426 | +-------------+ +--------------+ |
1427 | | | | | |
1428 +---------------------------------------------------+
1429 | | | |
1430 | | | |
1431 D E F G (Participants of Conference)
1433 13. References
1435 13.1. Normative References
1437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1438 Requirement Levels", BCP 14, RFC 2119, March 1997.
1440 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
1442 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
1443 A., Peterson, J., Sparks, R., Handley, M., and E.
1444 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
1445 June 2002.
1447 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1448 January 2004.
1450 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
1451 Internet: Timestamps", RFC 3339, July 2002.
1453 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
1454 Description Protocol", RFC 4566, July 2006.
1456 [RFC4574] Levin, O. and G. Camarillo, "The Session Description
1457 Protocol (SDP) Label Attribute", RFC 4574, August 2006.
1459 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description
1460 Protocol (SDP) Content Attribute", RFC 4796,
1461 February 2007.
1463 13.2. Informative References
1465 [I-D.ietf-siprec-req]
1466 Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use
1467 Cases and Requirements for SIP-based Media Recording
1468 (SIPREC)", draft-ietf-siprec-req-12 (work in progress),
1469 June 2011.
1471 [I-D.ietf-siprec-architecture]
1472 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An
1473 Architecture for Media Recording using the Session
1474 Initiation Protocol", draft-ietf-siprec-architecture-02
1475 (work in progress), April 2011.
1477 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
1478 August 1999.
1480 Authors' Addresses
1482 Ram Mohan Ravindranath
1483 Cisco Systems, Inc.
1484 Cessna Business Park,
1485 Kadabeesanahalli Village, Varthur Hobli,
1486 Sarjapur-Marathahalli Outer Ring Road
1487 Bangalore, Karnataka 560103
1488 India
1490 Email: rmohanr@cisco.com
1492 Parthasarathi Ravindran
1493 Cisco Systems, Inc.
1494 Cessna Business Park,
1495 Kadabeesanahalli Village, Varthur Hobli,
1496 Sarjapur-Marathahalli Outer Ring Road
1497 Bangalore, Karnataka 560103
1498 India
1500 Email: partr@cisco.com
1502 Paul Kyzivat
1503 Cisco Systems, Inc.
1504 1414 Massachusetts Avenue
1505 Boxborough, MA 01719
1506 USA
1508 Email: pkyzivat@cisco.com