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