栏目搜索
 
 
 
 
你的位置:首页 > 协议大全 > RFC4091 - The Alternative Network Address Types (ANAT) Semantics for the Session Description Protoc… >
 

RFC4091 - The Alternative Network Address Types (ANAT) Semantics for the Session Description Protoc…

发布者:[本站编辑] | 来源:[]

RFC4091 - The Alternative Network Address Types (ANAT) Semantics for the Session Description Protoc…_电脑维修资料库

network working group g. camarillorequest for comments: 4091 ericssoncategory: standards track j. rosenbergcisco systemsjune 2005the alternative network address types (anat) semanticsfor the session description protocol (sdp) grouping frameworkstatus of this memothis document specifies an internet standards track protocol for theinternet community, and requests discussion and suggestions forimprovements. please refer to the current edition of the internetofficial protocol standards (std 1) for the standardization stateand status of this protocol. distribution of this memo is unlimited.copyright noticecopyright (c) the internet society (2005).abstractthis document defines the alternative network address types (anat)semantics for the session description protocol (sdp) groupingframework. the anat semantics allow alternative types of networkaddresses to establish a particular media stream.table of contents1. introduction . . . . . . . . . . . . . . . . . . . . . . . . . 21.1. scope and relation with interactive connectivityestablishment. . . . . . . . . . . . . . . . . . . . . . 22. terminology . . . . . . . . . . . . . . . . . . . . . . . . . 33. anat semantics . . . . . . . . . . . . . . . . . . . . . . . . 34. preference . . . . . . . . . . . . . . . . . . . . . . . . . . 35. offer/answer and anat . . . . . . . . . . . . . . . . . . . . 36. example . . . . . . . . . . . . . . . . . . . . . . . . . . . 47. security considerations . . . . . . . . . . . . . . . . . . . 48. iana considerations . . . . . . . . . . . . . . . . . . . . . 59. references . . . . . . . . . . . . . . . . . . . . . . . . . . 59.1. normative references . . . . . . . . . . . . . . . . . . 59.2. informational references . . . . . . . . . . . . . . . . 51. introductiona session description protocol (sdp) <2> session description containsthe media parameters to be used in establishing a number of mediastreams. for a particular media stream, an sdp session descriptioncontains, among other parameters, the network addresses and the codecto be used in transferring media. sdp allows for a set of codecs permedia stream, but only one network address.the ability to offer a set of network addresses to establish a mediastream is useful in environments with both ipv4-only hosts andipv6-only hosts, for instance.this document defines the alternative network address types (anat)semantics for the sdp grouping framework <4>. the anat semanticsallow for the expression of alternative network addresses (e.g.,different ip versions) for a particular media stream.1.1. scope and relation with interactive connectivity establishmentthe anat semantics are intended to address scenarios that involvedifferent network address types (e.g., different ip versions). theyare not intended to provide alternative transport addresses with thesame network type. systems that need to provide different transportaddresses with the same network type should use the sdp formatdefined in ice (interactive connectivity establishment) <6> instead.ice is used by systems that cannot determine their own transportaddress as seen from the remote end, but that can provide severalpossible alternatives. ice encodes the address that is most likelyto be valid in an 'm' line, and the rest of addresses as a= linesafter that 'm' line. this way, systems that do not support icesimply ignore the a= lines and only use the address in the 'm' line.this achieves good backward compatibility.we have chosen to group 'm' lines with different ip versions at the'm' level (anat semantics) rather than at the a= level (ice format)in order to keep the ipv6 syntax free from ice parameters used forlegacy (ipv4) nats (network address translators). this yields asyntax much closer to vanilla sdp, where ipv6 addresses are definedin their own 'm' line, rather than in parameters belonging to adifferent 'm' line.additionally, ice only allows us to provide a single primary addresswhen the peer does not support ice. the anat semantics avoidrelegating certain types of addresses (e.g., ipv6 addresses) to onlybe a secondary alternate to another address type (e.g., ipv4addresses).furthermore, the separation between anat and ice helps systems thatsupport ipv4 and ipv6 but that do not need to support ice (e.g., amulticast server).2. terminologyin this document, the key words must, must not, required,shall, shall not, should, should not, recommended, notrecommended, may, and optional are to be interpreted asdescribed in bcp 14, rfc 2119 <1> and indicate requirement levels forcompliant implementations.3. anat semanticswe define a new semantics attribute within the sdp groupingframework <4>: anat (alternative network address types).media lines grouped using anat semantics provide alternative networkaddresses of different types for a single logical media stream. theentity creating a session description with an anat group must beready to receive (or send) media over any of the grouped 'm' lines.the anat semantics must not be used to group media streams whosenetwork addresses are of the same type.4. preferencethe entity generating a session description may have an order ofpreference for the alternative network address types offered. theidentifiers of the media streams must be listed in order ofpreference in the group line. for example, in the sessiondescription in section 6, the 'm' line with mid=1 has a higherpreference than the 'm' line with mid=2.5. offer/answer and anatan offerer using sip <3> to send its offer should place the sdp-anatoption-tag <5> in a require header field.an answerer receiving a session description that uses the anatsemantics should use the address with the highest priority itunderstands and set the ports of the rest of the 'm' lines of thegroup to zero.6. examplethe session description below contains an ipv4 address and an ipv6address grouped using anat. the format corresponding to the mappingof ice into sdp <6> can be used in both 'm' lines to provideadditional addresses.v=0o=bob 280744730 28977631 in ip4 host.example.coms=t=0 0a=group:anat 1 2m=audio 25000 rtp/avp 0c=in ip6 2001:db8::1a= a=mid:1m=audio 22334 rtp/avp 0c=in ip4 192.0.2.1a= a=mid:27. security considerationsan attacker adding group lines, using the anat semantics, to an sdpsession description could make an end-point use only one out of allthe streams offered by the remote end, when the intention of theremote-end might have been to establish all the streams.an attacker removing group lines using anat semantics could make anend-point establish a higher number of media streams. if theend-point sends media over all of them, the session bandwidth mayincrease dramatically.it is thus strongly recommended that integrity protection be appliedto the sdp session descriptions. for session descriptions carried insip <3>, s/mime is the natural choice to provide such end-to-endintegrity protection, as described in rfc 3261 <3>. otherapplications may use a different form of integrity protection.8. iana considerationsthe iana has registered the following new 'semantics' attribute forthe sdp grouping framework <4>:semantics token reference--------------------------------- ----- ---------alternative network address types anat anat has been registered in the sdp parameters registry undersemantics for the group sdp attribute.9. references9.1. normative references<1> bradner, s., key words for use in rfcs to indicate requirementlevels, bcp 14, rfc 2119, march 1997.<2> handley, m. and v. jacobson, sdp: session descriptionprotocol, rfc 2327, april 1998.<3> rosenberg, j., schulzrinne, h., camarillo, g., johnston, a.,peterson, j., sparks, r., handley, m., and e. schooler, sip:session initiation protocol, rfc 3261, june 2002.<4> camarillo, g., eriksson, g., holler, j., and h. schulzrinne,grouping of media lines in the session description protocol(sdp), rfc 3388, december 2002.<5> camarillo, g. and j. rosenberg, usage of the sessiondescription protocol (sdp) alternative network address types(anat) semantics in the session initiation protocol (sip), rfc4092, june 2005.9.2. informative references<6> rosenberg, j., interactive connectivity establishment (ice): amethodology for network address translator (nat) traversal formultimedia session establishment protocols, work in progress,february 2005.authors' addressesgonzalo camarilloericssonhirsalantie 11jorvas 02420finlandemail: gonzalo.camarillo@ericsson.comjonathan rosenbergcisco systems600 lanidex plazaparsippany, nj 07054usemail: jdrosen@cisco.comfull copyright statementcopyright (c) the internet society (2005).this document is subject to the rights, licenses and restrictionscontained in bcp 78, and except as set forth therein, the authorsretain all their rights.this document and the information contained herein are provided on anas is basis and the contributor, the organization he/she representsor is sponsored by (if any), the internet society and the internetengineering task force disclaim all warranties, express or implied,including but not limited to any warranty that the use of theinformation herein will not infringe any rights or any impliedwarranties of merchantability or fitness for a particular purpose.intellectual propertythe ietf takes no position regarding the validity or scope of anyintellectual property rights or other rights that might be claimed topertain to the implementation or use of the technology described inthis document or the extent to which any license under such rightsmight or might not be available; nor does it represent that it hasmade any independent effort to identify any such rights. informationon the procedures with respect to rights in rfc documents can befound in bcp 78 and bcp 79.copies of ipr disclosures made to the ietf secretariat and anyassurances of licenses to be made available, or the result of anattempt made to obtain a general license or permission for the use ofsuch proprietary rights by implementers or users of thisspecification can be obtained from the ietf on-line ipr repository athttp://www.ietf.org/ipr.the ietf invites any interested party to bring to its attention anycopyrights, patents or patent applications, or other proprietaryrights that may cover technology that may be required to implementthis standard. please address the information to the ietf at ietf-ipr@ietf.org.acknowledgementfunding for the rfc editor function is currently provided by theinternet society.</t