< draft-ietf-mediactrl-call-flows-12.txt		draft-ietf-mediactrl-call-flows-13.txt >
	MEDIACTRL A. Amirante		MEDIACTRL A. Amirante
	Internet-Draft University of Napoli		Internet-Draft University of Napoli
	Intended status: Informational T. Castaldi		Intended status: Informational T. Castaldi
	Expires: October 24, 2013 L. Miniero		Expires: November 24, 2013 L. Miniero
	Meetecho		Meetecho
	S P. Romano		S P. Romano
	University of Napoli		University of Napoli
	April 22, 2013		May 23, 2013
	Media Control Channel Framework (CFW) Call Flow Examples		Media Control Channel Framework (CFW) Call Flow Examples
	draft-ietf-mediactrl-call-flows-12		draft-ietf-mediactrl-call-flows-13
	Abstract		Abstract
	This document provides a list of typical Media Control Channel		This document provides a list of typical Media Control Channel
	Framework call flows. It aims at being a simple guide to the use of		Framework call flows. It aims at being a simple guide to the use of
	the interface between Application Servers and MEDIACTRL-based Media		the interface between Application Servers and MEDIACTRL-based Media
	Servers, as well as a base reference documentation for both		Servers, as well as a base reference documentation for both
	implementors and protocol researchers.		implementors and protocol researchers.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on October 24, 2013.		This Internet-Draft will expire on November 24, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 19 ¶		skipping to change at page 2, line 19 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. A Practical Approach . . . . . . . . . . . . . . . . . . . . 6		4. A Practical Approach . . . . . . . . . . . . . . . . . . . . 6
	4.1. State Diagrams . . . . . . . . . . . . . . . . . . . . . 6		4.1. State Diagrams . . . . . . . . . . . . . . . . . . . . . 6
	5. Control Channel Establishment . . . . . . . . . . . . . . . . 10		5. Control Channel Establishment . . . . . . . . . . . . . . . . 10
	5.1. COMEDIA Negotiation . . . . . . . . . . . . . . . . . . . 11		5.1. COMEDIA Negotiation . . . . . . . . . . . . . . . . . . . 11
	5.2. SYNC . . . . . . . . . . . . . . . . . . . . . . . . . . 14		5.2. SYNC . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	5.3. K-ALIVE . . . . . . . . . . . . . . . . . . . . . . . . . 16		5.3. K-ALIVE . . . . . . . . . . . . . . . . . . . . . . . . . 15
	5.4. Wrong behaviour . . . . . . . . . . . . . . . . . . . . . 18		5.4. Wrong behaviour . . . . . . . . . . . . . . . . . . . . . 17
	6. Use-case scenarios and examples . . . . . . . . . . . . . . . 21		6. Use-case scenarios and examples . . . . . . . . . . . . . . . 20
	6.1. Echo Test . . . . . . . . . . . . . . . . . . . . . . . . 28		6.1. Echo Test . . . . . . . . . . . . . . . . . . . . . . . . 27
	6.1.1. Direct Echo Test . . . . . . . . . . . . . . . . . . 29		6.1.1. Direct Echo Test . . . . . . . . . . . . . . . . . . 28
	6.1.2. Echo Test based on Recording . . . . . . . . . . . . 31		6.1.2. Echo Test based on Recording . . . . . . . . . . . . 30
	6.2. Phone Call . . . . . . . . . . . . . . . . . . . . . . . 39		6.2. Phone Call . . . . . . . . . . . . . . . . . . . . . . . 38
	6.2.1. Direct Connection . . . . . . . . . . . . . . . . . . 42		6.2.1. Direct Connection . . . . . . . . . . . . . . . . . . 41
	6.2.2. Conference-based Approach . . . . . . . . . . . . . . 44		6.2.2. Conference-based Approach . . . . . . . . . . . . . . 43
	6.2.3. Recording a conversation . . . . . . . . . . . . . . 50		6.2.3. Recording a conversation . . . . . . . . . . . . . . 49
	6.3. Conferencing . . . . . . . . . . . . . . . . . . . . . . 56		6.3. Conferencing . . . . . . . . . . . . . . . . . . . . . . 55
	6.3.1. Simple Bridging . . . . . . . . . . . . . . . . . . . 61		6.3.1. Simple Bridging . . . . . . . . . . . . . . . . . . . 60
	6.3.2. Rich Conference Scenario . . . . . . . . . . . . . . 65		6.3.2. Rich Conference Scenario . . . . . . . . . . . . . . 64
	6.3.3. Coaching Scenario . . . . . . . . . . . . . . . . . . 74		6.3.3. Coaching Scenario . . . . . . . . . . . . . . . . . . 73
	6.3.4. Sidebars . . . . . . . . . . . . . . . . . . . . . . 81		6.3.4. Sidebars . . . . . . . . . . . . . . . . . . . . . . 80
	6.3.5. Floor Control . . . . . . . . . . . . . . . . . . . . 90		6.3.5. Floor Control . . . . . . . . . . . . . . . . . . . . 89
	6.4. Additional Scenarios . . . . . . . . . . . . . . . . . . 96		6.4. Additional Scenarios . . . . . . . . . . . . . . . . . . 95
	6.4.1. Voice Mail . . . . . . . . . . . . . . . . . . . . . 96		6.4.1. Voice Mail . . . . . . . . . . . . . . . . . . . . . 95
	6.4.2. Current Time . . . . . . . . . . . . . . . . . . . . 103		6.4.2. Current Time . . . . . . . . . . . . . . . . . . . . 102
	6.4.3. DTMF-driven Conference Manipulation . . . . . . . . . 107		6.4.3. DTMF-driven Conference Manipulation . . . . . . . . . 106
	7. Media Resource Brokering . . . . . . . . . . . . . . . . . . 120		7. Media Resource Brokering . . . . . . . . . . . . . . . . . . 119
	7.1. Publishing Interface . . . . . . . . . . . . . . . . . . 120		7.1. Publishing Interface . . . . . . . . . . . . . . . . . . 119
	7.2. Consumer Interface . . . . . . . . . . . . . . . . . . . 128		7.2. Consumer Interface . . . . . . . . . . . . . . . . . . . 127
	7.2.1. Query Mode . . . . . . . . . . . . . . . . . . . . . 129		7.2.1. Query Mode . . . . . . . . . . . . . . . . . . . . . 128
	7.2.2. Inline-aware Mode . . . . . . . . . . . . . . . . . . 133		7.2.2. Inline-aware Mode . . . . . . . . . . . . . . . . . . 132
	7.2.3. Inline-unaware Mode . . . . . . . . . . . . . . . . . 147		7.2.3. Inline-unaware Mode . . . . . . . . . . . . . . . . . 146
	7.3. Handling media dialogs . . . . . . . . . . . . . . . . . 149		7.3. Handling media dialogs . . . . . . . . . . . . . . . . . 148
	7.3.1. Query and Inline-aware mode . . . . . . . . . . . . . 149		7.3.1. Query and Inline-aware mode . . . . . . . . . . . . . 148
	7.3.2. Inline-unaware mode . . . . . . . . . . . . . . . . . 152		7.3.2. Inline-unaware mode . . . . . . . . . . . . . . . . . 151
	7.3.3. CFW Protocol Bhaviour . . . . . . . . . . . . . . . . 156		7.3.3. CFW Protocol Bhaviour . . . . . . . . . . . . . . . . 158
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 159		8. Security Considerations . . . . . . . . . . . . . . . . . . . 161
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 167		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 170
	10. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 167		10. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 170
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 170		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 173
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 170		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 173
	12.1. Normative References . . . . . . . . . . . . . . . . . . 170		12.1. Normative References . . . . . . . . . . . . . . . . . . 173
	12.2. Informative References . . . . . . . . . . . . . . . . . 171		12.2. Informative References . . . . . . . . . . . . . . . . . 174
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 172		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 175
	1. Introduction		1. Introduction
	This document provides a list of typical MEDIACTRL Media Control		This document provides a list of typical MEDIACTRL Media Control
	Channel Framework [RFC6230] call flows. The motivation for this		Channel Framework [RFC6230] call flows. The motivation for this
	comes from our implementation experience with the framework and its		comes from our implementation experience with the framework and its
	protocol. This drove us to writing a simple guide to the use of the		protocol. This drove us to writing a simple guide to the use of the
	several interfaces between Application Servers and MEDIACTRL-based		several interfaces between Application Servers and MEDIACTRL-based
	Media Servers and a base reference documentation for other		Media Servers and a base reference documentation for other
	implementors and protocol researchers.		implementors and protocol researchers.
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 5 ¶
	answer, by communicating to the AS the transport address to connect		answer, by communicating to the AS the transport address to connect
	to in order to establish the TCP connection. In the provided		to in order to establish the TCP connection. In the provided
	example, the MS will listen on port 7575. Once this negotiation is		example, the MS will listen on port 7575. Once this negotiation is
	over, the AS can effectively connect to the MS.		over, the AS can effectively connect to the MS.
	The negotiation includes additional attributes, the most important		The negotiation includes additional attributes, the most important
	being the 'cfw-id' attribute, since it specifies the Dialog-ID which		being the 'cfw-id' attribute, since it specifies the Dialog-ID which
	will be subsequently referred to by both the AS and the MS, as		will be subsequently referred to by both the AS and the MS, as
	specified in the core framework draft.		specified in the core framework draft.
	Note that the provided example also includes the indication, from
	both the AS and the MS, of the supported control packages. This is
	achieved by means of a series of 'ctrl-package' attributes as
	specified in [I-D.boulton-mmusic-sdp-control-package-attribute]. In
	the example, the AS supports (or is only interested to) two packages:
	IVR (Interactive Voice Response) and Mixer (Conferencing and
	Bridging). The MS replies with the list of packages it supports,
	adding a dummy example package to the list provided by the AS. It is
	worth noting that this exchange of information is not meant as a
	strict or formal negotiation of packages: in case the AS realizes
	that one or more packages it needs are not supported according to the
	indications sent by the MS, it may, or may not, choose not to open a
	control channel with the MS at all, if its application logic leads to
	such a decision. The actual negotiation of control packages is done
	subsequenty through the use of the framework SYNC transaction.
	AS MS		AS MS
	| |		| |
	| 1. INVITE (COMEDIA) |		| 1. INVITE (COMEDIA) |
	|------------------------------>|		|------------------------------>|
	| 2. 100 (Trying) |		| 2. 100 (Trying) |
	|<------------------------------|		|<------------------------------|
	| 3. 200 OK (COMEDIA) |		| 3. 200 OK (COMEDIA) |
	|<------------------------------|		|<------------------------------|
	| 4. ACK |		| 4. ACK |
	|------------------------------>|		|------------------------------>|
	skipping to change at page 13, line 10 ¶		skipping to change at page 12, line 38 ¶
	Via: SIP/2.0/UDP 203.0.113.1:5060;\		Via: SIP/2.0/UDP 203.0.113.1:5060;\
	branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060		branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060
	Max-Forwards: 70		Max-Forwards: 70
	Contact: <sip:ApplicationServer@203.0.113.1:5060>		Contact: <sip:ApplicationServer@203.0.113.1:5060>
	To: <sip:MediaServer@ms.example.net:5060>		To: <sip:MediaServer@ms.example.net:5060>
	From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63		From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63
	Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY.		Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY.
	CSeq: 1 INVITE		CSeq: 1 INVITE
	Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER		Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER
	Content-Type: application/sdp		Content-Type: application/sdp
	Content-Length: 263		Content-Length: 203
	v=0		v=0
	o=lminiero 2890844526 2890842807 IN IP4 as.example.com		o=lminiero 2890844526 2890842807 IN IP4 as.example.com
	s=MediaCtrl		s=MediaCtrl
	c=IN IP4 as.example.com		c=IN IP4 as.example.com
	t=0 0		t=0 0
	m=application 5757 TCP cfw		m=application 5757 TCP cfw
	a=connection:new		a=connection:new
	a=setup:active		a=setup:active
	a=cfw-id:5feb6486792a		a=cfw-id:5feb6486792a
	a=ctrl-package:msc-ivr/1.0
	a=ctrl-package:msc-mixer/1.0
	2. AS <- MS (SIP 100 Trying)		2. AS <- MS (SIP 100 Trying)
	----------------------------		----------------------------
	SIP/2.0 100 Trying		SIP/2.0 100 Trying
	Via: SIP/2.0/UDP 203.0.113.1:5060; \		Via: SIP/2.0/UDP 203.0.113.1:5060; \
	branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060		branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060
	To: <sip:MediaServer@ms.example.net:5060>;tag=499a5b74		To: <sip:MediaServer@ms.example.net:5060>;tag=499a5b74
	From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63		From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63
	Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY.		Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY.
	CSeq: 1 INVITE		CSeq: 1 INVITE
	skipping to change at page 13, line 47 ¶		skipping to change at page 13, line 28 ¶
	SIP/2.0 200 OK		SIP/2.0 200 OK
	Via: SIP/2.0/UDP 203.0.113.1:5060; \		Via: SIP/2.0/UDP 203.0.113.1:5060; \
	branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060		branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060
	Contact: <sip:MediaServer@ms.example.net:5060>		Contact: <sip:MediaServer@ms.example.net:5060>
	To: <sip:MediaServer@ms.example.net:5060>;tag=499a5b74		To: <sip:MediaServer@ms.example.net:5060>;tag=499a5b74
	From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63		From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63
	Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY.		Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY.
	CSeq: 1 INVITE		CSeq: 1 INVITE
	Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER		Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER
	Content-Type: application/sdp		Content-Type: application/sdp
	Content-Length: 296		Content-Length: 199
	v=0		v=0
	o=lminiero 2890844526 2890842808 IN IP4 ms.example.net		o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
	s=MediaCtrl		s=MediaCtrl
	c=IN IP4 ms.example.net		c=IN IP4 ms.example.net
	t=0 0		t=0 0
	m=application 7575 TCP cfw		m=application 7575 TCP cfw
	a=connection:new		a=connection:new
	a=setup:passive		a=setup:passive
	a=cfw-id:5feb6486792a		a=cfw-id:5feb6486792a
	a=ctrl-package:msc-ivr/1.0
	a=ctrl-package:msc-example-pkg/1.0
	a=ctrl-package:msc-mixer/1.0
	4. AS -> MS (SIP ACK)		4. AS -> MS (SIP ACK)
	---------------------		---------------------
	ACK sip:MediaServer@ms.example.net:5060 SIP/2.0		ACK sip:MediaServer@ms.example.net:5060 SIP/2.0
	Via: SIP/2.0/UDP 203.0.113.1:5060; \		Via: SIP/2.0/UDP 203.0.113.1:5060; \
	branch=z9hG4bK-d8754z-22940f5f4589701b-1---d8754z-;rport		branch=z9hG4bK-d8754z-22940f5f4589701b-1---d8754z-;rport
	Max-Forwards: 70		Max-Forwards: 70
	Contact: <sip:ApplicationServer@203.0.113.1:5060>		Contact: <sip:ApplicationServer@203.0.113.1:5060>
	To: <sip:MediaServer@ms.example.net:5060>;tag=499a5b74		To: <sip:MediaServer@ms.example.net:5060>;tag=499a5b74
	From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63		From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63
	skipping to change at page 15, line 15 ¶		skipping to change at page 14, line 36 ¶
	Besides, it offers an additional negotiation mechanism. In fact, the		Besides, it offers an additional negotiation mechanism. In fact, the
	AS uses the SYNC not only to properly correlate as explained before,		AS uses the SYNC not only to properly correlate as explained before,
	but also to negotiate with the MS the control packages it is		but also to negotiate with the MS the control packages it is
	interested in, as well as to agree on a Keep-Alive timer needed by		interested in, as well as to agree on a Keep-Alive timer needed by
	both the AS and the MS to understand if problems on the connection		both the AS and the MS to understand if problems on the connection
	occur. In the provided example (see Figure 6 and the related call		occur. In the provided example (see Figure 6 and the related call
	flow), the AS sends a SYNC with a Dialog-ID constructed as needed		flow), the AS sends a SYNC with a Dialog-ID constructed as needed
	(using the 'cfw-id' attribute from the SIP dialog) and requests		(using the 'cfw-id' attribute from the SIP dialog) and requests
	access to two control packages, specifically the IVR and the Mixer		access to two control packages, specifically the IVR and the Mixer
	package (the same packages the AS previously indicated in its SDP as		package. Besides, it instructs the MS that a 100 seconds timeout is
	specified in [I-D.boulton-mmusic-sdp-control-package-attribute], with		to be used for Keep-Alive messages. The MS validates the request by
	the difference that this time they are reported in the context of a		matching the received Dialog-ID with the SIP dialog values and,
	binding negotiation). Besides, it instructs the MS that a 100		assuming it supports the control packages the AS requested access to
	seconds timeout is to be used for Keep-Alive messages. The MS		(and for the sake of this document we assume it does), it answers
	validates the request by matching the received Dialog-ID with the SIP		with a 200 message. Additionally, the MS provides the AS with a list
	dialog values and, assuming it supports the control packages the AS		of other unrequested packages it supports (in this case just a dummy
	requested access to (and for the sake of this document we assume it		package providing testing functionality).
	does), it answers with a 200 message. Additionally, the MS provides
	the AS with a list of other unrequested packages it supports (in this
	case just a dummy package providing testing functionality).
	AS MS		AS MS
	. .		. .
	. .		. .
	| |		| |
	| 1. SYNC (Dialog-ID, etc.) |		| 1. SYNC (Dialog-ID, etc.) |
	|+++++++++++++++++++++++++++++>>|		|+++++++++++++++++++++++++++++>>|
	| |--+		| |--+
	| | | Check SYNC		| | | Check SYNC
	| |<-+		| |<-+
	skipping to change at page 136, line 8 ¶		skipping to change at page 135, line 8 ¶
	v=0		v=0
	o=- 2890844526 2890842807 IN IP4 as.example.com		o=- 2890844526 2890842807 IN IP4 as.example.com
	s=MediaCtrl		s=MediaCtrl
	c=IN IP4 as.example.com		c=IN IP4 as.example.com
	t=0 0		t=0 0
	m=application 48035 TCP cfw		m=application 48035 TCP cfw
	a=connection:new		a=connection:new
	a=setup:active		a=setup:active
	a=cfw-id:vF0zD4xzUAW9		a=cfw-id:vF0zD4xzUAW9
	a=ctrl-package:msc-mixer/1.0
	a=ctrl-package:msc-ivr/1.0
	--Part		--Part
	Content-Type: application/mrb-consumer+xml		Content-Type: application/mrb-consumer+xml
	<?xml version="1.0" encoding="UTF-8" standalone="yes"?>		<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
	<mrbconsumer version="1.0"		<mrbconsumer version="1.0"
	xmlns="urn:ietf:params:xml:ns:mrb-consumer">		xmlns="urn:ietf:params:xml:ns:mrb-consumer">
	<mediaResourceRequest id="fr34asx1">		<mediaResourceRequest id="fr34asx1">
	<generalInfo>		<generalInfo>
	<packages>		<packages>
	skipping to change at page 137, line 11 ¶		skipping to change at page 136, line 9 ¶
	v=0		v=0
	o=- 2890844526 2890842807 IN IP4 as.example.com		o=- 2890844526 2890842807 IN IP4 as.example.com
	s=MediaCtrl		s=MediaCtrl
	c=IN IP4 as.example.com		c=IN IP4 as.example.com
	t=0 0		t=0 0
	m=application 48035 TCP cfw		m=application 48035 TCP cfw
	a=connection:new		a=connection:new
	a=setup:active		a=setup:active
	a=cfw-id:vF0zD4xzUAW9		a=cfw-id:vF0zD4xzUAW9
	a=ctrl-package:msc-mixer/1.0
	a=ctrl-package:msc-ivr/1.0
	5. MRB <- MS (200 OK SDP)		5. MRB <- MS (200 OK SDP)
	-------------------------		-------------------------
	[..]		[..]
	Content-Type: application/sdp		Content-Type: application/sdp
	v=0		v=0
	o=lminiero 2890844526 2890842808 IN IP4 ms.example.net		o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
	s=MediaCtrl		s=MediaCtrl
	c=IN IP4 ms.example.net		c=IN IP4 ms.example.net
	t=0 0		t=0 0
	m=application 7575 TCP cfw		m=application 7575 TCP cfw
	a=connection:new		a=connection:new
	a=setup:passive		a=setup:passive
	a=cfw-id:vF0zD4xzUAW9		a=cfw-id:vF0zD4xzUAW9
	a=ctrl-package:msc-mixer/1.0
	a=ctrl-package:msc-ivr/1.0
	a=ctrl-package:mrb-publish/1.0
	a=ctrl-package:msc-example-pkg/1.0
	7. AS <- MRB (200 OK multipart/mixed)		7. AS <- MRB (200 OK multipart/mixed)
	-------------------------------------		-------------------------------------
	[..]		[..]
	Content-Type: multipart/mixed;boundary="Part"		Content-Type: multipart/mixed;boundary="Part"
	--Part		--Part
	Content-Type: application/sdp		Content-Type: application/sdp
	v=0		v=0
	o=lminiero 2890844526 2890842808 IN IP4 ms.example.net		o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
	s=MediaCtrl		s=MediaCtrl
	c=IN IP4 ms.example.net		c=IN IP4 ms.example.net
	t=0 0		t=0 0
	m=application 7575 TCP cfw		m=application 7575 TCP cfw
	a=connection:new		a=connection:new
	a=setup:passive		a=setup:passive
	a=cfw-id:vF0zD4xzUAW9		a=cfw-id:vF0zD4xzUAW9
	a=ctrl-package:msc-mixer/1.0
	a=ctrl-package:msc-ivr/1.0
	a=ctrl-package:mrb-publish/1.0
	a=ctrl-package:msc-example-pkg/1.0
	--Part		--Part
	Content-Type: application/mrb-consumer+xml		Content-Type: application/mrb-consumer+xml
	<?xml version="1.0" encoding="UTF-8" standalone="yes"?>		<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
	<mrbconsumer version="1.0"		<mrbconsumer version="1.0"
	xmlns="urn:ietf:params:xml:ns:mrb-consumer">		xmlns="urn:ietf:params:xml:ns:mrb-consumer">
	<mediaResourceResponse reason="Resource found" status="200"		<mediaResourceResponse reason="Resource found" status="200"
	id="fr34asx1">		id="fr34asx1">
	<response-session-info>		<response-session-info>
	skipping to change at page 149, line 23 ¶		skipping to change at page 148, line 15 ¶
	actually redirected to the MS somehow.		actually redirected to the MS somehow.
	No content for the presented messages is provided in this section, as		No content for the presented messages is provided in this section, as
	in the IUMM mode no Consumer transaction is involved. In this		in the IUMM mode no Consumer transaction is involved. In this
	example, a simple [RFC6230] Control Channel negotiation occurs where		example, a simple [RFC6230] Control Channel negotiation occurs where
	the MRB acts as an intermediary, that is, picking a MS for the AS		the MRB acts as an intermediary, that is, picking a MS for the AS
	according to some logic. In this case, in fact, the AS does not		according to some logic. In this case, in fact, the AS does not
	support the MRB specification, and so just tries to set up a control		support the MRB specification, and so just tries to set up a control
	channel the way it knows.		channel the way it knows.
			It is worth pointing out that the MRB may actually enforce its
			decision about the MS to grant to the AS in different ways:
			specifically, the sentence "redirect the INVITE" that is used in
			Figure 51 does not necessarily mean that a SIP 302 message should be
			used for the purpose. A simple way to achieve this may be
			provisioning the unaware AS with different URIs, all actually
			transparently handled by the MRB itself: this would allow the MRB to
			simply map those URIs to different MS instances. Besides, the SIP
			'Contact' header may also be used by the MRB in a reply to an INVITE
			coming from an AS to provide the actual URI the chosen MS might be
			reached on. A motivation for such a discussion and more details
			about this are provided in Section 7.3.2.
	7.3. Handling media dialogs		7.3. Handling media dialogs
	It is worthwile to spend a few words to address how media dialogs		It is worthwile to spend a few words to address how media dialogs
	would be managed whenever a MRB is involved in the scenarios. In		would be managed whenever a MRB is involved in the scenarios. In
	fact, the presence of a MRB may introduce an additional complexity		fact, the presence of a MRB may introduce an additional complexity
	compared to the quite straightforward 1:1 AS-MS topology.		compared to the quite straightforward 1:1 AS-MS topology.
	7.3.1. Query and Inline-aware mode		7.3.1. Query and Inline-aware mode
	Normally, especially in the Query and IAMM case, the MRB would only		Normally, especially in the Query and IAMM case, the MRB would only
	skipping to change at page 152, line 22 ¶		skipping to change at page 151, line 26 ¶
	are unique but which all route to the same host and port, e.g.,		are unique but which all route to the same host and port, e.g.,
	sip:MrbToMs@mrb.example.com:5080;p=1234567890. Alternatively, the		sip:MrbToMs@mrb.example.com:5080;p=1234567890. Alternatively, the
	MRB might simply allocate a pool of URIs it would be responsible of,		MRB might simply allocate a pool of URIs it would be responsible of,
	and manage the associations with the requested MS services		and manage the associations with the requested MS services
	accordingly.		accordingly.
	7.3.2. Inline-unaware mode		7.3.2. Inline-unaware mode
	As mentioned previously, in the IUMM case the AS would interact with		As mentioned previously, in the IUMM case the AS would interact with
	the MRB as if it were the MS itself. One might argue that this would		the MRB as if it were the MS itself. One might argue that this would
	make the AS act as in the IUMM case: nevertheless, this is not the		make the AS act as in the IAMM case: nevertheless, this is not the
	case, considering the AS actually provided the MRB with information		case, considering there the AS actually provided the MRB with
	about the resources it required, and as such a proper MS has been		information about the resources it required, leading to a proper MS
	picked, while in the IUMM case the MRB would have to pick a MS with		to be picked, while in the IUMM case the MRB would have to pick a MS
	no help from the AS at all.		with no help from the AS at all.
	That said, the IUMM case is also very interesting with respect to the		That said, the IUMM case is also very interesting with respect to the
	media dialog management. In fact, in the MRB-unaware mode there		media dialog management. In fact, in the MRB-unaware mode there
	would be no Consumer request and an AS would actually see the MRB as		would be no Consumer request and an AS would actually see the MRB as
	an MS. This means that, unlike the previous scenarios, being there		an MS. This means that, unlike the previous scenarios, being there
	no AS<->MRB interaction and as such no MS selection process the MRB		no AS<->MRB interaction and as such no MS selection process the MRB
	would likely be in the signaling path anyway, at least when the AS		would likely be in the signaling path anyway, at least when the AS
	first shows up. The MRB could either redirect the AS to a MS		first shows up. The MRB could either redirect the AS to a MS
	directly or transparently act a proxy/B2BUA and contact a MS		directly or transparently act a proxy/B2BUA and contact a MS
	(according to implementation-specific policies) on behalf of the		(according to implementation-specific policies) on behalf of the
	unaware AS.		unaware AS.
	While apparently not a problem, this raises an issue when the same		While apparently not a problem, this raises an issue when the same
	unaware AS has several sessions with different MS: the AS would only		unaware AS has several sessions with different MS: the AS would only
	see one "virtual" MS (the MRB) and so it would relay all calls there,		see one "virtual" MS (the MRB) and so it would relay all calls there,
	making it hard for the MRB to understand where these media dialogs		making it hard for the MRB to understand where these media dialogs
	should belong: specifically, whether the UAC calling belongs to the		should belong: specifically, whether the UAC calling belongs to the
	AS application logic leading to MS1 or MS2, or wherever else.		AS application logic leading to MS1 or MS2, or wherever else.
	One possible approach to take care of this issue, is to always relay		One possible, very simple approach to take care of this issue, is to
	the SIP dialogs from the same unaware AS to the same MS. It is		always relay the SIP dialogs from the same unaware AS to the same MS.
	depicted in Figure 54.
			It is depicted in Figure 54.
	UAC1 UAC2 AS MRB MS		UAC1 UAC2 AS MRB MS
	| | | | |		| | | | |
	| | | 1. COMEDIA negotiation (A) | |		| | | 1. COMEDIA negotiation (A) | |
	| | |--------------------------->| |		| | |--------------------------->| |
	| | | | 2. COMEDIA neg. (A) |		| | | | 2. COMEDIA neg. (A) |
	| | | |--------------------->|		| | | |--------------------->|
	| | | | |		| | | | |
	| | |<<############## CFW CONNECTION #################>>|		| | |<<############## CFW CONNECTION #################>>|
	| | | | |		| | | | |
	| | | 3. COMEDIA negotiation (B) | |		| | | 3. COMEDIA negotiation (B) | |
	| | |--------------------------->| |		| | |--------------------------->| |
	| | | | 4. COMEDIA neg. (B) |		| | | | 4. COMEDIA neg. (B) |
	| | | |--------------------->|		| | | |--------------------->|
	| | | | |		| | | | |
	| | |<<############## CFW CONNECTION #################>>|		| | |<<############## CFW CONNECTION #################>>|
	| 5. INVITE xyz | | |		| 5. INVITE xyz | | |
	|--------------->| | |		|--------------->| | |
	| | | 6. Attach UAC to MS (3PCC) | |		| | | 6. Attach UAC1 to MS (3PCC)| |
	| | |--------------------------->| |		| | |--------------------------->| |
	| | | | 7. Attach UAC (3PCC) |		| | | | 7. Attach UAC (3PCC) |
	| | | |--------------------->|		| | | |--------------------->|
	| | | | |		| | | | |
	|<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|		|<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
	| | | | |		| | | | |
	| | 8. INVITE| | |		| | 8. INVITE| | |
	| | jkl | | |		| | jkl | | |
	| |--------->| | |		| |--------->| | |
	| | | 9. Attach UAC to MS (3PCC) | |		| | | 9. Attach UAC2 to MS (3PCC)| |
	| | |--------------------------->| |		| | |--------------------------->| |
	| | | | 10. Attach UAC (3PCC)|		| | | | 10. Attach UAC (3PCC)|
	| | | |--------------------->|		| | | |--------------------->|
	| | | | |		| | | | |
	| |<<++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|		| |<<++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
	| | | | |		| | | | |
	. . . . .		. . . . .
	. . . . .		. . . . .
	Figure 54: Handling media dialogs in IUMM: always the same MS		Figure 54: Handling media dialogs in IUMM: always the same MS
	skipping to change at page 154, line 11 ¶		skipping to change at page 153, line 15 ¶
	conference room. It's quite clear, then, that if the MRB forwarded		conference room. It's quite clear, then, that if the MRB forwarded
	the two CFW sessions to two different MS, the handling of UAC media		the two CFW sessions to two different MS, the handling of UAC media
	dialogs would prove troublesome, considering the MRB would have an		dialogs would prove troublesome, considering the MRB would have an
	hard way figuring out whether UAC1 should be attached to the MS		hard way figuring out whether UAC1 should be attached to the MS
	managing CFW session A or the MS managing CFW session B. Forwarding		managing CFW session A or the MS managing CFW session B. Forwarding
	all CFW sessions and UAC media dialogs coming from the same MRB-		all CFW sessions and UAC media dialogs coming from the same MRB-
	unaware AS to the same MS would instead work as expected: the MRB		unaware AS to the same MS would instead work as expected: the MRB
	would in fact leave the mapping of media dialogs and CFW sessions up		would in fact leave the mapping of media dialogs and CFW sessions up
	to the AS.		to the AS.
	This approach, while very simple and potentially not very scalable,		This approach, while very simple and indeed not very scalable, would
	would actually help take care of the issue: in fact, no matter how		actually help take care of the issue: in fact, no matter how many
	many separate control channels the AS might have with the MRB/MS (in		separate control channels the AS might have with the MRB/MS (in this
	this example, the control channel A would be mapped to application		example, the control channel A would be mapped to application xyz,
	xyz, and B to application jkl), the termination point would still		and B to application jkl), the termination point would still always
	always be the same MS, which would consequently be the destination		be the same MS, which would consequently be the destination for all
	for all media dialogs as well.		media dialogs as well.
	To overcome the scalability limitations of such an approach, at least		To overcome the scalability limitations of such an approach, though,
	in regard to the MRB being in the SIP signalling path for all calls,		at least in regard to the MRB being in the SIP signalling path for
	the MRB could instead make use of redirection, as depicted in		all calls, a different approach needs to be exploited. In fact,
	Figure 55.		especially in the case of different applications handled by the same
			unaware AS, it makes sense to try and exploit different MS for the
			purpose, and correctly track media dialogs being forwarded
			accordingly. This means that the MRB must find a way to somehow
			redirect the unaware AS to different MS when it predicts or realizes
			that a different application logic is being involved.
			To do so, the MRB might make use of different approaches. One of
			them is by making use of redirection, e.g., by means of a SIP 302
			message in reply to a control channel negotiation originated by an
			unaware AS. Such an approach is depicted in Figure 55.
	UAC1 AS MRB MS		UAC1 AS MRB MS
	| | | |		| | | |
	| | 1. COMEDIA negotiation | |		| | 1. COMEDIA negotiation | |
	| |--------------------------->| |		| |--------------------------->| |
	| | | |		| | | |
	| | 2. 302 Moved (MS) | |		| | 2. 302 Moved (MS) | |
	| |<---------------------------| |		| |<---------------------------| |
	| | | |		| | | |
	| | 3. COMEDIA negotiation | |		| | 3. COMEDIA negotiation | |
	| |-------------------------------------------------->|		| |-------------------------------------------------->|
	| | | |		| | | |
	| |<<############## CFW CONNECTION #################>>|		| |<<############## CFW CONNECTION #################>>|
	| | | |		| | | |
	| 4. INVITE xyz | | |		| 4. INVITE xyz | | |
	|--------------->| | |		|--------------->| | |
	| | 5. Attach UAC to MS (3PCC) | |		| | 5. Attach UAC1 to MS (3PCC)| |
	| |-------------------------------------------------->|		| |-------------------------------------------------->|
	| | | |		| | | |
	|<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|		|<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
	| | | |		| | | |
	. . . .		. . . .
	. . . .		. . . .
	Figure 55: Handling media dialogs in IUMM: redirection		Figure 55: Handling media dialogs in IUMM: redirection
	With this approach, the MRB might redirect the AS to a specific MS		With this approach, the MRB might redirect the AS to a specific MS
	skipping to change at page 155, line 40 ¶		skipping to change at page 155, line 22 ¶
	| | | |		| | | |
	| | 3. COMEDIA negotiation (MRB') | |		| | 3. COMEDIA negotiation (MRB') | |
	| |------------------------------>| |		| |------------------------------>| |
	| | | 4. COMEDIA neg. |		| | | 4. COMEDIA neg. |
	| | |------------------>		| | |------------------>
	| | | |		| | | |
	| |<<############## CFW CONNECTION #################>>|		| |<<############## CFW CONNECTION #################>>|
	| | | |		| | | |
	| 5. INVITE xyz | | |		| 5. INVITE xyz | | |
	|--------------->| | |		|--------------->| | |
	| | 6. Attach UAC to MRB' (3PCC) | |		| | 6. Attach UAC1 to MRB' (3PCC) | |
	| |------------------------------>| |		| |------------------------------>| |
	| | | 7 Attach UAC (3PCC)		| | | 7 Attach UAC (3PCC)
	| | |------------------>		| | |------------------>
	| | | |		| | | |
	|<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|		|<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
	| | | |		| | | |
	. . . .		. . . .
	. . . .		. . . .
	Figure 56: Handling media dialogs in IUMM: MRB in the signalling path		Figure 56: Handling media dialogs in IUMM: MRB in the signalling path
			It is worth pointing out that in both cases, though, that there are
			scenarios where there could be no assurance that the 302 sent by the
			MRB would be seen by the AS: in fact, should a proxy be between the
			AS and the MRB, such a proxy could act on the 302 itself. To
			properly cope with such an issue, the MRB might also make use of the
			'Contact' header in the SIP responses to the INVITE to address the
			right MS: while the AS is not required to use the info in such a
			header to reach the MS, it could be reasonable to exploit it for the
			purpose as it would take care of the proxy scenario mentioned above.
			To conclude, there is a further approach a MRB might try to exploit
			to take care of the IUMM case. Since, as explained before, the
			issues related to the IUMM case mostly relate to the fact that the
			MRB is seen as a single MS instance by the AS, a simple way to
			overcome this might be to make the MRB look as a set of different MS
			right away: this can be done by simply provisioning the unaware AS
			with a series of different URIs, all handled by the MRB itself acting
			as a pool of "virtual" MS. This way, the AS may be designed to use
			different MS for different classes of call, e.g., for different
			applications it is managing (two in the example presented in this
			section), and as such would contact two different of the provisioned
			URIs to create two distinct control channels towards two different
			MS. Considering both the URIs would be handled by the MRB, the MRB
			can use them to determine which MS each call should be directed to.
			Expanding on Figure 54 by removing the constraint to always use the
			same MS, this new scenario might looks as depicted in Figure 57.
			UAC1 UAC2 AS MRB MS1 MS2
			| | | | | |
			| | | 1. COMEDIA negotiation (A) | | |
			| | | INVITE fake-ms1 | | |
			| | |--------------------------->| | |
			| | | | 2. COMEDIA (A) | |
			| | | |---------------->| |
			| | | | | |
			| | |<<############## CFW CONNECTION 1 ##########>>| |
			| | | | | |
			| | | 3. COMEDIA negotiation (B) | | |
			| | | INVITE fake-ms2 | | |
			| | |--------------------------->| | |
			| | | | 4. COMEDIA neg. (B) |
			| | | |--------------------->|
			| | | | | |
			| | |<<############## CFW CONNECTION 2 ###############>>|
			| | | | | |
			| 5. INVITE xyz | | | |
			|--------------->| | | |
			| | | 6. Attach UAC1 to fake-ms1 (3PCC) | |
			| | |--------------------------->| | |
			| | | | 7. Attach UAC | |
			| | | |---------------->| |
			| | | | | |
			|<<++++++++++++++++++++++ RTP channels +++++++++++++++++++++++>>| |
			| | | | | |
			| 8. INVITE jkl | | | |
			|--------------->| | | |
			| | | 9. Attach UAC2 to fake-ms2 (3PCC) | |
			| | |--------------------------->| | |
			| | | | 10. Attach UAC | |
			| | | |--------------------->|
			| | | | | |
			|<<+++++++++++++++++++++++++ RTP channels +++++++++++++++++++++++++>>|
			| | | | | |
			. . . . . .
			. . . . . .
			Figure 57: Handling media dialogs in IUMM: provisioned URIs
			In this new example, we still assume that the same unaware AS is
			handling two different applications, still associated with the same
			URIs as before. This time, though, we also assume the AS has been
			designed to try and make use of different MS instances to handle the
			two very different applications it is responsible for. Besides, we
			also assume it has been configured to be able to use two different
			MS, respectively reachable at SIP URI 'fake-ms1' and 'fake-ms2', both
			actually handled by the MRB transparently. This results, just as
			before, in two different control channels (A and B) being created,
			but towards two different MS: specifically, the MRB makes sure that,
			for this AS, the control channel negotiation towards 'fake-ms1' is
			actually redirected to MS1; at the same time, 'fake-ms2' is
			associated with MS2. Once the AS has set up the control channels
			with both the MS, it is ready to handle media dialogs. UAC1 calls
			the SIP URI 'xyz' on the AS to order a pizza: the AS attaches the
			media dialog to the MS it knows is responsible for that branch of
			application logic, that is 'fake-ms1'; the MRB in turn makes sure it
			reaches the right MS instance, MS1. Later on, a different user,
			UAC2, calls SIP URI 'jkl' to join a conference room: this time the AS
			attaches this new media dialog to the MS instance handling the
			conference application, that is 'fake-ms2'; again, the MRB makes sure
			it is actually MS2 to receive the dialog.
			Again, this diagram is only meant to describe how the MRB might
			enforce its decisions: Just as described in the previous examples,
			the MRB may choose to either act as a proxy/B2BUA in between the AS
			and the MS instances, or redirect the AS to the right MS instances
			when they're first contacted (e.g., by means of the Contact header
			and/or a SIP redirect as explained before) and let the AS attach the
			media dialogs by itself.
	7.3.3. CFW Protocol Bhaviour		7.3.3. CFW Protocol Bhaviour
	As shown in the previous diagrams, no matter what the topology, the		As shown in the previous diagrams, no matter what the topology, the
	AS and MS usually end up with a direct connection with respect to the		AS and MS usually end up with a direct connection with respect to the
	CFW control channel. As such, it can be expected that the CFW		CFW control channel. As such, it can be expected that the CFW
	protocol continue to work as it should, and as a consequence all the		protocol continue to work as it should, and as a consequence all the
	call flows presented in this document can easily be reproduced in		call flows presented in this document can easily be reproduced in
	those circumstances as well.		those circumstances as well.
	One aspect needs to be taken in very good care, nevertheless. It's		One aspect needs to be taken in very good care, nevertheless. It's
	skipping to change at page 156, line 38 ¶		skipping to change at page 159, line 12 ¶
	using different 'connectionid' identifiers to address actually the		using different 'connectionid' identifiers to address actually the
	same UAC, thus preventing the protocol to work as expected. As a		same UAC, thus preventing the protocol to work as expected. As a
	consequence, it's very important that any MRB implementation take		consequence, it's very important that any MRB implementation take
	very good care of preserving the integrity of the involved SIP		very good care of preserving the integrity of the involved SIP
	headers when proxying/forwarding SIP dialogs between AS and MS, in		headers when proxying/forwarding SIP dialogs between AS and MS, in
	order not to break the protocol behaviour.		order not to break the protocol behaviour.
	Let's take, for instance, the scenario depicted in Figure 53,		Let's take, for instance, the scenario depicted in Figure 53,
	especially steps 6 and 7 which specifically address an UAC being		especially steps 6 and 7 which specifically address an UAC being
	attached by an AS to a MS via the MRB. Let's assume that what is		attached by an AS to a MS via the MRB. Let's assume that what is
	presented in Figure 57 is what happens to the From: and To: headers		presented in Figure 58 is what happens to the From: and To: headers
	when dealing with the 3PCC approach to attach a specific UAC to the		when dealing with the 3PCC approach to attach a specific UAC to the
	MS in that case.		MS in that case.
	UAC AS MRB MS		UAC AS MRB MS
	| | | |		| | | |
	| INVITE xyz | | |		| INVITE xyz | | |
	|--------------->| | |		|--------------->| | |
	| | SIP [..] | |		| | SIP [..] | |
	| | From: <..>;tag=a1b2c3 | |		| | From: <..>;tag=a1b2c3 | |
	| | To: <..>;tag=d4e5f6 | |		| | To: <..>;tag=d4e5f6 | |
	skipping to change at page 157, line 26 ¶		skipping to change at page 159, line 37 ¶
	| | |<---------------------->|		| | |<---------------------->|
	| | | |		| | | |
	| | 1. CONTROL (play announcement to UAC) |		| | 1. CONTROL (play announcement to UAC) |
	| |-------------------------------------------------->|		| |-------------------------------------------------->|
	| | 2. 200 (IVR Error!) |		| | 2. 200 (IVR Error!) |
	| |<--------------------------------------------------|		| |<--------------------------------------------------|
	| | | |		| | | |
	. . . .		. . . .
	. . . .		. . . .
	Figure 57: CFW protocol behaviour in case of manipulated tags		Figure 58: CFW protocol behaviour in case of manipulated tags
	In the example, once done with the 3PCC and the UAC being attached to		In the example, once done with the 3PCC and the UAC being attached to
	the MS, the AS and the MS end up with different assumptions with		the MS, the AS and the MS end up with different assumptions with
	respect to the 'connectionid' addressing UAC. In fact, the AS builds		respect to the 'connectionid' addressing UAC. In fact, the AS builds
	a 'connectionid' using the tags it is aware of (a1b2c3:d4e5f6), while		a 'connectionid' using the tags it is aware of (a1b2c3:d4e5f6), while
	the MS builds a different one, considering it got different		the MS builds a different one, considering it got different
	information from the MRB (aaabbb:cccddd).		information from the MRB (aaabbb:cccddd).
	As a consequence, when the AS tries to play an announcement to the		As a consequence, when the AS tries to play an announcement to the
	UAC using the connectionid it correctly constructed, the MS just as		UAC using the connectionid it correctly constructed, the MS just as
	skipping to change at page 159, line 37 ¶		skipping to change at page 161, line 42 ¶
	how a single secured MS is assumed to reply to different AS when		how a single secured MS is assumed to reply to different AS when
	receiving requests that may cross the bounds each AS is constrained		receiving requests that may cross the bounds each AS is constrained
	within. It is the case, for instance, of generic auditing requests,		within. It is the case, for instance, of generic auditing requests,
	or explicit conference manipulation requests where the involved		or explicit conference manipulation requests where the involved
	identifiers are not part of the context of the originating AS.		identifiers are not part of the context of the originating AS.
	To address a very specific scenario, let's assume that two different		To address a very specific scenario, let's assume that two different
	AS, AS1 and AS2, have established a Control Channel with the same MS.		AS, AS1 and AS2, have established a Control Channel with the same MS.
	Considering the SYNC transaction an AS and a MS use to set up a		Considering the SYNC transaction an AS and a MS use to set up a
	control channel, the MS is able to discern the requests coming from		control channel, the MS is able to discern the requests coming from
	AS1 from the ones coming from AS2. Let's also assume that AS1 has		AS1 from the ones coming from AS2: in fact, as explained in
	created a conference mix (confid=74b6d62) to which it has attached		Section 5.1 and Section 5.2, an AS and a MS negotiate a cfw-id
	some participants within the context of its business logic, while AS2		attribute in the SDP, and the same value is subsequently used in the
	has created a currently active IVR dialog (dialogid=dfg3252) with a		SYNC message on the control channel that is created after the
	user agent it is handling (237430727:a338e95f); besides, AS2 has also		negotiation, thus reassuring both the AS and the MS about the fact
	joined two connections to each other (1:75d4dd0d and 1:b9e6a659). As		that the control channel they share is actually the one they
	it is clear, it is highly desirable that AS1 is not aware of what AS2		negotiated in the first place.
	is doing with the MS and viceversa, and that they are not allowed to
	manipulate the other's resources. The following transactions will		Let's also assume that AS1 has created a conference mix
	occur, and it will be shown how the MS is assumed to reply in all the		(confid=74b6d62) to which it has attached some participants within
	cases in order to avoid security issues:		the context of its business logic, while AS2 has created a currently
			active IVR dialog (dialogid=dfg3252) with a user agent it is handling
			(237430727:a338e95f); besides, AS2 has also joined two connections to
			each other (1:75d4dd0d and 1:b9e6a659). As it is clear, it is highly
			desirable that AS1 is not aware of what AS2 is doing with the MS and
			viceversa, and that they are not allowed to manipulate the other's
			resources. The following transactions will occur, and it will be
			shown how the MS is assumed to reply in all the cases in order to
			avoid security issues:
	1. AS1 places a generic audit request to both the mixer and IVR		1. AS1 places a generic audit request to both the mixer and IVR
	packages;		packages;
	2. AS2 places a generic audit request to both the mixer and IVR		2. AS2 places a generic audit request to both the mixer and IVR
	packages;		packages;
	3. AS1 tries to terminate the dialog created by AS2 (6791fee);		3. AS1 tries to terminate the dialog created by AS2 (6791fee);
	4. AS2 tries to join a user agent it handles (1:272e9c05) to the		4. AS2 tries to join a user agent it handles (1:272e9c05) to the
	conference mix created by AS1 (74b6d62);		conference mix created by AS1 (74b6d62);
	A sequence diagram of the mentioned transactions is depicted in		A sequence diagram of the mentioned transactions is depicted in
	Figure 58:		Figure 59:
	AS1 AS2 MS		AS1 AS2 MS
	| | |		| | |
	| A1. CONTROL (IVR audit) |		| A1. CONTROL (IVR audit) |
	|++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>|		|++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>|
	| | A2. 200 OK |		| | A2. 200 OK |
	|<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++|		|<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
	| | |		| | |
	| B1. CONTROL (Mixer audit) |		| B1. CONTROL (Mixer audit) |
	|++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>|		|++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>|
	skipping to change at page 161, line 5 ¶		skipping to change at page 163, line 40 ¶
	|<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++|		|<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
	| | |		| | |
	| | F1. CONTROL (join UAC&conf[AS1]) |		| | F1. CONTROL (join UAC&conf[AS1]) |
	| |++++++++++++++++++++++++++++++++>>|		| |++++++++++++++++++++++++++++++++>>|
	| | F2. 403 Forbidden |		| | F2. 403 Forbidden |
	| |<<++++++++++++++++++++++++++++++++|		| |<<++++++++++++++++++++++++++++++++|
	| | |		| | |
	. . .		. . .
	. . .		. . .
	Figure 58: Security Considerations: Framework Transaction		Figure 59: Security Considerations: Framework Transaction
	The expected outcome of the transaction is the MS partially "lying"		The expected outcome of the transaction is the MS partially "lying"
	to both AS1 and AS2 when replying to the audit requests (not all the		to both AS1 and AS2 when replying to the audit requests (not all the
	identifiers are reported, but only the ones each AS is directly		identifiers are reported, but only the ones each AS is directly
	involved in), and the MS denying the requests for the unauthorized		involved in), and the MS denying the requests for the unauthorized
	operations (403). Looking at each transaction separately:		operations (403). Looking at each transaction separately:
	o In the first transaction (A1), AS1 places a generic <audit>		o In the first transaction (A1), AS1 places a generic <audit>
	request to the IVR package; the request is generic since no		request to the IVR package; the request is generic since no
	attributes are passed as part of the request, meaning AS1 is		attributes are passed as part of the request, meaning AS1 is
	skipping to change at page 167, line 41 ¶		skipping to change at page 170, line 32 ¶
	CFW 140e0f763352 403		CFW 140e0f763352 403
	9. IANA Considerations		9. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	10. Change Summary		10. Change Summary
	Note to RFC Editor: Please remove this whole section.		Note to RFC Editor: Please remove this whole section.
			The following are the major changes between the 12 and the 13
			versions of the draft:
			o Fixed some nits in the document.
			o Addressed additional comments and typos reported by Dale Worley
			from his review on the mailing list.
			o Clarified the IUMM scenario with respect to how media dialogs are
			handled.
			o Removed reference to expired
			draft-boulton-mmusic-sdp-control-package-attribute and related
			example.
	The following are the major changes between the 11 and the 12		The following are the major changes between the 11 and the 12
	versions of the draft:		versions of the draft:
	o Fixed some nits in the document.		o Fixed some nits in the document.
	o Addressed additional comments and typos reported by Dale Worley		o Addressed additional comments and typos reported by Dale Worley
	from his review on the mailing list.		from his review on the mailing list.
	The following are the major changes between the 10 and the 11		The following are the major changes between the 10 and the 11
	versions of the draft:		versions of the draft:
	skipping to change at page 171, line 19 ¶		skipping to change at page 174, line 19 ¶
	the Session Description Protocol (SDP)", RFC 4145,		the Session Description Protocol (SDP)", RFC 4145,
	September 2005.		September 2005.
	[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the		[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
	Transport Layer Security (TLS) Protocol in the Session		Transport Layer Security (TLS) Protocol in the Session
	Description Protocol (SDP)", RFC 4572, July 2006.		Description Protocol (SDP)", RFC 4572, July 2006.
	[RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media		[RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media
	Control Channel Framework", RFC 6230, May 2011.		Control Channel Framework", RFC 6230, May 2011.
	[I-D.boulton-mmusic-sdp-control-package-attribute]
	Boulton, C., "A Session Description Protocol (SDP) Control
	Package Attribute",
	draft-boulton-mmusic-sdp-control-package-attribute-07
	(work in progress), September 2011.
	[RFC6231] McGlashan, S., Melanchuk, T., and C. Boulton, "An		[RFC6231] McGlashan, S., Melanchuk, T., and C. Boulton, "An
	Interactive Voice Response (IVR) Control Package for the		Interactive Voice Response (IVR) Control Package for the
	Media Control Channel Framework", RFC 6231, May 2011.		Media Control Channel Framework", RFC 6231, May 2011.
	[RFC6505] McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer		[RFC6505] McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
	Control Package for the Media Control Channel Framework",		Control Package for the Media Control Channel Framework",
	RFC 6505, March 2012.		RFC 6505, March 2012.
	[RFC6917] Boulton, C., Miniero, L., and G. Munson, "Media Resource		[RFC6917] Boulton, C., Miniero, L., and G. Munson, "Media Resource
	Brokering", RFC 6917, April 2013.		Brokering", RFC 6917, April 2013.
End of changes. 32 change blocks.
	132 lines changed or deleted		233 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/