idnits 2.17.1 draft-ram-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 == Line 511 has weird spacing: '... |codec param...' -- The document date (December 15, 2010) is 4880 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) == Outdated reference: A later version (-12) exists of draft-ietf-siprec-req-05 == Outdated reference: A later version (-12) exists of draft-ietf-siprec-architecture-01 Summary: 0 errors (**), 0 flaws (~~), 4 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: June 18, 2011 Cisco Systems, Inc. 5 December 15, 2010 7 Session Initiation Protocol (SIP) Recording Metadata 8 draft-ram-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). 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 18, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Metadata Model . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Recording Metadata elements . . . . . . . . . . . . . . . . . 5 58 4.1. Recording Session . . . . . . . . . . . . . . . . . . . . 5 59 4.1.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1.2. Associations . . . . . . . . . . . . . . . . . . . . . 6 61 4.2. Communication Session Group . . . . . . . . . . . . . . . 6 62 4.2.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 6 63 4.2.2. Associations . . . . . . . . . . . . . . . . . . . . . 7 64 4.3. Communication Session . . . . . . . . . . . . . . . . . . 7 65 4.3.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 8 66 4.3.2. Associations . . . . . . . . . . . . . . . . . . . . . 8 67 4.4. Participant . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.4.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 9 69 4.4.2. Associations . . . . . . . . . . . . . . . . . . . . . 10 70 4.5. Media Stream . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.5.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 10 72 4.5.2. Associations . . . . . . . . . . . . . . . . . . . . . 11 73 4.6. Application Data . . . . . . . . . . . . . . . . . . . . . 11 74 5. Metadata Model Object Instances . . . . . . . . . . . . . . . 11 75 5.1. Use case 1: Basic Call . . . . . . . . . . . . . . . . . . 11 76 5.2. Use case 2: Basic Call with hold/resume . . . . . . . . . 12 77 5.3. Use case 3: Basic call with Transfer . . . . . . . . . . . 14 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 80 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 86 1. Introduction 88 Session recording is a critical requirement in many communications 89 environments such as call centers and financial trading. In some of 90 these environments, all calls must be recorded for regulatory, 91 compliance, and consumer protection reasons. Recording of a session 92 is typically performed by sending a copy of a media stream to a 93 recording device. This document focuses on the Recording metadata 94 which describes the communication session. The document describes a 95 metadata model as viewed by Session Recording Server, the 96 architecture for which is described in [I-D.ietf-siprec-architecture] 97 and the requirements for which are described in 98 [I-D.ietf-siprec-req]. 100 2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. This 105 document only uses these key words when referencing normative 106 statements in existing RFCs." 108 3. Metadata Model 110 Metadata is the data that describes the communication session. Below 111 diagram shows a model for Metadata as viewed by Session Recording 112 Server (SRS). 114 +-------------------------------+ 1 115 | Recording Session (RS) |---------------+ 116 +-------------------------------+ | 117 | 1..* | 118 | | 119 | 0..* | 120 +-------------------------------+ | 121 | Communication Session (CS) | 1 | 122 | Group |---------------| 123 +-------------------------------+ | 124 | 1 | 125 | | 126 | 1..* | 127 +-------------------------------+ | 128 | Communication Session (CS) | 1 | 129 | |---------------| 130 +-------------------------------+ | +--------------+ 131 | 0..* | | | 132 | | 0..* |Application | 133 | 2..* |-------| Data | 134 +-------------------------------+ | | | 135 | Participant | 1 | +--------------+ 136 | |---------------| 137 +-------------------------------+ | 138 | 0..* 1..* | | 139 receives | | sends | 140 | 0..* 0..* | | 141 +-------------------------------+ 1 | 142 | Media Streams |---------------+ 143 | | 144 +-------------------------------+ 146 The metadata model above MUST be used by a SRS. (NOTE: Not entirely 147 clear what sort of normative statement to make about this.) 149 The Session Recording Client (SRC) MAY initiate the Recording 150 Session. It should be noted that the Recording Session is a 151 completely independent from the Communication Session that is being 152 recorded at both the SIP dialog level and at the session level. The 153 metadata MUST be conveyed from SRC to SRS. The metadata MAY be 154 conveyed in Recording Session Dialog. 156 Note that the metadata model captures changes that occur over the 157 duration of the recording session. For example, if the call is 158 transferred from one participant to another, then the SRC SHALL 159 convey a change of participant and the properties of the new media 160 stream to the SRS. 162 Some of the data in the model may not be conveyed explicitly from the 163 SRC to the SRS, if it can be obtained contextually by the SRS. For 164 instance, the timing of changes may not explicitly conveyed from the 165 SRC to the SRC, because the mechanism (yet to be defined) which 166 conveys the metadata may implicitly provide the timing. (E.g. the 167 time a change occurred by be assumed to be the same as the time when 168 notification of the change is received by the SRS.) 170 4. Recording Metadata elements 172 This section describes the different elements and its attributes of 173 the metadata model shown above. This section also describes in brief 174 on how the different elements of metadata are associated. 176 4.1. Recording Session 178 +-------------------------------+ 179 | Recording Session (RS) | 180 +-------------------------------+ 181 | Recording RequestorID(SRC or | +-----------------+ 182 | SRS) | 1 0..* | | 183 | Reason for Recording |------------|Application Data | 184 | Recording Type (Selective | | | 185 | Persistant) | +-----------------+ 186 +-------------------------------+ 187 | 1..* 188 | 189 | 0..* 190 Communication Session Group(CS Group) 192 A Recording Session element represents one instance of a Recording 193 Session. 195 4.1.1. Attributes 197 A Recording Session element MAY have attributes like: 198 o Recording requestor ID(which could be SRS or SRC). 199 o Reason for recording - The reason for recording MAY be a policy(in 200 a financial trading floor or Call centre) or to monitor a agent, 201 or for quality purposes etc. 203 o Recording type - This attribute indicates whether the recording 204 session is selective or persistent. 206 4.1.2. Associations 208 One instance of Recording Session SHALL have: 210 o Zero or more instances of Communication Session Group.This is to 211 accommodate persistent recording cases. 212 o Each CS Group MUST be associated with one or more Recording 213 Sessions [ setup potentially by multiple SRCs] 215 NOTE: Need to check if the current cardinality between CS Group and 216 RS is sufficient for all use cases of SIPREC 218 4.2. Communication Session Group 220 Recording Session (RS) 221 | 1..* 222 | 223 | 0..* 224 +-------------------------------+ 225 | Communication Session | 226 | Group | 227 +-------------------------------+ 228 | Unique-ID | +----------------+ 229 | | 1 0..* | | 230 | |-----------|Application Data| 231 | | | | 232 +-------------------------------+ +----------------+ 233 | 1 234 | 235 | 1..* 236 Communication Session (CS) 238 A Communication Session Group provides association or linking of 239 Communication Sessions. 241 4.2.1. Attributes 243 A CS Group MUST have a Unique-ID attribute. SRC MUST ensure the 244 uniqueness of Unique-ID in case multiple SRC interacts with the same 245 SRS. The mechanism by which SRC creates this unique-ID and ensures 246 its uniqueness is outside the scope of SIPREC. 248 NOTE: Need more clarity/use cases on how the unique-ID SHALL be used 250 4.2.2. Associations 252 A communication Session Group SHALL be associated with RS and CS in 253 the following manner: 255 o There can be one or more Recording Session elements per 256 Communication Session Group. 257 o Each Communication Session Group MUST be associated with one or 258 more RS [ setup potentially by multiple SRCs] 259 o There MAY be one or more Communication Sessions per CS Group [e.g. 260 Consult Transfer] 261 o Each CS MUST be associated to one CS-Group 263 NOTE: The current metadata model allows each CS to be associated to 264 only one CS-Group block in the model. It does not allow a CS to be 265 associated with multiple CS-Groups concurrently. Do we want to allow 266 CSs to be concurrently associated (different views) with multiple CS- 267 Groups in the model ? 269 For e.g. from the perspective of customer or from the perspective of 270 Agent or supervisor. I can guess that storing these different 271 perspectives may be useful at SRS as there may be applications that 272 may query for one view(a customer's view or agents view or 273 supervisors view).If we need to accommodate this kind of thing in the 274 model, a CS has to be associated with multiple CS-Groups 275 simultaneously. The tricky question here though is how the SRC knows 276 these different perspectives(views) and assign unique IDS for each 277 grouping. 279 4.3. Communication Session 281 Communication Session Group(CS Group) 282 | 1 283 | 284 | 1..* 285 +-------------------------------+ 286 | Communication Session | 287 | (CS) | 288 +-------------------------------+ 289 | Call Termination Reason | +-----------------+ 290 | Retention | 1 0..* | | 291 | Force Deletion |------------|Application Data | 292 | | | | 293 +-------------------------------+ +-----------------+ 294 | 0..* 295 | 296 | 2..* 298 Participant 300 A Communication Session block/element in the metadata model 301 represents Communication Session and its properties needed as seen by 302 SRC. 304 4.3.1. Attributes 306 A communication Session block SHALL have the following attributes: 308 o Call Termination Reason - This represents the reason why a CS was 309 terminated. This MAY be derived from SIP Reason header of CS 310 o Retention - This attributes represent the value/duration for which 311 Media streams of the CS needs to be retained 312 o Force Deletion - This attribute can be sent to SRS by SRC to 313 delete the Media Streams of that CS immediately 315 NOTE: Depending on where the SRC is located the direction may have 316 some significance. For example a B2BUA acting as SRC and located at 317 a edge of an Enterprise may know whether is incoming/outgoing. 318 Otherwise in a lot of 3PCC situations,the UA is the recipient of the 319 INVITE request, even if the user requested the call. Also, if the 320 call is established by transfer from somebody else, it might always 321 be incoming from the perspective of the localuser but might also be 322 incoming from the perspective of the remote user. So it may be 323 tricky to find the direction in all cases. 325 NOTE: Discussions are needed to conclude on some of the attributes 326 and any other attributes ( like Direction, Initiator e.t.c) 328 4.3.2. Associations 330 A Communication Session SHALL be associated to CS-Group and 331 Participant. Cardinalities between CS and Participant allows: 333 o CS to have atleast two or more participants 334 o Participant may be associated with zero or more CS's (It is 335 possible, though unlikely, that there are participants who are not 336 part of any CS). An example of such a case is participants in a 337 premixed media stream. The SRC may have knowledge of such 338 Participants, yet not have any signaling relationship with them. 339 This might arise if one participant in CS is a conf focus. 340 Another use case is if one UA in CS works in 3pcc mode to acquire 341 an MoH media stream, this might be reflected as unique source for 342 media stream without having a reported signaling relationship to 343 it. 345 o The model also allows participants in CS that are not participants 346 in the media. An example is the identity of a 3pcc controller 347 that has initiated a CS to two or more participants of the CS. 348 Another example is the identity of a conference focus. Of course 349 a focus is probably in the media, but since it may only be there 350 as a mixer, it may not report itself as a participant in any of 351 the media streams. 353 4.4. Participant 355 Communication Session (CS) 356 | 0..* 357 | 358 | 2..* 359 +-------------------------------+ 360 | Participant | 361 | | 362 +-------------------------------+ 363 | AoR | +-----------------+ 364 | Name | 1 0..* | | 365 | Participant Type |------------|Application Data | 366 | | | | 367 +-------------------------------+ +-----------------+ 368 | 0..* 1..*| 369 receives| |sends 370 | 0..* 0..*| 371 Media Stream 373 A Participant represents one contributor of media. 375 4.4.1. Attributes 377 Participant has attributes like: 379 o AoR - AoR MAY be SIP/SIPS/TEL URI 380 o Name - This attribute represents Participant name or DN number ( 381 in case it is known) 382 o Participant Type - This attribute can have values as "internal" or 383 "external" or "don't know" (in cases where it is not possible to 384 determine). 386 NOTE: Need to conclude on what other attributes [ like End point 387 information(IP, Port e.t.c), Device Type, Participant Role e.t.c] are 388 needed to be represented in the model 390 4.4.2. Associations 392 Cardinalities between participant and Media Stream allows: 394 o Participant to receives zero or more media streams 395 o Participant to send zero or more media streams. (Same participant 396 provides multiple streams e.g. audio and video) 397 o Media stream to be received by zero or more participants. Its 398 possible, though perhaps unlikely, that a stream is generated but 399 sent only to the SRC and SRS, not to any participant. E.g. In 400 conferencing where all participants are on hold and the SRC is 401 collocated with the focus. Also a media stream may be received by 402 multiple participants (e.g. Whisper calls, side conversations). 403 o Media stream to be sent by one or more participants (pre-mixed 404 streams). 406 NOTE: Example of a case where a participant may receive Zero or more 407 streams - a Supervisor may have side conversation with Agent, while 408 Agent converses with customer. 410 4.5. Media Stream 412 Participant 413 | 0..* 1..*| 414 receives| |sends 415 | 0..* 0..*| 416 +-------------------------------+ 417 | Media Stream | 418 | | 419 +-------------------------------+ 420 | Start Time | +-----------------+ 421 | End Time | 1 0..* | | 422 | Codec |------------|Application Data | 423 | Media Stream Reference | | | 424 +-------------------------------+ +-----------------+ 426 A Media Stream block shall have properties of media as seen by SRC 427 and sent to SRS. Different instances of Media Stream block would be 428 created whenever there is a change in media (e.g. dir change like 429 pause/resume and/or codec change and/or participant change.). 431 4.5.1. Attributes 433 A Media Stream block SHALL have the following attributes: 435 o Start Time - Represents Media Start time at SRC. 436 o End Time - Represents Media End time at SRC. 437 o Codec - represents codec parameters 438 o Media Stream Reference - In implementations this can reference to 439 m-line 441 OPEN ITEM: Is it required to model media streams that are not 442 recorded[ e.g SRC offered certain media types but SRS choose to 443 accept only subset of them] ? 445 OPEN ITEM: How do we represent the Information that the SRC has 446 regarding privacy/access of information(media) being recorded as an 447 attribute in Media Stream OR can this be app data ? 449 OPEN ITEM: How do we represent hold/resume from SRC to SRS and pause/ 450 resume from SRS to SRC in the model? 452 4.5.2. Associations 454 A Media Stream SHALL be associated with Participant the details of 455 which are described in the Participant block section. 457 4.6. Application Data 459 A recording metadata object MAY have a opaque application data. This 460 opaque data is intended to be used by vendor specific applications on 461 SRS. 463 5. Metadata Model Object Instances 465 This section describes the metadata model object instances for 466 different use cases of SIPREC. For the sake of simplicity as the 467 media streams sent by each of the participants is received by every 468 other participant in these use cases, it is NOT shown in the object 469 instance diagram. 471 5.1. Use case 1: Basic Call 473 Basic call between two Participants A and B. In this use case each 474 participant sends one Media Stream. 476 +-------------------------------+ 477 | Recording Session (RS) | 478 +-------------------------------+ 479 | 480 | 481 | 482 +-------------------------------+ 483 | Communication Session (CS) | 484 | Group(CSG) | 485 +-------------------------------+ 486 | Unique-id1 | 487 +-------------------------------+ 488 | 489 | 490 | 491 +----------------+ 492 | Communication | 493 | Session (CS) | 494 +----------------+ 495 | | 496 +----------------+ 497 | 498 |-------------------+ 499 | | 500 +---------------+ +---------------+ 501 | ParticipantA | | ParticipantB | 502 | | | | 503 +---------------+ +---------------+ 504 | | 505 sends | | sends 506 | | 507 +---------------+ +---------------+ 508 |Media Stream A1| |Media Stream B1| 509 +---------------+ +---------------+ 510 |MediaStream Ref| |MediaStream Ref| 511 |codec params | |codec params | 512 +---------------+ +---------------+ 514 5.2. Use case 2: Basic Call with hold/resume 516 Basic call between two Participants A and B and with Participant A or 517 B doing a Hold/Resume. In this use case each participant sends one 518 Media Stream. After Hold/Resume the properties of Media MAY change. 520 +-------------------------------+ 521 | Recording Session (RS) | 522 +-------------------------------+ 523 | 524 | 525 | 526 +-------------------------------+ 527 | Communication Session (CS) | 528 | Group(CSG) | 529 +-------------------------------+ 530 | Unique-id1 | 531 +-------------------------------+ 532 | 533 | 534 | 535 +----------------+ 536 | Communication | 537 | Session (CS) | 538 +----------------+ 539 | | 540 +----------------+ 541 | 542 |-------------------+ 543 | | 544 +---------------+ +---------------+ 545 | ParticipantA | | ParticipantB |-----------+ 546 | |--+ | | | 547 +---------------+ | +---------------+ | sends(After 548 | | | | | | Resume) 549 | | | | | +----------------+ 550 sends | | +--+ | sends | | Media Stream B3| 551 | -----+ | | +-----+ +----------------+ 552 +---------------+ | | +---------------+ | | MediaStream Ref| 553 |Media Stream A1| | | |Media Stream B1| | | Codec Params | 554 +---------------+ | | +---------------+ | | | 555 |MediaStreamref | | | |MediaStreamRef | | +----------------+ 556 |codec params | | | |codec params | | 557 +---------------+ | | +---------------+ | 558 | | | 559 +------------+ |sends |sends (hold) 560 | sends |(Resume) | 561 | (hold) +-------+ +-------+ 562 | | | 563 +---------------+ +---------------+ +----------------+ 564 |Media Stream A2| |Media Stream A3| | Media Stream B2| 565 +---------------+ +---------------+ | | 566 |MediaStreamref | |MediaStreamRef | +----------------+ 567 |codec params | |codec params | | Codec Params | 568 +---------------+ +---------------+ | MediaStream Ref| 569 | | 570 +----------------+ 572 NOTE: Need discssions on how to represent Hold/Resume from SRC to SRS 573 and Pause/Resume from SRS to SRC. 575 5.3. Use case 3: Basic call with Transfer 577 Basic call between two Participants A and B and with Participant A 578 transfer(consult transfer) to Participant C. In this use case each 579 participant sends one Media Stream. After transfer the properties of 580 Participant A Media MAY change. 582 +-------------------------------+ 583 | Recording Session (RS) | 584 +-------------------------------+ 585 | 586 | 587 | 588 +-------------------------------+ 589 | Communication Session (CS) | 590 | Group(CSG) | 591 +-------------------------------+ 592 | Unique-id1 | 593 +-------------------------------+ 594 | 595 |----------------- 596 | | 597 +----------------+ +----------------+ 598 | Communication | | Communication | 599 | Session (CS)1 | | Session (CS)2 | 600 +----------------+ +----------------+-----------+ 601 | | | | | 602 +----------------+ +----------------+ | 603 | | 604 |-------------------+ | 605 | | | 606 +---------------+ +---------------+ | 607 | ParticipantA | | ParticipantB | | 608 | | | | | 609 +---------------+ +---------------+ | 610 | | | 611 sends | | sends | 612 | | | 613 +---------------+ +---------------+ | 614 |Media Stream A1| |Media Stream B1| | 615 +---------------+ +---------------+ | 616 | | | | | 617 |codec params | | Media Stream | | 618 | Media Stream | | Ref | | 619 | Ref | |codec params | | 620 +---------------+ +---------------+ | 621 | 622 | 623 +----------------------------+ 624 | 625 +--------------------------------+ 626 | | 627 +---------------+ +---------------+ 628 | Participant A | | Participant C | 629 | | | | 630 +---------------+ +---------------+ 631 | | 632 | sends (After transfer) | sends 633 +----------------+ +----------------+ 634 | Media Stream A2| | Media Stream C1| 635 +----------------+ +----------------+ 636 | Media StreamRef| | Media StreamRef| 637 | Codec params | | Codecparams | 638 | | | | 639 +----------------+ +----------------+ 641 6. Security Considerations 643 The Recording Session is fundamentally a standard SIP dialog 644 [RFC3261] and media session and therefore make use of existing SIP 645 security mechanisms for securing the Recording Session and Media 646 Recording Metadata. 648 7. IANA Considerations 650 Not Applicable 652 8. Acknowledgement 654 We wish to thank John Elwell, Henry Lum, Leon Portman, De Villers for 655 the valuable comments. 657 9. References 659 9.1. Normative References 661 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 662 Requirement Levels", BCP 14, RFC 2119, March 1997. 664 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 665 A., Peterson, J., Sparks, R., Handley, M., and E. 666 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 667 June 2002. 669 9.2. Informative References 671 [I-D.ietf-siprec-req] 672 Rehor, K., Portman, L., Hutton, A., and R. Jain, 673 "Requirements for SIP-based Media Recording (SIPREC)", 674 draft-ietf-siprec-req-05 (work in progress), 675 December 2010. 677 [I-D.ietf-siprec-architecture] 678 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An 679 Architecture for Media Recording using the Session 680 Initiation Protocol", draft-ietf-siprec-architecture-01 681 (work in progress), October 2010. 683 Authors' Addresses 685 Ram Mohan R 686 Cisco Systems, Inc. 687 Cessna Business Park, 688 Kadabeesanahalli Village, Varthur Hobli, 689 Sarjapur-Marathahalli Outer Ring Road 690 Bangalore, Karnataka 560103 691 India 693 Email: rmohanr@cisco.com 694 Parthasarathi R 695 Cisco Systems, Inc. 696 Cessna Business Park, 697 Kadabeesanahalli Village, Varthur Hobli, 698 Sarjapur-Marathahalli Outer Ring Road 699 Bangalore, Karnataka 560103 700 India 702 Email: partr@cisco.com 704 P. Kyzivat 705 Cisco Systems, Inc. 706 1414 Massachusetts Avenue 707 Boxborough, MA 01719 708 USA 710 Email: pkyzivat@cisco.com