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