One document matched: draft-ietf-mmusic-sdp-g723-g729-05.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc3667.dtd">
<?rfc toc='yes'?>
<?rfc tocdepth='4'?>
<?rfc compact="yes"?>
<!--rfc category="info" ipr="full3978"-->
<rfc category="std" ipr="trust200811">
	<front>
		<title abbrev="Offer/Answer G723 AnnexA & G729 AnnexB">
		    Offer/Answer Considerations for G723 Annex A and G729 Annex B
		</title>
            <author initials="Muthu A M" surname="Perumal" fullname="Muthu Arul Mozhi Perumal">
			<organization>Cisco Systems</organization>
			<address>
				<postal>
					<street>Cessna Business Park</street>
                    <street>Sarjapur-Marathahalli Outer Ring Road</street>
					<city>Bangalore</city>
					<region>Karnataka</region>
					<code>560103</code>
					<country>India</country>
				</postal>
				<email>mperumal@cisco.com</email>
			</address>
		</author>
            <author initials="Parthasarathi" surname="Ravindran" fullname="Parthasarathi Ravindran">
			<organization>Nokia Solutions and Networks</organization>
			<address>
				<postal>
				<street> Manyata Embassy Business park</street>	
					<city>Bangalore</city>
					<region>Karnataka</region>
                           <code>560045</code>

					<country>India</country>
				</postal>
				<email>partha@parthasarathi.co.in</email>
			</address>
		</author> 
		<date year="2014"/>
		<area>RAI</area>
		<workgroup>MMUSIC</workgroup>
		<abstract>
			<t>This document provides the offer/answer considerations for the annexa parameter of G723 
			and the annexb parameter of G729, G729D and G729E when the value of the annexa or annexb 
			parameter does not match in the Session Description protocol (SDP) offer and answer.
			</t>
		</abstract>
	</front>
	<middle>
		<section title="Introduction">
			<t><xref target="RFC4856"/> describes the annexa parameter for G723 as follows:</t>
			<t><list style="empty"> 
				<t>annexa: indicates that Annex A, voice activity detection, is used or preferred.
				Permissible values are "yes" and "no" (without the quotes); "yes" is implied if 
				this parameter is omitted.</t>
				</list></t>
			<t></t>
		      <t> Also, <xref target="RFC4856"/> describes the annexb parameter for G729, G729D and
			  G729E as follows:</t>
			<t><list style="empty">
				<t>annexb: indicates that Annex B, voice activity detection, is used or preferred. 
				Permissible values are "yes" and "no" (without the quotes); "yes" is implied if 
				this parameter is omitted.</t>
			</list></t>
            
			<t>However, problem arises when the value of the annexa or annexb parameter does not match 
            in the SDP [RFC4566] offer and answer.</t>
			
			<t>For example, if the offer has G729 with annexb=yes and the answer has G729 with annexb=no, 
			it can be interpreted in two different ways:</t>
            <list style="symbols">
				<t>The offerer and answerer proceed as if G729 is negotiated with annexb=yes, or</t>
				<t>The offerer and answerer proceed as if G729 is negotiated with annexb=no.</t>
			</list>
			
			<t>Since this is not clear in the existing specifications, various implementations have 
			interpreted the offer/answer in their own ways, resulting in a different codec being chosen
			to call failure, when the parameter value does not match in the offer and answer.</t>
            
			<t><xref target="RFC3264"/> requires SDP extensions that define new fmtp parameters to specify 
			their proper interpretation in offer/answer. This document specifies the proper interpretation 
			for the annexa and annexb parameters in offer/answer.</t>
            </section>
			
		<section title="Terminology" anchor="sec-term">
			<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
			   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 
				this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
		</section>
		
		<section title="Offer/Answer Considerations">
			<t><xref target="RFC3551"/> states that
				<t><list style="empty">
				   <t>Receivers MUST accept comfort noise frames if restriction of their use has not been signaled.
				      The MIME registration for G729 in RFC 3555 specifies a parameter that MAY be used with MIME or 
					  SDP to restrict the use of comfort noise frames.</t>
			   	   </list></t>
				<t>Hence, if the SDP offer or answer indicates that comfort noise is not supported, comfort noise 
				   frames MUST NOT be used.</t>
			</t>
			
			<section title="Offer/Answer Considerations for G723 Annex A">
			    <t>The general objective of the below offer/answer considerations is to make sure that if the
				   offerer or answerer indicates it does not support Annex A, Annex A is not used.</t>
				   
				<t>When the offer or answer has G723 and the annexa parameter is absent, the offerer or answerer knows 
				   that it has implied the default "annexa=yes". This is because the annexa attribute is part of the 
				   original registration of audio/G723 <xref target="RFC4856"/>. All implementations that support G723 
				   understand the annexa attribute. Hence, this case MUST be considered as if the offer or answer has 
				   G723 with annexa=yes.</t>

                <t>When the offer has G723 with annexa=yes and the answer has G723 with annexa=no, the offerer and 
				   answerer MUST proceed as if G723 is negotiated with annexa=no.</t>
                
				<t>When the offer has G723 with annexa=no, after the offer/answer completion the offerer and answerer 
				   MUST proceed as if G723 is negotiated with annexa=no.</t>
				
				<t><list style="empty">
				   <t>When the offer has G723 with annexa=no, the reason for not mandating that the answer MUST have annexa=no 
				      for G723 is that there are implementations that omit the annexa parameter in answer. In such case the 
				      offerer and answerer proceed as if G723 is negotiated with annexa=no.</t>
				   </list></t>
                
				<t>When the offer has G723 with no annexa parameter and the answer has G723 with annexa=yes,
				   the offerer and answerer MUST proceed as if G723 is negotiated with annexa=yes.</t>
            </section>
				
            <section title="Offer/Answer Considerations for G729 Annex B, G729D Annex B and G729E Annex B">
				<t>In this section G729 represents any of G729 or G729D or G729E.</t>

				<t>The general objective of the below offer/answer considerations is to make sure that if the
				   offerer or answerer indicates it does not support Annex B, Annex B is not used.</t>

				<t>When the offer or answer has G729 and the annexb parameter is absent, the offerer or answerer knows 
				   that it has implied the default "annexb=yes". This is because the annexb attribute is part of the 
				   original registration of audio/G729 <xref target="RFC4856"/>. All implementations that support G729 
				   understand the annexb attribute. Hence, this case MUST be considered as if the offer or answer has 
				   G729 with annexb=yes.</t>

                <t>When the offer has G729 with annexb=yes and the answer has G729 with annexb=no, the offerer and 
				   answerer MUST proceed as if G729 is negotiated with annexb=no.</t>
            
			    <t>When the offer has G729 with annexb=no, after the offer/answer completion the offerer and answerer 
				   MUST proceed as if G729 is negotiated with annexb=no.</t>

				<t><list style="empty">
				   <t>When the offer has G729 with annexb=no, the reason for not mandating that the answer MUST have annexb=no 
				      for G729 is that there are implementations that omit the annexb parameter in answer. In such case the 
				      offerer and answerer proceed as if G729 is negotiated with annexb=no.</t>
					</list></t>
                
				<t>When the offer has G729 with no annexb parameter and the answer has G729 with annexb=yes, 
				   the offerer and answerer MUST proceed as if G729 is negotiated with annexb=yes.</t>
             </section>
        </section>
		
		<section title="Examples">
			<section title="Offer with G729 annexb=yes and answer with G729 annexb=no">
			<artwork> <![CDATA[
        [Offer with G729 annexb=yes]
		
        v=0
        o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
        s=
        c=IN IP4 host.atlanta.example.com
        t=0 0
        m=audio 49170 RTP/AVP 18
        a=rtpmap:18 G729/8000
        a=fmtp:18 annexb=yes]]> </artwork>
			<artwork> <![CDATA[ 
        [Answer with G729 annexb=no]   

        v=0
        o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com
        s=
        c=IN IP4 host.bangalore.example.com
        t=0 0
        m=audio 19140 RTP/AVP 18
        a=rtpmap:18 G729/8000
        a=fmtp:18 annexb=no]]> </artwork>
			<t>In the above example the offerer and answerer proceed as if G729 is negotiated with annexb=no.</t>
			</section>
			<section title="Offer with G729 annexb=yes and answer with G729 and no annexb parameter">
			<artwork> <![CDATA[
        [Offer with G729 annexb=yes]

        v=0
        o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
        s=
        c=IN IP4 host.atlanta.example.com
        t=0 0
        m=audio 49170 RTP/AVP 18
        a=rtpmap:18 G729/8000
        a=fmtp:18 annexb=yes]]> </artwork>
			<artwork> <![CDATA[
        [Answer with G729 and no annexb parameter]

        v=0
        o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com
        s=
        c=IN IP4 host.bangalore.example.com
        t=0 0
        m=audio 19140 RTP/AVP 18
        a=rtpmap:18 G729/8000]]> </artwork>
			<t>In the above example the offerer and answerer proceed as if G729 is negotiated with annexb=yes.</t>
            </section> 
			<section title="Offer with G729 and no annexb parameter and answer with G729 annexb=no">
			<artwork> <![CDATA[
        [Offer with G729 and no annexb parameter]

        v=0
        o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
        s=
        c=IN IP4 host.atlanta.example.com
        t=0 0
        m=audio 49170 RTP/AVP 18
        a=rtpmap:18 G729/8000]]> </artwork>
			<artwork> <![CDATA[
        [Answer with G729 annexb=no]

        v=0
        o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com
        s=
        c=IN IP4 host.bangalore.example.com
        t=0 0
        m=audio 19140 RTP/AVP 18
        a=rtpmap:18 G729/8000
        a=fmtp:18 annexb=no	]]> </artwork>

		<t>In the above example the offerer and answerer proceed as if G729 is negotiated with annexb=no.</t>
            </section> 
		</section>
		
		<section title="Security Considerations">
			<t>There is no extra security consideration apart from what is described in <xref target="RFC4856"/>.</t>
		</section>
		
		<section title="IANA Considerations" anchor="sec.iana-considerations">
			<t>There is no IANA consideration for this draft.</t>
		</section>
        
		<section title="Acknowledgment">
			<t>Thanks to Flemming Andreasen (Cisco), Miguel A. Garcia (Ericsson), Ali C. Begen (Cisco), Paul Kyzivat (Huawei), 
			Roni Even (Huawei), Kevin Riley (Sonus), Ashish Sharma (Sonus), Kevin P. Fleming (Digium), Dale Worley (Avaya), 
			Cullen Jennings (Cisco), Ari Keranen (Ericsson), Harprit S. Chhatwal (InnoMedia), Aurelien Sollaud (Orange), 
			SM, Stephen Casner and Keith Drage (Alcatel-Lucent) for their valuable inputs and comments. Martin Dolly (ATT) 
			and Hadriel Kaplan (Acme Packet) provided useful suggestions at the mic at IETF-83.</t>
        </section>

	</middle>
	<back>
 		<references title="Normative References">
            <?rfc include="reference.RFC.2119"?>
            <?rfc include="reference.RFC.3264"?>
            <?rfc include="reference.RFC.3551"?>
            <?rfc include="reference.RFC.4566"?>
            <?rfc include="reference.RFC.4856"?>
        </references>
	</back>
</rfc>