Internet DRAFT - draft-rverma-media-multihoming-over-sctp
draft-rverma-media-multihoming-over-sctp
Network Working Group Rohit Verma
Internet-Draft Bangalore, India
Expires:10 July, 2012 Jan 10, 2012
Media Multihoming in SIP Sessions
draft-rverma-media-multihoming-over-sctp-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on 09 July, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as
the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info)
in effect on the date of publication of this document. Please
review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License
text as described in Section 4.e of the Trust Legal Provisions and
are provided without warranty as described in the Simplified BSD
License."
Abstract
This document discusses the requirements and procedures to achieve the
multihoming of media for voice over IP sessions using the transport layer
protocol as signaling Control Transmission Protocol.
Media is an essential part of any voice over IP session. SIP (RFC 3261)
is a text based signaling protocol and Multihoming using SIP can be
achieved by using the SCTP as a transport protocol (RFC 4168),
therefore the application level resiliency can be guaranteed even in
case of any middle node or terminal failures. But any voice over IP or
multimedia session is nearly insignificant, if the media path is broken
during a call and is waiting for a timeout which further shall lead to a
call drop.A complete solution to Multihoming can be achieved if a system
is capable of a performing the failovers at both application and media
plane and still maintaining the session irrespective of the application
or media path failures or at least to detect a signaling or media path
failure and terminate the session rather than waiting for timeouts. The
requirement of Multihoming in media can also be derived from the fact
that in any voice, video or data session, the signaling and call setup
time use to be incomparably short than that of real media session at
media plane. Therefore providing the resiliency at the signaling level
does not provide the guaranteed and best effort service from a media
session point of view as not only signaling but media is an integral
part of it.
Table of Contents
1. Introduction ............................................. 1
2. Terminology .............................................. 2
3. SCTP usage for Multihoming ............................... 2
4. Advantages of media Multihoming .......................... 2
5. Real Time media over SCTP ................................ 2
6. SIP and SDP extensions for Multihomed sessions ........... 2
6.1 UAC Behaviour ............................................ 2
6.2 UAS Behaviour ............................................ 4
7. Transport Protocol Requirements .......................... 5
7.1 Association establishment ................................ 5
7.2 Association Termination .................................. 6
8. Path Failures ............................................ 6
8.1 signaling Association failure ............................ 6
8.2 Media Association failure ................................. 6
9. Security Considerations .................................. 6
1. Introduction
The Stream Control Transmission Protocol (SCTP) is a reliable transport
protocol (RFC 2960) which is capable of providing several levels of
reliability over the voice over IP sessions. Whenever a higher level of
transport redundancy is desired in networks, in terms of multiple paths
and terminals, SCTP can be considered as a deserving candidate. As of now,
the signaling resiliency can be attained using the Multihoming over SCTP
(RFC 4168) when the ULP(upper Layer Protocol) is SIP. But a complete
Multihoming solution can be attained when along with signaling, media
is also Multihomed, during a voice over IP session.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Documents are to be interpreted as described in RFC 2119 [1].
3. SCTP usage for Multihoming
RFC 4168 define and discuss the Multihoming concepts with respect to the
Upper Layer Protocol (ULP) as SIP. SIP along with SDP, can be used to
indicate and instruct the peer node to accept the SCTP as the preferred
transport for real time media. It can further make use of the path
resiliency and failure detection mechanisms of SCTP to establish the redundant
and reliable media sessions.
4. Advantages of media Multihoming
UDP is considered as an outstanding protocol for real time media transport
as the media payloads are sent and received in out of sequence fashion.
SCTP, on the other hand has the inherent property of delivering the packets
in in-order or un-ordered fashion in application context while still
providing the reliability throughout the streams. This is suitable for the
real time protocols transporting the media between the devices. SCTP shall
use its inherent HEARTBEAT mechanism to detect the path failures and perform
a failover to a redundant media path in accordance with the application logic.
This further facilitates a way to continue a media session instead of a call
failure due to media inactivity detection during a session.
5. Real Time media over SCTP
The real time transmission protocol extensions to support SCTP, are not the
part of this document and the implementations MAY seek the partial
reliability extensions of SCTP described in RFC 3758. This specification
only recommends and discusses the application level amendments to choose
the transport type as SCTP for the media plane.
6. SIP and SDP extensions for Multihomed sessions
For signaling and media associations in over SCTP sessions, the two
associations SHALL be linked and the control logic should be driven by
the application.
However, all the associations SHALL be independent, in terms of transport
protocol counters and primitives, at signaling and media plane.
Both the participants SHALL specify the primary and secondary IP addresses
during the association establishment. ULP SHALL indicate to SCTP to select
the default primary path using primitives defined in RFC 4960.
6.1 UAC Behaviour
A User Agent Client (UAC) offering the Multihomed media and signaling
solutions can have various permutations based on the signaling and media
transport types. This draft concentrates on transport type as SCTP for
media at session or media level in SDP protocol.
UAC with a Multihoming solution for signaling shall use the procedures
as defined in RFC 4168 and RFC 5061 (dynamic address mapping).
UAC with both SCTP Multihomed media and signaling MUST specify the
support for it in its SDP offer.
To support the Single homed media over SCTP, a UAC MAY specify the transport
parameter in the m-line attribute of SDP (RFC 2327) along with the connection
parameter at session level.
v=0
o=first 2322646859 2815701234 IN IP4 node.mhome.net
s=mhome
t=0 0
c=IN IP4 10.217.10.15
m=audio 9 SCTP/RTP/AVP 0
m=audio 9 RTP/AVP 0
Figure-1(a): single home media at session level
UAC MAY also specify a connection address at media level for single homing
solutions which SHALL take precedence over the address, if specified, at
session level as an extension to the procedure specified in SDP RFC 2327.
v=0
o=first 2322646859 2815701234 IN IP4 node.mhome.net
s=mhome
t=0 0
m=audio 9 SCTP/RTP/AVP 0
c=IN IP4 10.217.10.15
m=audio 9 RTP/AVP 0
c=IN IP4 10.217.10.25
Figure-1(b): single home media at media level
However the Multihomed media solutions MUST have more than one c-lines,
corresponding the redundant media paths, at media level in the SDP offer
during a SIP session initiation.
v=0
o=first 2322646859 2815701234 IN IP4 node.mhome.net
s=mhome
t=0 0
c=IN IP4 10.217.10.35
m=audio 9 SCTP/RTP/AVP 0
c=IN IP4 10.217.10.15
c=IN IP4 10.218.10.25
m=video 49110/2 SCTP/RTP/AVP 31
m=video 49110/2 RTP/AVP 31
Figure-2: Multihomed media example
Above references are independent of the signaling transport type, this
draft does not mandate the signaling to be chosen as the SCTP and applications
MAY seek other transport types for signaling such as TCP or UDP.
If multiple "c=" lines are specified at session level and no "c=" line at
SDP media level with transport type as SCTP, then session SHALL BE treated
as multi homed media. On contrary to this, if multiple "c=" lines are present
at session level and single "c=" line is present at media level with transport
type as SCTP, then session MUST be treated as single homed media session. One
more advantage of specifying the multiple "c=" lines is to indicate the peer the
IP addresses which will result into the media association described as in
section 9.
UAC supporting media over SCTP MUST support UDP as a transport protocol for
media to perform fallback, if SCTP association results in a failure.
However, fallback decisions should be application specific.
If the UAS does not support the media over SCTP and no media lines are
specified in the SDP answer no new SCTP association should be created
and media should flow over the mutually agreed transport type.
UAC supporting Multihomed media over SCTP SHALL prefer to SCTP, this behaviour
is expected if the next hop entity supports media over SCTP. However, in case
of mismatch with peer entity, the next preferred protocol for media SHALL be
used by the application for media establishment.
Media over SCTP sessions SHOULD be agnostic of the transport type of ULP
as the SDP negotiation for media over SCTP SHALL results into new
associations. However, the recommendations are to prefer media over SCTP
if signaling is over SCTP for a resilient session.
Association establishment and terminations MUST be initiated by the User
Agent Client and applications and implementations MUST avoid the scenarios
where signaling and media association initiators are different.
UAC supporting all transport types for media SHALL follow the given rules
6.1.1 For media over SCTP, UAC MUST specify at least one "m="
line with SCTP transport type, denoted as "SCTP/RTP/AVP" in SDP
offer.
6.1.2 At least one connection address MUST be present for single homed
media, either at session or media level or both.
6.1.3 In case a connection address is specified at both session
and media level with SCTP, then the precedence procedures
described in RFC 2327 and RFC 4566 SHALL be followed.
6.1.4 For a Multihomed media sessions, UAC MUST specify all
SCTP connection parameters at media level in SDP if
signaling and media have different addresses.
6.1.5 UAC MUST specify all the connection addresses at session level if
both signaling and media addresses are same.There MUST not be
any connection address present at media level in such case.
6.1.6 There MUST be at least one more transport type specified in the
SDP offer to support the transport fallback.
6.2 UAS Behaviour
UAS supporting media over SCTP shall use the following rules
6.2.1 For media over SCTP, UAS MUST specify at least one "m=" line with
SCTP transport type, denoted as "SCTP/RTP/AVP" in SDP answer.
6.2.2 UAS MUST specify all supported transport types for media in SDP
answer.
6.2.3 UAS MUST specify at least one connection address either at
session level or media level in SDP answer.
6.2.4 UAS MUST not initiate an SCTP association for media.
6.2.5 UAS MUST specify at least one more transport type in SDP answer
at either session or media level, if it supports SCTP for the
transport fallback for media.
6.2.6 UAS SHALL specify the possible IP addresses that may result in to
an association with transport type as SCTP in "m=" line.
6.2.7 UAS MUST specify all the connection addresses at session level if
both signaling and media addresses are same. There MUST not be
any connection address present at media level in such case.
6.2.8 UAS SHALL not add the SCTP preferences in answer if not offered
from initiator of the session.
6.2.9 UAS Shall be able to modify the media associations.
Media associations MUST be initiated by UAC however, exceptions can be there
for three way calling sessions where the media mixer SHALL terminate or modify
the media focus and associations.
7. Transport Protocol Requirements
There should be separate and independent association establishment for
signaling and media at signaling and media plane so as to provide the
independence of transport type at both levels. This also facilitates the path
and endpoint failure detection at discrete levels.
7.1 Association establishment
For the applications using same set of IP addresses both for media and
signaling, no modifications to the established association are required
and signaling. This approach eliminates the need of maintaining the separate
HEARTBEAT counters both for media and signaling paths. In case if the peer
protocol support signaling but not media over SCTP, the session should be
established with signaling association only.
If the peer wishes to use the different set of transport address for media
and signaling, a new association MUST be initiated by the UAC to separate
the signaling and media path failure detections. This new association
establishment is also applicable when both peers have, at least one or all
separate transport addresses for either media or signaling. Creation of
new association for media also facilitates the separates monitoring on both
media and signaling paths using HEARTBEAT. This further provides a way to
perform the path failovers independently for both associations. This procedure
SHALL be applicable if either side is single homed with different IP address
than from signaling.
The new association for media shall have a different initiate and
verification tag than that of signaling along with the other SCTP attributes.
SIP application MUST have the full control over both the associations and it
should be responsible for managing all the linked associations during a session.
Application running on the SIP node MUST choose the primary signaling IP
address as the primary path media also if same set of IP addresses are
imparted in both signaling and media sessions.
If during a session any party wish to switch the media transport, it may
initiate the new SDP media session over SCTP using re-INVITE. If peer fails
to fulfil the request then transport type fall back MUST be employed. If change
in transport is successful, then media association SHALL be terminated by the
initiator of the media association.
If during an SCTP media session either party wishes to change the SCTP
attributes in SDP, it should initiate a re-INVITE which should follow
the procedures as specified in RFC 5061 for media or signaling association
modifications.
In case of change of participants, applications MAY seek the established
association modifications. However the terminations of existing association a
nd establishment of new association is recommended.
UAS also MAY initiate the new association if the SDP answer is received
in ACK, however this specification discourages such implementations so as
to have multiple associations control centric to one user agent.
7.2 Association Termination
Association termination shall be initiated at the receipt of BYE. Before
terminating the signaling association, media association shall be
terminated and BYE should propagate over SCTP for signaling association
conclusion.
In case if the applications are using same association both for media and
signaling then procedures for signaling association terminations as
specified in RFC 4960 shall be used.
8. Path Failures
8.1 signaling Association failure
signaling association failures SHALL be detected independent of the media
association failure however the media association MUST be terminated gracefully
if a 'Association.Max.Retrans' is reached for signaling association, followed
by signaling association termination.
In case of the same addresses being used in Multihomed media and signaling
scenarios, there arise no need to maintain the separate counters for Path
and association failures for both associations.
8.2 Media Association failure
In case of media Path failure detection, application shall try the next
available path on the expiry of T3-rtx timer. If all the paths are declared
as unavailable for media association then the indication MUST be sent to
application to shutdown the media association followed by the signaling
association shutdown.
In case, if the 'Association.Max.Retrans' is reached for media association,
application MUST immediately terminate signaling association after media
association termination.
In case of any initial media association establishment if an ABORT is received
in response to the INIT chunk, then next available transport type in precedence
MUST be used in the session.
9. Security Considerations
There are no new security considerations introduced in this document.
Authors' Address
Rohit Verma
114 Ashoka Windows
5th Main Mallespalya
Bangalore 560075
Karnataka India
Tel: +918884963560
Email: verma.rohitk@gmail.com
