One document matched: draft-ietf-siprec-callflows-06.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629xslt/rfc2629.dtd" [
<!ENTITY rfc3667 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3667.xml'>
]>
<?rfc toc='yes'?>
<?rfc tocdepth='4'?>
<?rfc compact="yes"?>
<!--rfc category="info" ipr="full3978"-->
<rfc category="info" docName="draft-ietf-siprec-callflows-06" ipr='trust200902'>
<front>
<title abbrev="SIP Recording Callflows">Session Initiation Protocol (SIP) Recording Call Flows</title>
<author initials="Ram Mohan" surname="Ravindranath" fullname="Ram Mohan Ravindranath">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park,</street>
<street>Kadabeesanahalli Village, Varthur Hobli,</street>
<street>Sarjapur-Marathahalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>rmohanr@cisco.com</email>
</address>
</author>
<author initials="Parthasarathi" surname="Ravindran" fullname="Parthasarathi Ravindran">
<organization>Nokia Networks</organization>
<address>
<postal>
<street/>
<city>Bangalore</city>
<region>Karnataka</region>
<country>India</country>
</postal>
<email>partha@parthasarathi.co.in</email>
</address>
</author>
<author initials="Paul" surname="Kyzivat" fullname="Paul Kyzivat">
<organization>Huawei</organization>
<address>
<postal>
<street/>
<region>Hudson, MA</region>
<country>USA</country>
</postal>
<email>pkyzivat@alum.mit.edu</email>
</address>
</author>
<date year="2016" />
<area>Transport</area>
<workgroup>SIPREC</workgroup>
<abstract>
<t>
Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document lists call flows that has snapshot of metadata sent from a Session Recording Client to Session Recording Server. This is purely an informational document that is written to support the model defined in the metadata draft.
</t>
</abstract>
</front>
<middle>
<section title="Overview">
<t><xref target="I-D.ietf-siprec-metadata"/> document focuses on the recording metadata which describes the communication session(CS). This document lists few examples and shows the snapshots of metadata sent from a Session Recording Client (SRC) to Session Recording Server (SRS). For the sake of simplicity the entire Session Initiation Protocol (SIP) <xref target="RFC3261"/> messages are not shown at various points, instead only snippets of the SIP and Session Description Protocol (SDP)<xref target="RFC4566"/> messages and the XML snapshot of metadata is shown.</t>
</section>
<section title="Terminology" anchor="sec-term">
<t>The terms using in this document are defined in <xref target="I-D.ietf-siprec-metadata"/> and <xref target="RFC6341"/>. No new definitions are introduced in this document.</t>
</section>
<section title="Metadata XML Instances">
<t>The following sub-sections has examples showing the metadata snapshot sent from SRC to SRS. In all these use-cases, the SRC is a B2BUA.</t>
<section title="Sample Call flow">
<t>
The following is a sample call flow that shows the SRC establishing a Recording Session(RS) towards the SRS. The SRC in this example could be part of any one of the architectures described in section 3 of <xref target="RFC7245"/>. </t>
<t><figure>
<artwork>
<![CDATA[
SRC SRS
| |
|(1) INVITE (metadata snapshot) F1 |
|---------------------------------------------------->|
| 200 OK |
|<----------------------------------------------------|
|(3) ACK |
|---------------------------------------------------->|
|(4) RTP |
|====================================================>|
|====================================================>|
|====================================================>|
|====================================================>|
|(5) UPDATE/RE-INVITE (metadata update 1) F2 |
|---------------------------------------------------->|
| 200 OK |
|<----------------------------------------------------|
| ................................................... |
| ................................................... |
| |
|====================================================>|
|====================================================>|
|(7) UPDATE/RE-INVITE (metadata update n-1) Fn-1 |
|---------------------------------------------------->|
| 200 OK |
|<----------------------------------------------------|
]]>
</artwork></figure></t>
<t>For the sake of simplicity, ACKs to RE-INVITES and BYEs are not shown. The subsequent sections describes the snapshot of metadata sent from SRC to SRS for each of the above transactions (F1 ... Fn-1). There may be multiple UPDATES/RE-INVITES mid call to indicates snapshots of different CS changes. Depending on the architecture described in section 3 of <xref target="RFC7245"/> an SRC may be a endpoint or B2BUA or as part of MEDIACTRL or Conference Focus. The subsequent sections in this document tries to list some example metadata snapshots for three major categories.</t>
<t>
<list style='symbols'>
<t>SRC recording streams unmixed to SRS. This includes cases where SRC is SIP UA or B2BUA.</t>
<t>SRC recording mixed streams to SRS. This includes cases where SRC is part of SIP conference model explained in <xref target="RFC4353"/>.</t>
<t> SRC having a persistent RS with SRS. </t>
<t>Special flows like Turrent flows. </t>
</list>
</t>
<t> Note that only those examples for which metadata changes are listed in each category. For some of the call flows the snapshots may be same (like in case of endpoint or B2BUA acting as SRC) and the same is mentioned in the text preceding the example.</t>
</section>
<section title="Call Scenarios with SRC recording streams with out mixing">
<t>This section describes few example flows where SRC can be a SIP-UA or B2BUA as described in section 3 of <xref target="RFC7245"/>. The SRS here can be a SIP-UA or an entity part of MEDIACTRL architecture described in <xref target="RFC6230"/>.</t>
<section title="Example 1: Basic Call">
<t> Basic call between two participants Alice and Bob who are part of the same CS. In this use case each participant sends two media streams(audio and video). Media streams sent by each participant are received by the other participant in this use-case. In this example the SRC is a B2BUA in the path between Alice and Bob as described in section 3.1.1 of <xref target="RFC7245"/>. Below is the initial snapshot sent by SRC in the INVITE to SRS. This snapshot has the complete metadata. For the sake of simplicity only snippets of SIP/SDP are shown. The SRCs records the streams of each participant to SRS with out mixing in this example.</t>
<t><figure><artwork>
<![CDATA[
F1 INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49174 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51372 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49176 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>complete</datamode>
<group group_id="7+OTCyoxTmqmqyA/1weDAg==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
<!-- Standardized extension -->
<call-center xmlns='urn:ietf:params:xml:ns:callcenter'>
<supervisor>sip:alice@atlanta.com</supervisor>
</call-center>
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</group>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<sipSessionID>ab30317f1a784dc48ff824d0d3715d86;
remote=47755a9de7794ba387653f2099600ef2</sipSessionID>
<group-ref>7+OTCyoxTmqmqyA/1weDAg==
</group-ref>
<!-- Standardized extension -->
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</session>
<participant
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<nameID aor="sip:alice@atlanta.com">
<name xml:lang="it">Alice</name>
</nameID>
<!-- Standardized extension -->
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</participant>
<participant
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor="sip:bob@biloxy.com">
<name xml:lang="it">Bob</name>
</nameID>
<!-- Standardized extension -->
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</participant>
<stream stream_id="UAAMm5GRQKSCMVvLyl4rFw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>97</label>
</stream>
<stream stream_id="8zc6e0lYTlWIINA6GR+3ag=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>98</label>
</stream>
<stream stream_id="EiXGlc+4TruqqoDaNE76ag=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>99</label>
</stream>
<sessionrecordingassoc session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</sessionrecordingassoc>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
</recording>
]]>
</artwork></figure></t>
</section>
<section title="Example 2: Hold/resume">
<t> A call between two participants Alice and Bob is established and a RS is created for recording as in example1. One of the participants Bob puts Alice hold and then resumes as part of the same CS. The send and recv XML elements of a participantstreamassoc XML element is used to indicate whether a participant is contributing to a media stream or not. SRC sends a snapshot with only the changed XML elements. </t>
<t>During hold</t>
<t><figure><artwork>
<![CDATA[
F2 mid call RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49174 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51372 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49176 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
</participantstreamassoc>
</recording>
]]>
</artwork></figure></t>
<t>In the above snippet, Alice with participant_id srfBElmCRp2QB23b7Mpk0w== only receives media streams and does not send any media. The same is indicated by the absence of send XML element. Bob(participant_id zSfPoSvdSDCmU3A3TRDxAw==) on the other hand would be sending media but does not receive any media from Alice and so recv XML element is absent in this instance. </t>
<t>During resume</t>
<t>The snapshot now has send and recv XML elements for both Alice and Bob indicating that both are receiving and sending media.</t>
<t><figure><artwork>
<![CDATA[
F3 mid call RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49174 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51372 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49176 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc>
</recording>
]]>
</artwork></figure></t>
</section>
<section title="Example 3:Call Transfer (RE-INVITE and REFER based)">
<t> Basic call between two Participants Alice and Bob is connected and SRC(B2BUA acting as SRC as per section 3.1.1 of <xref target="RFC7245"/>) has sent a snapshot as described in example 1. Transfer is initiated by one of the participants(Alice). After the transfer is completed, SRC sends a snapshot of the participant changes to SRS. In this transfer scenario, Alice drops out after transfer is completed and Bob and Carol gets connected and recording of media between Bob and Carol is done by SRC. There are two flows that can happen here as described below. </t>
<t>Transfer with in the same session - (.e.g. RE-INVITE based transfer). Participant Alice drops out and Carol is added to the same session. No change to session/group element. A participantsessassoc element indicating that Alice has disassociated from the CS will be present in the snapshot. A new participant XML element representing Carol with mapping to the same RS SDP stream used for mapping earlier Alice's stream is sent in the snapshot. A new sipSessionID XML element that has UUID tuples which corresponds to Bob and Carol is sent in the snapshot from SRC to SRS. Note that one half of the session ID that corresponds to Bob remains same.</t>
<t><figure><artwork>
<![CDATA[
mid call RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49180 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49182 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51374 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49178 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<sipSessionID>3363127f0d084c10876dddd4f8e5eeb9
;remote=2272bb7e70fe41dba0025ae9a26d54cf</sipSessionID>
</session>
<participant
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<nameIDaor="sip:carol@example.com">
<name xml:lang="it">Carol</name>
</nameID>
</participant>
<participantsessionassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2013-12-16T23:41:07Z</associate-time>
</participantsession>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2013-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>60JAJm9UTvik0Ltlih/Gzw==</recv>
<recv>AcR5FUd3Edi8cACQJy/3JQ==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<send>60JAJm9UTvik0Ltlih/Gzw==</send>
<send>AcR5FUd3Edi8cACQJy/3JQ==</send>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
<associate-time>2013-12-16T23:42:07Z</associate-time>
</participantstreamassoc>
</recording>
]]>
</artwork></figure></t>
<t>Transfer with new session - (.e.g. REFER based transfer). In this case a new session (CS) is created and shall be part of same CS-group (done by SRC).</t>
<t>SRC first sends an optional snapshot indicating disassociation of participant from the old CS. Please note this is a optional message. An SRC may choose to just send a INVITE with a new session element to implicitly indicate that the participants are now part of a different CS with out sending disassociation from the old CS. The SRC in this example uses the same RS. In case the SRC wishes to use a new RS, it will tear down the current RS using normal SIP procedures (BYE) with metadata as in example 4.</t>
<t><figure><artwork>
<![CDATA[
mid call RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49180 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49182 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51374 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49178 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>Partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<stop-time>2010-12-16T23:41:07Z</stop-time>
</session>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disasociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
</recording>
]]>
</artwork></figure></t>
<t> In the above snapshot, the participantsessionassoc element is optional as indicating session XML element with a stop-time implicitly means that all the participants associated with that session have been disassociated.</t>
<t>SRC sends another snapshot to indicate the participant change (due to REFER) and new session information after transfer. In this example it is assumed SRC uses the same RS to continue recording the call. The sipSessionID XML element in metadata snapshot now indicates Alice and Carol in the (local, remote) uuid pair.</t>
<t><figure><artwork>
<![CDATA[
mid call RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49180 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49182 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51374 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49178 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>complete</datamode>
<session session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<start-time>2010-12-16T23:41:07Z</start-time>
<sipSessionID>3363127f0d084c10876dddd4f8e5eeb9
;remote=2272bb7e70fe41dba0025ae9a26d54cf</sipSessionID>
</session>
<participant
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor="sip:Bob@biloxy.com"/>
</participant>
<participant
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<nameID aor="sip:carol@example.com"/>
</participant>
<stream stream_id="60JAJm9UTvik0Ltlih/Gzw=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<label>96</label>
</stream>
<stream stream_id="AcR5FUd3Edi8cACQJy/3JQ=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<label>97</label>
</stream>
<stream stream_id="8zc6e0lYTlWIINA6GR+3ag=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<label>98</label>
</stream>
<stream stream_id="EiXGlc+4TruqqoDaNE76ag=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<label>99</label>
</stream>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<associate-time>2010-12-16T23:32:03Z</associate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>60JAJm9UTvik0Ltlih/Gzw==</recv>
<recv>AcR5FUd3Edi8cACQJy/3JQ==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<send>60JAJm9UTvik0Ltlih/Gzw==</send>
<send>AcR5FUd3Edi8cACQJy/3JQ==</send>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc>
</recording>
]]>
</artwork></figure></t>
</section>
<section title="Example 4: Call disconnect">
<t>This example shows a snapshot of metadata sent by the SRC to SRS when a CS with Alice and Bob as participants is disconnected.</t>
<t><figure><artwork>
<![CDATA[
SRC SRS
| |
|(1) BYE (metadata snapshot) F1 |
|---------------------------------------------------->|
| 200 OK F2 |
|<----------------------------------------------------|
F1 BYE SRC -----------> SRS
BYE sip:2001@example.com SIP/2.0
Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 102 BYE
Max-Forwards: 70
Require: siprec
Accept: application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/rs-metadata
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>Partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<stop-time>2010-12-16T23:41:07Z</stop-time>
</session>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disasociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
</recording>
]]>
</artwork></figure></t>
</section>
</section>
<section title="Call Scenarios with SRC recording streams by mixing">
<t>The section describes a few example call flows where SRC may be part of conference model either as Focus or a participant in conference as explained in section 3.1.5 of <xref target="RFC7245"/>. The SRS here can be a SIP UA or an entity part of MEDIACTRL architecture. Note that the disconnect case is not shown since the metadata snapshot will be same as for a non-mixing case.</t>
<section title="Example 1: Basic call with SRC mixing streams">
<t> Basic call between two participants Alice and Bob who are part of one CS. In this use case each participant call into a conference server (say, an MCU) to attend
one of many conferences hosted on or managed by that servers. Media streams sent by each participant is received by all the other participants in the conference. Below is the initial snapshot sent by SRC in the INVITE to SRS that has the complete metadata. For the sake of simplicity only snippets of SIP/SDP are shown. The SRC records the streams of each participant to SRS by mixing in this example. The SRC here is part of conference model described in section 3 of <xref target="RFC7245"/> as a Focus and does mixing. The SRC here is not a participant by itself and hence it does not contribute to media.</t>
<t><figure><artwork>
<![CDATA[
F1 INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=00000000000000000000000000000000
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>complete</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<start-time>2010-12-16T23:41:07Z</start-time>
<sipSessionID>fa3b60f27e91441e84c55a9a0095f075
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>ca718e1430474b5485a53aa5d0bea45e
;remote=68caf509b9284b7ea45f84a049febf0a</sipSessionID>
</session>
<participant
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<nameID aor="sip:alice@atlanta.com">
<name xml:lang="it">Alice</name>
</nameID>
</participant>
<participant
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor="sip:bob@biloxy.com">
<name xml:lang="it">Bob</name>
</nameID>
</participant>
<stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
</recording>
]]>
</artwork></figure></t>
<t>In the above example there are two participants Alice and Bob in the conference. Among other things, SRC sends Session-ID in the metadata snapshot. There are two Session-ID's here, one that corresponds to the SIP session between Alice and conference focus and the other for the SIP session between Bob and conference focus. In this use-case, since Alice and Bob calls into the conference these Session-ID's are different.</t>
</section>
<section title="Example 2: Hold/resume with SRC recording by mixing streams">
<t> Assume a call between two participants Alice and Bob is established and a RS is created for recording as in example 5. This is the continuation of above use-case. One of the participants Bob puts Alice hold and then resumes as part of the same CS. The send and recv XML elements of a participant is used to indicate whether a participant is contributing or not to a media stream. The metadata snapshot looks as below: </t>
<t>During hold</t>
<t><figure><artwork>
<![CDATA[
mid call hold RE-INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
</participantstreamassoc>
</recording>
]]>
</artwork></figure></t>
<t>During resume a snapshot shown below will be sent from SRC to SRS.</t>
<t><figure><artwork>
<![CDATA[
mid call resume RE-INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
</recording>
]]>
</artwork></figure></t>
</section>
<section title="Example 3: Metadata snapshot of joining/dropping of a participant to a session">
<t>In a conference model, participants can join and drop a session any time during the session. The below shows a snapshot sent from SRC to SRC in these case. Note the SRC here can be a focus or a participant in the conference. In case where the SRC is a participant it may learn the information required for metadata by subscribing to conference event package <xref target="RFC4575"/>. Assume Alice and Bob were in the conference and a third participant Carol joins, then SRC sends the below snapshot with the indication of new participant.</t>
<t>
<figure><artwork>
<![CDATA[
mid call resume RE-INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<sipSessionID>fa3b60f27e91441e84c55a9a0095f075
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>ca718e1430474b5485a53aa5d0bea45e
;remote=68caf509b9284b7ea45f84a049febf0a</sipSessionID>
<sipSessionID>497c0f13929643b4a16858e2a3885edc
;remote=0e8a82bedda74f57be4a4a4da54167c4</sipSessionID>
</session>
<participant
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<nameID aor="sip:carol@example.com">
<name xml:lang="it">Carol</name>
</nameID>
</participant>
<participantsessionassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2013-12-16T23:41:07Z</associate-time>
</participantsession>
<participantstreamassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
</recording>
]]>
</artwork></figure></t>
<t> Assume Alice drops after some time from the conference. SRC generates a new snapshot showing Alice disassociating from the session</t>
<t><figure>
<artwork>
<![CDATA[
mid call resume RE-INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<sipSessionID>ca718e1430474b5485a53aa5d0bea45e
;remote=68caf509b9284b7ea45f84a049febf0a</sipSessionID>
<sipSessionID>497c0f13929643b4a16858e2a3885edc
;remote=0e8a82bedda74f57be4a4a4da54167c4</sipSessionID>
</session>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
</recording>
]]>
</artwork></figure></t>
</section>
<section title="Example 4: Call disconnect">
<t>When a CS is disconnected, SRC sends BYE with a snapshot of metadata having session stop-time and participant dis-associate times. The snapshot looks same as listed in section 3.2.4</t>
</section>
</section>
<section title="Call scenarios with persistent RS between SRC and SRS">
<t>The section shows the snapshots of metadata for the cases there a persistent RS exists between SRC and SRS. An SRC here may be SIP UA or a B2BUA or may be part of Conference model either as Focus or a participant in a conference. The SRS here could be a SIP UA or an entity part of
MEDIACTRL architecture. Except disconnect case, the snapshot remains same as mentioned in previous sections. </t>
<section title="Example 1: Metadata snapshot during CS disconnect with persistent RS between SRC and SRS">
<t><figure>
<artwork>
<![CDATA[
RE-INVITE sent from SRC -----------> SRS
INVITE sip:2001@example.com SIP/2.0
Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/rs-metadata
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>Partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<stop-time>2010-12-16T23:41:07Z</stop-time>
</session>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disasociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
</recording>
]]>
</artwork></figure></t>
</section>
</section>
<section title="Turrent-Case: Multiple CS into single RS with mixed stream">
<t>
In trading floor environments, in order to minimize storage and
recording system resources, it may be preferable to mix multiple
concurrent calls (each call is one CS) on different handsets/
speakers on the same turret into a single RS. This would means media in each CS is mixed and recorded as part of single media stream and multiple such CSs are recording in one RSfrom a SRC to SRS. </t>
<t>Lets take a example where there are two CS[CS1 and CS2]. Assume mixing is done in each of these CS and both these CS are recorded as part of single RS from a single SRC which is part of both the CS. There are three possibilities here:</t>
<t>
<list style='symbols'>
<t>CS1 and CS2 uses the same Focus for fixing and that Focus is also
acting as SRC in each of the CS.</t>
<t>In of the CS(say CS1), SRC is Focus and in the other CS(say CS2), SRC
is just one of the participant of the conference.</t>
<t> In both CS1 and CS2, SRC is just a participant of conference. </t>
</list>
</t>
<t> The following example shows the first possibility where CS1 and CS2 uses the
same Focus for fixing and that Focus is also acting as SRC in each of the
CS.
</t>
<t><figure>
<artwork>
<![CDATA[
snapshot of metadata INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=00000000000000000000000000000000
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>complete</datamode>
<group group_id="7+OTCyoxTmqmqyA/1weDAg==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</group>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref>
<start-time>2010-12-16T23:41:07Z</start-time>
<sipSessionID>fa3b60f27e91441e84c55a9a0095f075
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>ca718e1430474b5485a53aa5d0bea45e
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>497c0f13929643b4a16858e2a3885edc
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
</session>
<session session_id="zzlafnvvjlCHllaHF6mn8kkSS==">
<group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref>
<start-time>2010-12-16T23:43:07Z</start-time>
<sipSessionID>ae10731ca50343a5aaae2dd0904a65de
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSession>33c77aac7deb414cbc8c10f363fccb71
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>fd6932e9e5fc489fae2d5b3779723b7e
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
</session>
<participant
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<nameID aor="sip:alice@atlanta.com">
<name xml:lang="it">Alice</name>
</nameID>
</participant>
<participant
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor="sip:Bob@biloxy.com">
<name xml:lang="it">Bob</name>
</nameID>
</participant>
<participant
participant_id="EiXGlc+4TruqqoDaNE76ag==">
<nameID aor="sip:Carol@example.com">
<name xml:lang="it">Carol</name>
</nameID>
</participant>
<stream stream_id="UAAMm5GRQKSCMVvLyl4rFw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="zzlafnvvjlCHllaHF6mn8kkSS==">
<associate-time>2010-12-16T23:43:07Z</associate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="EiXGlc+4TruqqoDaNE76ag=="
session_id="zzlafnvvjlCHllaHF6mn8kkSS==">
<associate-time>2010-12-16T23:43:07Z</associate-time>
</participantsessionassoc>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="EiXGlc+4TruqqoDaNE76ag==">
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc>
</recording>
]]>
</artwork></figure></t>
</section>
</section>
<section title="Security Considerations">
<t> Security considerations mentioned in <xref target="I-D.ietf-siprec-metadata"/> and <xref target="I-D.ietf-siprec-protocol"/> has to be followed by SRC and SRS for setting up RS SIP dialog and sending metadata. </t>
</section>
<section title="IANA Considerations" anchor="sec.iana-considerations">
<t>This document has no IANA considerations</t>
</section>
<section title="Acknowledgement">
<t> Thanks to Ofir Rath, Charles Eckel and Yaron Pdut for their review comments. </t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-siprec-metadata"?>
<?rfc include="reference.RFC.7245"?>
<?rfc include="reference.RFC.4575"?>
<?rfc include="reference.RFC.4353"?>
<?rfc include="reference.RFC.6230"?>
<?rfc include="reference.RFC.6341"?>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.4566"?>
<?rfc include="reference.I-D.ietf-siprec-protocol"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 22:12:27 |