1%% ``Licensed under the Apache License, Version 2.0 (the "License"); 2%% you may not use this file except in compliance with the License. 3%% You may obtain a copy of the License at 4%% 5%% http://www.apache.org/licenses/LICENSE-2.0 6%% 7%% Unless required by applicable law or agreed to in writing, software 8%% distributed under the License is distributed on an "AS IS" BASIS, 9%% WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 10%% See the License for the specific language governing permissions and 11%% limitations under the License. 12%% 13%% The Initial Developer of the Original Code is Ericsson Utvecklings AB. 14%% Portions created by Ericsson are Copyright 1999, Ericsson Utvecklings 15%% AB. All Rights Reserved.'' 16%% 17%% $Id$ 18%% 19%%---------------------------------------------------------------------- 20%% Purpose: 21%%---------------------------------------------------------------------- 22%% 23%% 24%% Explanaition of the fields in the SDP body 25%% (See RFC 4566 for the complete decription) 26%% 27%% Session descriptions 28%% 29%% v protocol version 30%% o owner/creator and session identifier 31%% s session name (optional) 32%% i session information (optional) 33%% u URI of description (optional) 34%% e email address (optional) 35%% p phone number (optional) 36%% c connection information (optional) 37%% b bandwidth information (optional) 38%% One or more time descriptions ("t=" and "r=" lines; see below) 39%% z time zone adjustment (optional) 40%% k encryption key (optional) 41%% a zero or more session attribute lines (optional) 42%% Zero or more media descriptions 43%% 44%% Time descriptions 45%% 46%% t time the session is active 47%% r zero or more repeat times (optional) 48%% 49%% Media descriptions, if present 50%% 51%% m media name and transport address 52%% i media title (optional) 53%% c connection information - optional if included at session-level 54%% b bandwidth information (optional) 55%% k encryption key (optional) 56%% a zero or more media attribute lines (optional) 57%% 58%% 59%% An example SDP description is: 60%% 61%% v=0 62%% o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 63%% s=SDP Seminar 64%% i=A Seminar on the session description protocol 65%% u=http://www.example.com/seminars/sdp.pdf 66%% e=j.doe@example.com (Jane Doe) 67%% c=IN IP4 224.2.17.12/127 68%% t=2873397496 2873404696 69%% a=recvonly 70%% m=audio 49170 RTP/AVP 0 71%% m=video 51372 RTP/AVP 99 72%% a=rtpmap:99 h263-1998/90000 73%% 74%% 75%%---------------------------------------------------------------------- 76 77-ifndef(megaco_sdp_). 78-define(megaco_sdp_, true). 79 80 81%% =================================================================== 82%% 83%% Protocol Version ("v=") 84%% 85%% v=0 86%% 87%% The "v=" field gives the version of the Session Description 88%% Protocol. This memo defines version 0. There is no minor version 89%% number 90%% 91 92-record(megaco_sdp_v, { 93 version % integer() 94 } 95 ). 96 97 98 99 100%% =================================================================== 101%% 102%% Origin ("o=") 103%% 104%% o=<username> <sess-id> <sess-version> <nettype> <addrtype> 105%% <unicast-address> 106%% 107%% The "o=" field gives the originator of the session (their username 108%% and the address of the user's host) plus a session id and session 109%% version number: 110%% 111%% <username> is the user's login on the originating host, or it is 112%% "-" if the originating host does not support the concept of 113%% user IDs. The <username> MUST NOT contain spaces. 114%% 115%% <sess-id> is a numeric string such that the tuple of <username>, 116%% <sess-id>, <nettype>, <addrtype> and <unicast-address> form a 117%% globally unique identifier for the session. The method of 118%% <sess-id> allocation is up to the creating tool, but it has 119%% been suggested that a Network Time Protocol (NTP) 120%% timestamp be used to ensure uniqueness [13]. 121%% 122%% <sess-version> is a version number for this announcement. Its 123%% usage is up to the creating tool, so long as <sess-version> 124%% is increased when a modification is made to the session data. 125%% Again, it is RECOMMENDED that an NTP format timestamp is used 126%% 127%% <nettype> is a text string giving the type of network. 128%% Initially "IN" is defined to have the meaning "Internet", but 129%% other values MAY be registered in the future (see Section 8 130%% of RFC 4566). 131%% 132%% <addrtype> is a text string giving the type of the address that 133%% follows. Initially "IP4" and "IP6" are defined, but other 134%% values MAY be registered in the future (see Section 8 135%% of RFC 4566). 136%% 137%% <unicast-address> is the address of the machine from which the 138%% session was created. For an address type of IP4, this is 139%% either the fully qualified domain name of the machine or the 140%% dotted-decimal representation of the IP version 4 address of 141%% the machine. For an address type of IP6, this is either the 142%% fully qualified domain name of the machine or the compressed 143%% textual representation of the IP version 6 address of the 144%% machine. For both IP4 and IP6, the fully qualified domain name 145%% is the form that SHOULD be given unless this is unavailable, 146%% in which case the globally unique address MAY be substituted. 147%% A local IP address MUST NOT be used in any context where the 148%% SDP description might leave the scope in which the address is 149%% meaningful (for example, a local address MUST NOT be included 150%% in an application-level referral that might leave the scope). 151%% 152%% In general, the "o=" field serves as a globally unique identifier 153%% for this version of this session description, and the subfields 154%% excepting the version taken together identify the session 155%% irrespective of any modifications. 156%% 157%% For privacy reasons, it is sometimes desirable to obfuscate the 158%% username and IP address of the session originator. If this is a 159%% concern, an arbitrary <username> and private <unicast-address> MAY be 160%% chosen to populate the "o=" field, provided that these are selected 161%% in a manner that does not affect the global uniqueness of the field. 162%% 163%% 164 165-record(megaco_sdp_o, { 166 user_name, % <username> string() 167 session_id, % <sess-id> integer() 168 version, % <sess-version> integer() 169 network_type = in, % <nettype> in | string() 170 address_type = ip4, % <addrtype> ip4 | ip6 | string() 171 address % <unicast-address> string() 172 } 173 ). 174 175 176%% =================================================================== 177%% 178%% Session Name ("s=") 179%% 180%% s=<session name> 181%% 182%% The "s=" field is the textual session name. There MUST be one and 183%% only one "s=" field per session description. The "s=" field MUST 184%% NOT be empty and SHOULD contain ISO 10646 characters (but see also 185%% the "a=charset" attribute). If a session has no meaningful name, 186%% the value "s= " SHOULD be used (i.e., a single space as the session 187%% name). 188%% 189 190-record(megaco_sdp_s, { 191 name % string() 192 } 193 ). 194 195 196 197 198%% =================================================================== 199%% 200%% Session and Media Information ("i=") 201%% 202%% i=<session description> 203%% 204%% The "i=" field provides textual information about the session. 205%% There MUST be at most one session-level "i=" field per session 206%% description, and at most one "i=" field per media. If the 207%% "a=charset" attribute is present, it specifies the character set 208%% used in the "i=" field. If the "a=charset" attribute is not 209%% present, the "i=" field MUST contain ISO 10646 characters in 210%% UTF-8 encoding. 211%% 212%% A single "i=" field MAY also be used for each media definition. 213%% In media definitions, "i=" fields are primarily intended for 214%% labelling media streams. As such, they are most likely to be 215%% useful when a single session has more than one distinct media 216%% stream of the same media type. An example would be two different 217%% whiteboards, one for slides and one for feedback and questions. 218%% 219%% The "i=" field is intended to provide a free-form human-readable 220%% description of the session or the purpose of a media stream. It 221%% is not suitable for parsing by automata. 222%% 223 224-record(megaco_sdp_i, { 225 session_descriptor % string() 226 } 227 ). 228 229 230 231 232%% =================================================================== 233%% 234%% URI ("u=") 235%% 236%% u=<URI> 237%% 238%% A URI is a Uniform Resource Identifier as used by WWW clients [7]. 239%% The URI should be a pointer to additional information about the 240%% session. This field is OPTIONAL, but if it is present it MUST be 241%% specified before the first media field. No more than one URI field 242%% is allowed per session description. 243%% 244 245-record(megaco_sdp_u, { 246 uri % string() 247 } 248 ). 249 250 251 252 253%% =================================================================== 254%% 255%% Email Address and Phone Number ("e=" and "p=") 256%% 257%% e=<email address> 258%% p=<phone number> 259%% 260%% The "e=" and "p=" lines specify contact information for the person 261%% responsible for the conference. This is not necessarily the same 262%% person that created the conference announcement. 263%% 264%% Inclusion of an email address or phone number is OPTIONAL. Note 265%% that the previous version of SDP specified that either an email 266%% field or a phone field MUST be specified, but this was widely 267%% ignored. The change brings the specification into line with 268%% common usage. 269%% 270%% If an email address or phone number is present, it MUST be 271%% specified before the first media field. More than one email or 272%% phone field can be given for a session description. 273%% 274%% Phone numbers SHOULD be given in the form of an international 275%% public telecommunication number (see ITU-T Recommendation E.164) 276%% preceded by a "+". Spaces and hyphens may be used to split up a 277%% phone field to aid readability if desired. For example: 278%% 279%% p=+1 617 555-6011 280%% 281%% Both email addresses and phone numbers can have an OPTIONAL free 282%% text string associated with them, normally giving the name of the 283%% person who may be contacted. This MUST be enclosed in parentheses 284%% if it is present. For example: 285%% 286%% e=j.doe@example.com (Jane Doe) 287%% 288%% The alternative RFC 2822 [29] name quoting convention is also 289%% allowed for both email addresses and phone numbers. For example: 290%% 291%% e=Jane Doe <j.doe@example.com> 292%% 293%% The free text string SHOULD be in the ISO-10646 character set with 294%% UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings 295%% if the appropriate session-level "a=charset" attribute is set. 296%% 297 298-record(megaco_sdp_e, { 299 email % string() 300 } 301 ). 302 303-record(megaco_sdp_p, { 304 phone_number % string() 305 } 306 ). 307 308 309 310 311%% =================================================================== 312%% 313%% Connection Data ("c=") 314%% 315%% c=<nettype> <addrtype> <connection-address> 316%% 317%% The "c=" field contains connection data. 318%% 319%% A session description MUST contain either at least one "c=" field 320%% in each media description or a single "c=" field at the session 321%% level. It MAY contain a single session-level "c=" field and 322%% additional "c=" field(s) per media description, in which case the 323%% per-media values override the session-level settings for the 324%% respective media. 325%% 326%% The first sub-field ("<nettype>") is the network type, which is a 327%% text string giving the type of network. Initially, "IN" is 328%% defined to have the meaning "Internet", but other values MAY be 329%% registered in the future (see Section 8 of RFC 4566). 330%% 331%% The second sub-field ("<addrtype>") is the address type. This 332%% allows SDP to be used for sessions that are not IP based. This 333%% memo only defines IP4 and IP6, but other values MAY be registered 334%% in the future (see Section 8 of RFC 4566). 335%% 336%% The third sub-field ("<connection-address>") is the connection 337%% address. OPTIONAL sub-fields MAY be added after the connection 338%% address depending on the value of the <addrtype> field. 339%% 340%% When the <addrtype> is IP4 and IP6, the connection address is 341%% defined as follows: 342%% 343%% o If the session is multicast, the connection address will be an 344%% IP multicast group address. If the session is not multicast, 345%% then the connection address contains the unicast IP address of 346%% the expected data source or data relay or data sink as 347%% determined by additional attribute fields. It is not expected 348%% that unicast addresses will be given in a session description 349%% that is communicated by a multicast announcement, though this 350%% is not prohibited. 351%% 352%% o Sessions using an IPv4 multicast connection address MUST also 353%% have a time to live (TTL) value present in addition to the 354%% multicast address. The TTL and the address together define the 355%% scope with which multicast packets sent in this conference will 356%% be sent. TTL values MUST be in the range 0-255. Although the 357%% TTL MUST be specified, its use to scope multicast traffic is 358%% deprecated; applications SHOULD use an administratively scoped 359%% address instead. 360%% 361%% The TTL for the session is appended to the address using a slash 362%% as a separator. An example is: 363%% 364%% c=IN IP4 224.2.36.42/127 365%% 366%% IPv6 multicast does not use TTL scoping, and hence the TTL value 367%% MUST NOT be present for IPv6 multicast. It is expected that IPv6 368%% scoped addresses will be used to limit the scope of conferences. 369%% 370%% Hierarchical or layered encoding schemes are data streams where 371%% the encoding from a single media source is split into a number of 372%% layers. The receiver can choose the desired quality (and hence 373%% bandwidth) by only subscribing to a subset of these layers. Such 374%% layered encodings are normally transmitted in multiple multicast 375%% groups to allow multicast pruning. This technique keeps unwanted 376%% traffic from sites only requiring certain levels of the hierarchy. 377%% For applications requiring multiple multicast groups, we allow the 378%% following notation to be used for the connection address: 379%% 380%% <base multicast address>[/<ttl>]/<number of addresses> 381%% 382%% If the number of addresses is not given, it is assumed to be one. 383%% Multicast addresses so assigned are contiguously allocated above 384%% the base address, so that, for example: 385%% 386%% c=IN IP4 224.2.1.1/127/3 387%% 388%% would state that addresses 224.2.1.1, 224.2.1.2, and 224.2.1.3 are 389%% to be used at a TTL of 127. This is semantically identical to 390%% including multiple "c=" lines in a media description: 391%% 392%% c=IN IP4 224.2.1.1/127 393%% c=IN IP4 224.2.1.2/127 394%% c=IN IP4 224.2.1.3/127 395%% 396%% Similarly, an IPv6 example would be: 397%% 398%% c=IN IP6 FF15::101/3 399%% 400%% which is semantically equivalent to: 401%% 402%% c=IN IP6 FF15::101 403%% c=IN IP6 FF15::102 404%% c=IN IP6 FF15::103 405%% 406%% (remembering that the TTL field is not present in IPv6 multicast). 407%% 408%% Multiple addresses or "c=" lines MAY be specified on a per-media 409%% basis only if they provide multicast addresses for different layers 410%% in a hierarchical or layered encoding scheme. They MUST NOT be 411%% specified for a session-level "c=" field. 412%% 413%% The slash notation for multiple addresses described above MUST NOT 414%% be used for IP unicast addresses. 415%% 416 417-record(megaco_sdp_c, { 418 network_type = in, % <nettype> in | string() 419 address_type = ip4, % <addrtype> ip4 | ip6 | string() 420 connection_addr % <connection-address> string() | conn_addr() 421 }). 422 423%% Only if address type = ip4 424%% conn_addr() -> #megaco_sdp_c_conn_addr{} 425-record(megaco_sdp_c_conn_addr, { 426 base, % <base multicast address> string() 427 ttl, % <ttl> integer() 428 num_of % <number of addresses> undefined | integer() 429 }). 430 431 432 433%% =================================================================== 434%% 435%% Bandwidth ("b=") 436%% 437%% b=<bwtype>:<bandwidth> 438%% 439%% This OPTIONAL field denotes the proposed bandwidth to be used by 440%% the session or media. The <bwtype> is an alphanumeric modifier 441%% giving the meaning of the <bandwidth> figure. Two values are 442%% defined in this specification, but other values MAY be registered 443%% in the future (see Section 8 of RFC 4566 and [21], [25]): 444%% 445%% CT If the bandwidth of a session or media in a session is 446%% different from the bandwidth implicit from the scope, a 447%% "b=CT:..." line SHOULD be supplied for the session giving the 448%% proposed upper limit to the bandwidth used (the "conference 449%% total" bandwidth). The primary purpose of this is to give an 450%% approximate idea as to whether two or more sessions can coexist 451%% simultaneously. When using the CT modifier with RTP, if 452%% several RTP sessions are part of the conference, the conference 453%% total refers to total bandwidth of all RTP sessions. 454%% 455%% AS The bandwidth is interpreted to be application specific (it 456%% will be the application's concept of maximum bandwidth). 457%% Normally, this will coincide with what is set on the 458%% application's "maximum bandwidth" control if applicable. For 459%% RTP-based applications, AS gives the RTP "session bandwidth" 460%% as defined in Section 6.2 of [19]. 461%% 462%% Note that CT gives a total bandwidth figure for all the media at 463%% all sites. AS gives a bandwidth figure for a single media at a 464%% single site, although there may be many sites sending 465%% simultaneously. 466%% 467%% A prefix "X-" is defined for <bwtype> names. This is intended 468%% for experimental purposes only. For example: 469%% 470%% b=X-YZ:128 471%% 472%% Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers 473%% SHOULD be registered with IANA in the standard namespace. SDP 474%% parsers MUST ignore bandwidth fields with unknown modifiers. 475%% Modifiers MUST be alphanumeric and, although no length limit is 476%% given, it is recommended that they be short. 477%% 478%% The <bandwidth> is interpreted as kilobits per second by default. 479%% The definition of a new <bwtype> modifier MAY specify that the 480%% bandwidth is to be interpreted in some alternative unit (the "CT" 481%% and "AS" modifiers defined in this memo use the default units). 482%% 483 484%% bwtype() -> ct | as | string() 485-record(megaco_sdp_b, { 486 bwtype, % bwtype() 487 bandwidth % integer() 488 }). 489 490 491 492 493%% =================================================================== 494%% 495%% Times ("t=") 496%% 497%% t=<start time> <stop time> 498%% 499%% The "t=" lines specify the start and stop times for a session. 500%% Multiple "t=" lines MAY be used if a session is active at 501%% multiple irregularly spaced times; each additional "t=" line 502%% specifies an additional period of time for which the session will 503%% be active. If the session is active at regular times, an "r=" 504%% line (see below) should be used in addition to, and following, a 505%% "t=" line -- in which case the "t=" line specifies the start and 506%% stop times of the repeat sequence. 507%% 508%% The first and second sub-fields give the start and stop times, 509%% respectively, for the session. These values are the decimal 510%% representation of Network Time Protocol (NTP) time values in 511%% seconds since 1900 [13]. To convert these values to UNIX time, 512%% subtract decimal 2208988800. 513%% 514%% NTP timestamps are elsewhere represented by 64-bit values, which 515%% wrap sometime in the year 2036. Since SDP uses an arbitrary length 516%% decimal representation, this should not cause an issue (SDP 517%% timestamps MUST continue counting seconds since 1900, NTP will use 518%% the value modulo the 64-bit limit). 519%% 520%% If the <stop-time> is set to zero, then the session is not bounded, 521%% though it will not become active until after the <start-time>. If 522%% the <start-time> is also zero, the session is regarded as 523%% permanent. 524%% 525%% User interfaces SHOULD strongly discourage the creation of 526%% unbounded and permanent sessions as they give no information about 527%% when the session is actually going to terminate, and so make 528%% scheduling difficult. 529%% 530%% The general assumption may be made, when displaying unbounded 531%% sessions that have not timed out to the user, that an unbounded 532%% session will only be active until half an hour from the current 533%% time or the session start time, whichever is the later. If 534%% behaviour other than this is required, an end-time SHOULD be given 535%% and modified as appropriate when new information becomes available 536%% about when the session should really end. 537%% 538%% Permanent sessions may be shown to the user as never being active 539%% unless there are associated repeat times that state precisely when 540%% the session will be active. 541%% 542 543-record(megaco_sdp_t, { 544 start, % integer() 545 stop % integer() 546 }). 547 548 549 550%% =================================================================== 551%% 552%% Repeat Times ("r=") 553%% 554%% r=<repeat interval> <active duration> <offsets from start-time> 555%% 556%% "r=" fields specify repeat times for a session. For example, if a 557%% session is active at 10am on Monday and 11am on Tuesday for one 558%% hour each week for three months, then the <start-time> in the 559%% corresponding "t=" field would be the NTP representation of 10am 560%% on the first Monday, the <repeat interval> would be 1 week, the 561%% <active duration> would be 1 hour, and the offsets would be zero 562%% and 25 hours. The corresponding "t=" field stop time would be 563%% the NTP representation of the end of the last session three months 564%% later. By default, all fields are in seconds, so the "r=" and 565%% "t=" fields might be the following: 566%% 567%% t=3034423619 3042462419 568%% r=604800 3600 0 90000 569%% 570%% To make description more compact, times may also be given in units 571%% of days, hours, or minutes. The syntax for these is a number 572%% immediately followed by a single case-sensitive character. 573%% Fractional units are not allowed -- a smaller unit should be used 574%% instead. The following unit specification characters are allowed: 575%% 576%% d - days (86400 seconds) 577%% h - hours (3600 seconds) 578%% m - minutes (60 seconds) 579%% s - seconds (allowed for completeness) 580%% 581%% Thus, the above session announcement could also have been written: 582%% 583%% r=7d 1h 0 25h 584%% 585%% Monthly and yearly repeats cannot be directly specified with a 586%% single SDP repeat time; instead, separate "t=" fields should be 587%% used to explicitly list the session times. 588%% 589 590-record(megaco_sdp_r, { 591 repeat_interval, % string() 592 active_duration, % string() 593 list_of_offsets % [ string() ] 594 } 595 ). 596 597 598 599%% =================================================================== 600%% 601%% Time Zones ("z=") 602%% 603%% z=<adjustment time> <offset> <adjustment time> <offset> .... 604%% 605%% To schedule a repeated session that spans a change from daylight 606%% saving time to standard time or vice versa, it is necessary to 607%% specify offsets from the base time. This is required because 608%% different time zones change time at different times of day, 609%% different countries change to or from daylight saving time on 610%% different dates, and some countries do not have daylight saving 611%% time at all. 612%% 613%% Thus, in order to schedule a session that is at the same time 614%% winter and summer, it must be possible to specify unambiguously by 615%% whose time zone a session is scheduled. To simplify this task for 616%% receivers, we allow the sender to specify the NTP time that a time 617%% zone adjustment happens and the offset from the time when the 618%% session was first scheduled. The "z=" field allows the sender to 619%% specify a list of these adjustment times and offsets from the base 620%% time. 621%% 622%% An example might be the following: 623%% 624%% z=2882844526 -1h 2898848070 0 625%% 626%% This specifies that at time 2882844526, the time base by which the 627%% session's repeat times are calculated is shifted back by 1 hour, 628%% and that at time 2898848070, the session's original time base is 629%% restored. Adjustments are always relative to the specified start 630%% time -- they are not cumulative. Adjustments apply to all "t=" 631%% and "r=" lines in a session description. 632%% 633%% If a session is likely to last several years, it is expected that 634%% the session announcement will be modified periodically rather than 635%% transmit several years' worth of adjustments in one session 636%% announcement. 637%% 638 639%% adjustment() -> #megaco_sdp_z_adjustement{} 640-record(megaco_sdp_z, { 641 list_of_adjustments % [ adjustment() ] 642 } 643 ). 644 645-record(megaco_sdp_z_adjustement, { 646 time, % string() 647 offset % string() 648 } 649 ). 650 651 652 653 654%% =================================================================== 655%% 656%% Encryption Keys ("k=") 657%% 658%% k=<method> 659%% k=<method>:<encryption key> 660%% 661%% If transported over a secure and trusted channel, the Session 662%% Description Protocol MAY be used to convey encryption keys. A 663%% simple mechanism for key exchange is provided by the key field 664%% ("k="), although this is primarily supported for compatibility 665%% with older implementations and its use is NOT RECOMMENDED. Work 666%% is in progress to define new key exchange mechanisms for use with 667%% SDP [27] [28], and it is expected that new applications will use 668%% those mechanisms. A key field is permitted before the first media 669%% entry (in which case it applies to all media in the session), or 670%% for each media entry as required. The format of keys and their 671%% usage are outside the scope of this document, and the key field 672%% provides no way to indicate the encryption algorithm to be used, 673%% key type, or other information about the key: this is assumed to 674%% be provided by the higher-level protocol using SDP. If there is 675%% a need to convey this information within SDP, the extensions 676%% mentioned previously SHOULD be used. Many security protocols 677%% require two keys: one for confidentiality, another for integrity. 678%% This specification does not support transfer of two keys. 679%% 680%% The method indicates the mechanism to be used to obtain a usable 681%% key by external means, or from the encoded encryption key given. 682%% The following methods are defined: 683%% 684%% k=clear:<encryption key> 685%% 686%% The encryption key is included untransformed in this key 687%% field. This method MUST NOT be used unless it can be 688%% guaranteed that the SDP is conveyed over a secure channel. 689%% The encryption key is interpreted as text according to the 690%% charset attribute; use the "k=base64:" method to convey 691%% characters that are otherwise prohibited in SDP. 692%% 693%% k=base64:<encoded encryption key> 694%% 695%% The encryption key is included in this key field but has 696%% been base64 encoded [12] because it includes characters 697%% that are prohibited in SDP. This method MUST NOT be used 698%% unless it can be guaranteed that the SDP is conveyed over 699%% a secure channel. 700%% 701%% k=uri:<URI to obtain key> 702%% 703%% A Uniform Resource Identifier is included in the key field. 704%% The URI refers to the data containing the key, and may 705%% require additional authentication before the key can be 706%% returned. When a request is made to the given URI, the 707%% reply should specify the encoding for the key. The URI is 708%% often an Secure Socket Layer/Transport Layer Security 709%% (SSL/TLS)-protected HTTP URI ("https:"), although this is 710%% not required. 711%% 712%% k=prompt 713%% 714%% No key is included in this SDP description, but the session 715%% or media stream referred to by this key field is encrypted. 716%% The user should be prompted for the key when attempting to 717%% join the session, and this user-supplied key should then be 718%% used to decrypt the media streams. The use of 719%% user-specified keys is NOT RECOMMENDED, since such keys tend 720%% to have weak security properties. 721%% 722%% The key field MUST NOT be used unless it can be guaranteed that 723%% the SDP is conveyed over a secure and trusted channel. An example 724%% of such a channel might be SDP embedded inside an S/MIME message 725%% or a TLS-protected HTTP session. It is important to ensure that 726%% the secure channel is with the party that is authorised to join the 727%% session, not an intermediary: if a caching proxy server is used, it 728%% is important to ensure that the proxy is either trusted or unable 729%% to access the SDP. 730%% 731 732%% method() -> clear | base64 | uri | prompt 733-record(megaco_sdp_k, { 734 method, % method() | string() 735 encryption_key % undefined | string() 736 } 737 ). 738 739 740%% =================================================================== 741%% 742%% Attributes ("a=") 743%% 744%% a=<attribute> 745%% a=<attribute>:<value> 746%% 747%% Attributes are the primary means for extending SDP. Attributes 748%% may be defined to be used as "session-level" attributes, 749%% "media-level" attributes, or both. 750%% 751%% A media description may have any number of attributes ("a=" 752%% fields) that are media specific. These are referred to as 753%% "media-level" attributes and add information about the media 754%% stream. Attribute fields can also be added before the first 755%% media field; these "session-level" attributes convey additional 756%% information that applies to the conference as a whole rather than 757%% to individual media. 758%% 759%% Attribute fields may be of two forms: 760%% 761%% o A property attribute is simply of the form "a=<flag>". These 762%% are binary attributes, and the presence of the attribute 763%% conveys that the attribute is a property of the session. An 764%% example might be "a=recvonly". 765%% 766%% o A value attribute is of the form "a=<attribute>:<value>". For 767%% example, a whiteboard could have the value attribute "a=orient: 768%% landscape" 769%% 770%% Attribute interpretation depends on the media tool being invoked. 771%% Thus receivers of session descriptions should be configurable in 772%% their interpretation of session descriptions in general and of 773%% attributes in particular. 774%% 775%% Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. 776%% 777%% Attribute values are octet strings, and MAY use any octet value 778%% except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, 779%% attribute values are to be interpreted as in ISO-10646 character 780%% set with UTF-8 encoding. Unlike other text fields, attribute 781%% values are NOT normally affected by the "charset" attribute as 782%% this would make comparisons against known values problematic. 783%% However, when an attribute is defined, it can be defined to be 784%% charset dependent, in which case its value should be interpreted 785%% in the session charset rather than in ISO-10646. 786%% 787%% Attributes MUST be registered with IANA (see Section 8 of RFC 788%% 4566). If an attribute is received that is not understood, it 789%% MUST be ignored by the receiver. 790%% 791%% SDP Attributes 792%% 793%% The following attributes are defined. Since application writers 794%% may add new attributes as they are required, this list is not 795%% exhaustive. Registration procedures for new attributes are defined 796%% in Section 8.2.4 of RFC 4566. 797%% 798%% a=cat:<category> 799%% 800%% This attribute gives the dot-separated hierarchical category 801%% of the session. This is to enable a receiver to filter 802%% unwanted sessions by category. There is no central registry 803%% of categories. It is a session-level attribute, and it is 804%% not dependent on charset. 805%% 806%% a=keywds:<keywords> 807%% 808%% Like the cat attribute, this is to assist identifying wanted 809%% sessions at the receiver. This allows a receiver to select 810%% interesting session based on keywords describing the purpose 811%% of the session; there is no central registry of keywords. It 812%% is a session-level attribute. It is a charset-dependent 813%% attribute, meaning that its value should be interpreted in the 814%% charset specified for the session description if one is 815%% specified, or by default in ISO 10646/UTF-8. 816%% 817%% a=tool:<name and version of tool> 818%% 819%% This gives the name and version number of the tool used to 820%% create the session description. It is a session-level 821%% attribute, and it is not dependent on charset. 822%% 823%% a=ptime:<packet time> 824%% 825%% This gives the length of time in milliseconds represented by 826%% the media in a packet. This is probably only meaningful for 827%% audio data, but may be used with other media types if it 828%% makes sense. It should not be necessary to know ptime to 829%% decode RTP or vat audio, and it is intended as a 830%% recommendation for the encoding/packetisation of audio. It 831%% is a media-level attribute, and it is not dependent on charset. 832%% 833%% a=maxptime:<maximum packet time> 834%% 835%% This gives the maximum amount of media that can be encapsulated 836%% in each packet, expressed as time in milliseconds. The time 837%% SHALL be calculated as the sum of the time the media present in 838%% the packet represents. For frame-based codecs, the time SHOULD 839%% be an integer multiple of the frame size. This attribute is 840%% probably only meaningful for audio data, but may be used with 841%% other media types if it makes sense. It is a media-level 842%% attribute, and it is not dependent on charset. Note that this 843%% attribute was introduced after RFC 2327, and non-updated 844%% implementations will ignore this attribute. 845%% 846%% a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding 847%% parameters>] 848%% 849%% This attribute maps from an RTP payload type number (as used in 850%% an "m=" line) to an encoding name denoting the payload format 851%% to be used. It also provides information on the clock rate and 852%% encoding parameters. It is a media-level attribute that is not 853%% dependent on charset. 854%% 855%% Although an RTP profile may make static assignments of payload 856%% type numbers to payload formats, it is more common for that 857%% assignment to be done dynamically using "a=rtpmap:" attributes. 858%% As an example of a static payload type, consider u-law PCM 859%% coded single-channel audio sampled at 8 kHz. This is 860%% completely defined in the RTP Audio/Video profile as payload 861%% type 0, so there is no need for an "a=rtpmap:" attribute, and 862%% the media for such a stream sent to UDP port 49232 can be 863%% specified as: 864%% 865%% m=audio 49232 RTP/AVP 0 866%% 867%% An example of a dynamic payload type is 16-bit linear encoded 868%% stereo audio sampled at 16 kHz. If we wish to use the dynamic 869%% RTP/AVP payload type 98 for this stream, additional 870%% information is required to decode it: 871%% 872%% m=audio 49232 RTP/AVP 98 873%% a=rtpmap:98 L16/16000/2 874%% 875%% Up to one rtpmap attribute can be defined for each media 876%% format specified. Thus, we might have the following: 877%% 878%% m=audio 49230 RTP/AVP 96 97 98 879%% a=rtpmap:96 L8/8000 880%% a=rtpmap:97 L16/8000 881%% a=rtpmap:98 L16/11025/2 882%% 883%% RTP profiles that specify the use of dynamic payload types 884%% MUST define the set of valid encoding names and/or a means to 885%% register encoding names if that profile is to be used with 886%% SDP. The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes 887%% for encoding names, under the top-level media type denoted in 888%% the "m=" line. In the example above, the media types are 889%% "audio/l8" and "audio/l16". 890%% 891%% For audio streams, <encoding parameters> indicates the number 892%% of audio channels. This parameter is OPTIONAL and may be 893%% omitted if the number of channels is one, provided that no 894%% additional parameters are needed. 895%% 896%% For video streams, no encoding parameters are currently 897%% specified. 898%% 899%% Additional encoding parameters MAY be defined in the future, 900%% but codec-specific parameters SHOULD NOT be added. 901%% Parameters added to an "a=rtpmap:" attribute SHOULD only be 902%% those required for a session directory to make the choice of 903%% appropriate media to participate in a session. Codec-specific 904%% parameters should be added in other attributes (for example, 905%% "a=fmtp:"). 906%% 907%% Note: RTP audio formats typically do not include information 908%% about the number of samples per packet. If a non-default (as 909%% defined in the RTP Audio/Video Profile) packetisation is 910%% required, the "ptime" attribute is used as given above. 911%% 912%% a=recvonly 913%% 914%% This specifies that the tools should be started in 915%% receive-only mode where applicable. It can be either a 916%% session- or media-level attribute, and it is not dependent 917%% on charset. Note that recvonly applies to the media only, 918%% not to any associated control protocol (e.g., an RTP-based 919%% system in recvonly mode SHOULD still send RTCP packets). 920%% 921%% a=sendrecv 922%% 923%% This specifies that the tools should be started in send and 924%% receive mode. This is necessary for interactive conferences 925%% with tools that default to receive-only mode. It can be 926%% either a session or media-level attribute, and it is not 927%% dependent on charset. 928%% 929%% If none of the attributes "sendonly", "recvonly", "inactive", 930%% and "sendrecv" is present, "sendrecv" SHOULD be assumed as 931%% the default for sessions that are not of the conference type 932%% "broadcast" or "H332" (see below). 933%% 934%% a=sendonly 935%% 936%% This specifies that the tools should be started in send-only 937%% mode. An example may be where a different unicast address is 938%% to be used for a traffic destination than for a traffic 939%% source. In such a case, two media descriptions may be used, 940%% one sendonly and one recvonly. It can be either a session- 941%% or media-level attribute, but would normally only be used as 942%% a media attribute. It is not dependent on charset. Note 943%% that sendonly applies only to the media, and any associated 944%% control protocol (e.g., RTCP) SHOULD still be received and 945%% processed as normal. 946%% 947%% a=inactive 948%% 949%% This specifies that the tools should be started in inactive 950%% mode. This is necessary for interactive conferences where 951%% users can put other users on hold. No media is sent over an 952%% inactive media stream. Note that an RTP-based system SHOULD 953%% still send RTCP, even if started inactive. It can be either 954%% a session or media-level attribute, and it is not dependent 955%% on charset. 956%% 957%% a=orient:<orientation> 958%% 959%% Normally this is only used for a whiteboard or presentation 960%% tool. It specifies the orientation of a the workspace on 961%% the screen. It is a media-level attribute. Permitted 962%% values are "portrait", "landscape", and "seascape" 963%% (upside-down landscape). It is not dependent on charset. 964%% 965%% a=type:<conference type> 966%% 967%% This specifies the type of the conference. Suggested 968%% values are "broadcast", "meeting", "moderated", "test", and 969%% "H332". "recvonly" should be the default for 970%% "type:broadcast" sessions, "type:meeting" should imply 971%% "sendrecv", and "type:moderated" should indicate the use of 972%% a floor control tool and that the media tools are started 973%% so as to mute new sites joining the conference. 974%% 975%% Specifying the attribute "type:H332" indicates that this 976%% loosely coupled session is part of an H.332 session as 977%% defined in the ITU H.332 specification [26]. Media tools 978%% should be started "recvonly". 979%% 980%% Specifying the attribute "type:test" is suggested as a hint 981%% that, unless explicitly requested otherwise, receivers can 982%% safely avoid displaying this session description to users. 983%% 984%% The type attribute is a session-level attribute, and it is 985%% not dependent on charset. 986%% 987%% a=charset:<character set> 988%% 989%% This specifies the character set to be used to display the 990%% session name and information data. By default, the 991%% ISO-10646 character set in UTF-8 encoding is used. If a 992%% more compact representation is required, other character 993%% sets may be used. For example, the ISO 8859-1 is specified 994%% with the following SDP attribute: 995%% 996%% a=charset:ISO-8859-1 997%% 998%% This is a session-level attribute and is not dependent on 999%% charset. The charset specified MUST be one of those 1000%% registered with IANA, such as ISO-8859-1. The character 1001%% set identifier is a US-ASCII string and MUST be compared 1002%% against the IANA identifiers using a case-insensitive 1003%% comparison. If the identifier is not recognised or not 1004%% supported, all strings that are affected by it SHOULD be 1005%% regarded as octet strings. 1006%% 1007%% Note that a character set specified MUST still prohibit 1008%% the use of bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). 1009%% Character sets requiring the use of these characters MUST 1010%% define a quoting mechanism that prevents these bytes from 1011%% appearing within text fields. 1012%% 1013%% a=sdplang:<language tag> 1014%% 1015%% This can be a session-level attribute or a media-level 1016%% attribute. As a session-level attribute, it specifies the 1017%% language for the session description. As a media-level 1018%% attribute, it specifies the language for any media-level 1019%% SDP information field associated with that media. Multiple 1020%% sdplang attributes can be provided either at session or 1021%% media level if multiple languages in the session description 1022%% or media use multiple languages, in which case the order of 1023%% the attributes indicates the order of importance of the 1024%% various languages in the session or media from most important 1025%% to least important. 1026%% 1027%% In general, sending session descriptions consisting of 1028%% multiple languages is discouraged. Instead, multiple 1029%% descriptions SHOULD be sent describing the session, one in 1030%% each language. However, this is not possible with all 1031%% transport mechanisms, and so multiple sdplang attributes 1032%% are allowed although NOT RECOMMENDED. 1033%% 1034%% The "sdplang" attribute value must be a single RFC 3066 1035%% language tag in US-ASCII [9]. It is not dependent on the 1036%% charset attribute. An "sdplang" attribute SHOULD be 1037%% specified when a session is of sufficient scope to cross 1038%% geographic boundaries where the language of recipients 1039%% cannot be assumed, or where the session is in a different 1040%% language from the locally assumed norm. 1041%% 1042%% a=lang:<language tag> 1043%% 1044%% This can be a session-level attribute or a media-level 1045%% attribute. As a session-level attribute, it specifies the 1046%% default language for the session being described. As a 1047%% media-level attribute, it specifies the language for that 1048%% media, overriding any session-level language specified. 1049%% Multiple lang attributes can be provided either at session 1050%% or media level if the session description or media use 1051%% multiple languages, in which case the order of the 1052%% attributes indicates the order of importance of the various 1053%% languages in the session or media from most important to 1054%% least important. 1055%% 1056%% The "lang" attribute value must be a single RFC 3066 1057%% language tag in US-ASCII [9]. It is not dependent on the 1058%% charset attribute. A "lang" attribute SHOULD be specified 1059%% when a session is of sufficient scope to cross geographic 1060%% boundaries where the language of recipients cannot be 1061%% assumed, or where the session is in a different language 1062%% from the locally assumed norm. 1063%% 1064%% a=framerate:<frame rate> 1065%% 1066%% This gives the maximum video frame rate in frames/sec. 1067%% It is intended as a recommendation for the encoding of 1068%% video data. Decimal representations of fractional values 1069%% using the notation "<integer>.<fraction>" are allowed. It 1070%% is a media-level attribute, defined only for video media, 1071%% and it is not dependent on charset. 1072%% 1073%% a=quality:<quality> 1074%% 1075%% This gives a suggestion for the quality of the encoding 1076%% as an integer value. The intention of the quality 1077%% attribute for video is to specify a non-default trade-off 1078%% between frame-rate and still-image quality. For video, 1079%% the value is in the range 0 to 10, with the following 1080%% suggested meaning: 1081%% 1082%% 10 - the best still-image quality the compression 1083%% scheme can give. 1084%% 5 - the default behaviour given no quality suggestion. 1085%% 0 - the worst still-image quality the codec designer 1086%% thinks is still usable. 1087%% 1088%% It is a media-level attribute, and it is not dependent on 1089%% charset. 1090%% 1091%% a=fmtp:<format> <format specific parameters> 1092%% 1093%% This attribute allows parameters that are specific to a 1094%% particular format to be conveyed in a way that SDP does 1095%% not have to understand them. The format must be one of 1096%% the formats specified for the media. Format-specific 1097%% parameters may be any set of parameters required to be 1098%% conveyed by SDP and given unchanged to the media tool that 1099%% will use this format. At most one instance of this 1100%% attribute is allowed for each format. 1101%% 1102%% It is a media-level attribute, and it is not dependent on 1103%% charset. 1104%% 1105 1106 1107%% a=<attribute> 1108%% a=<attribute>:<value> 1109-record(megaco_sdp_a, { 1110 attribute, % string() 1111 value % undefined | string() 1112 } 1113 ). 1114 1115%% a=cat:<category> 1116-record(megaco_sdp_a_cat, { 1117 category % string() 1118 } 1119 ). 1120 1121%% a=keywds:<keywords> 1122-record(megaco_sdp_a_keywds, { 1123 keywords % string() 1124 } 1125 ). 1126 1127%% a=tool:<name and version of tool> 1128-record(megaco_sdp_a_tool, { 1129 name_and_version % string() 1130 } 1131 ). 1132 1133%% a=ptime:<packet time> 1134-record(megaco_sdp_a_ptime, { 1135 packet_time % integer() 1136 } 1137 ). 1138 1139%% a=maxptime:<maximum packet time> 1140-record(megaco_sdp_a_maxptime, { 1141 maximum_packet_time % integer() 1142 } 1143 ). 1144 1145%% a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding parameters>] 1146-record(megaco_sdp_a_rtpmap, { 1147 payload_type, % <payload type> integer() 1148 encoding_name, % <encoding name> string() 1149 clock_rate, % <clock rate> integer() 1150 encoding_parms = [] % <encoding parameters> [ string() ] 1151 } 1152 ). 1153 1154%% a=orient:<orientation> 1155%% orientation() -> portrait | landscape | seascape 1156-record(megaco_sdp_a_orient, { 1157 orientation % orientation() 1158 } 1159 ). 1160 1161 1162%% a=type:<conference type> 1163-record(megaco_sdp_a_type, { 1164 conf_type % string() 1165 } 1166 ). 1167 1168 1169%% a=charset:<character set> 1170-record(megaco_sdp_a_charset, { 1171 char_set % string() 1172 } 1173 ). 1174 1175 1176%% a=sdplang:<language tag> 1177-record(megaco_sdp_a_sdplang, { 1178 tag % string() 1179 } 1180 ). 1181 1182 1183%% a=lang:<language tag> 1184-record(megaco_sdp_a_lang, { 1185 tag % string() 1186 } 1187 ). 1188 1189 1190%% a=framerate:<frame rate> 1191-record(megaco_sdp_a_framerate, { 1192 frame_rate % string() 1193 } 1194 ). 1195 1196 1197%% a=quality:<quality> 1198-record(megaco_sdp_a_quality, { 1199 quality % integer() 1200 } 1201 ). 1202 1203 1204%% a=fmtp:<format> <format specific parameters> 1205-record(megaco_sdp_a_fmtp, { 1206 format, % string() 1207 param % string() 1208 } 1209 ). 1210 1211 1212 1213 1214%% =================================================================== 1215%% 1216%% Media Announcements ("m=") 1217%% 1218%% m=<media> <port> <proto> <fmt> ... 1219%% 1220%% A session description may contain a number of media descriptions. 1221%% Each media description starts with an "m=" field and is terminated 1222%% by either the next "m=" field or by the end of the session 1223%% description. A media field has several sub-fields: 1224%% 1225%% <media> is the media type. Currently defined media are "audio", 1226%% "video", "text", "application", and "message", although this 1227%% list may be extended in the future (see Section 8 of RFC 4566). 1228%% 1229%% <port> is the transport port to which the media stream is sent. 1230%% The meaning of the transport port depends on the network being 1231%% used as specified in the relevant "c=" field, and on the 1232%% transport protocol defined in the <proto> sub-field of the 1233%% media field. Other ports used by the media application (such as 1234%% the RTP Control Protocol (RTCP) port [19]) MAY be derived 1235%% algorithmically from the base media port or MAY be specified in 1236%% a separate attribute (for example, "a=rtcp:" as defined in 1237%% [22]). 1238%% 1239%% If non-contiguous ports are used or if they don't follow the 1240%% parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" 1241%% attribute MUST be used. Applications that are requested to send 1242%% media to a <port> that is odd and where the "a=rtcp:" is present 1243%% MUST NOT subtract 1 from the RTP port: that is, they MUST send 1244%% the RTP to the port indicated in <port> and send the RTCP to the 1245%% port indicated in the "a=rtcp" attribute. 1246%% 1247%% For applications where hierarchically encoded streams are being 1248%% sent to a unicast address, it may be necessary to specify 1249%% multiple transport ports. This is done using a similar notation 1250%% to that used for IP multicast addresses in the "c=" field: 1251%% 1252%% m=<media> <port>/<number of ports> <proto> <fmt> ... 1253%% 1254%% In such a case, the ports used depend on the transport protocol. 1255%% For RTP, the default is that only the even-numbered ports are 1256%% used for data with the corresponding one-higher odd ports used 1257%% for the RTCP belonging to the RTP session, and the 1258%% <number of ports> denoting the number of RTP sessions. For 1259%% example: 1260%% 1261%% m=video 49170/2 RTP/AVP 31 1262%% 1263%% would specify that ports 49170 and 49171 form one RTP/RTCP pair 1264%% and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is 1265%% the transport protocol and 31 is the format (see below). If 1266%% non-contiguous ports are required, they must be signalled using 1267%% a separate attribute (for example, "a=rtcp:" as defined in 1268%% [22]). 1269%% 1270%% If multiple addresses are specified in the "c=" field and 1271%% multiple ports are specified in the "m=" field, a one-to-one 1272%% mapping from port to the corresponding address is implied. For 1273%% example: 1274%% 1275%% c=IN IP4 224.2.1.1/127/2 1276%% m=video 49170/2 RTP/AVP 31 1277%% 1278%% would imply that address 224.2.1.1 is used with ports 49170 1279%% and 49171, and address 224.2.1.2 is used with ports 49172 and 1280%% 49173. 1281%% 1282%% The semantics of multiple "m=" lines using the same transport 1283%% address are undefined. This implies that, unlike limited past 1284%% practice, there is no implicit grouping defined by such means 1285%% and an explicit grouping framework (for example, [18]) should 1286%% instead be used to express the intended semantics. 1287%% 1288%% <proto> is the transport protocol. The meaning of the transport 1289%% protocol is dependent on the address type field in the 1290%% relevant "c=" field. Thus a "c=" field of IP4 indicates that 1291%% the transport protocol runs over IP4. The following transport 1292%% protocols are defined, but may be extended through 1293%% registration of new protocols with IANA (see Section 8 of RFC 1294%% 4566): 1295%% 1296%% * udp: denotes an unspecified protocol running over UDP. 1297%% 1298%% * RTP/AVP: denotes RTP [19] used under the RTP Profile for 1299%% Audio and Video Conferences with Minimal Control [20] 1300%% running over UDP. 1301%% 1302%% * RTP/SAVP: denotes the Secure Real-time Transport Protocol 1303%% [23] running over UDP. 1304%% 1305%% The main reason to specify the transport protocol in addition 1306%% to the media format is that the same standard media formats 1307%% may be carried over different transport protocols even when 1308%% the network protocol is the same -- a historical example is 1309%% vat Pulse Code Modulation (PCM) audio and RTP PCM audio; 1310%% another might be TCP/RTP PCM audio. In addition, relays and 1311%% monitoring tools that are transport-protocol-specific but 1312%% format-independent are possible. 1313%% 1314%% <fmt> is a media format description. The fourth and any 1315%% subsequent sub-fields describe the format of the media. The 1316%% interpretation of the media format depends on the value of 1317%% the <proto> sub-field. 1318%% 1319%% If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt> 1320%% sub-fields contain RTP payload type numbers. When a list of 1321%% payload type numbers is given, this implies that all of these 1322%% payload formats MAY be used in the session, but the first of 1323%% these formats SHOULD be used as the default format for the 1324%% session. For dynamic payload type assignments the "a=rtpmap:" 1325%% attribute (see Section 6 of RFC 4566) SHOULD be used to map 1326%% from an RTP payload type number to a media encoding name that 1327%% identifies the payload format. The "a=fmtp:" attribute MAY 1328%% be used to specify format parameters (see Section 6 of RFC 1329%% 4566). 1330%% 1331%% If the <proto> sub-field is "udp" the <fmt> sub-fields MUST 1332%% reference a media type describing the format under the 1333%% "audio", "video", "text", "application", or "message" 1334%% top-level media types. The media type registration SHOULD 1335%% define the packet format for use with UDP transport. 1336%% 1337%% For media using other transport protocols, the <fmt> field is 1338%% protocol specific. Rules for interpretation of the <fmt> sub- 1339%% field MUST be defined when registering new protocols (see 1340%% Section 8.2.2 of RFC 4566). 1341%% 1342 1343%% ma_media() -> audio | video | application | data | control 1344-record(megaco_sdp_m, { 1345 media, % ma_media() | string() 1346 port, % integer() 1347 num_ports, % undefined | integer() 1348 transport, % string() 1349 fmt_list = [] % [ string() ] 1350 }). 1351 1352 1353 1354 1355%% =================================================================== 1356%% 1357%% References 1358%% 1359%% Normative References 1360%% 1361%% [1] Mockapetris, P., "Domain names - concepts and facilities", STD 1362%% 13, RFC 1034, November 1987. 1363%% 1364%% [2] Mockapetris, P., "Domain names - implementation and 1365%% specification", STD 13, RFC 1035, November 1987. 1366%% 1367%% [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1368%% Levels", BCP 14, RFC 2119, March 1997. 1369%% 1370%% [4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1371%% Specifications: ABNF", RFC 4234, October 2005. 1372%% 1373%% [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 1374%% 63, RFC 3629, November 2003. 1375%% 1376%% [6] Handley, M. and V. Jacobson, "SDP: Session Description 1377%% Protocol", RFC 2327, April 1998. 1378%% 1379%% [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1380%% Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 1381%% January 2005. 1382%% 1383%% [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1384%% Considerations Section in RFCs", BCP 26, RFC 2434, October 1385%% 1998. 1386%% 1387%% [9] Alvestrand, H., "Tags for the Identification of Languages", BCP 1388%% 47, RFC 3066, January 2001. 1389%% 1390%% [10] Olson, S., Camarillo, G., and A. Roach, "Support for IPv6 in 1391%% Session Description Protocol (SDP)", RFC 3266, June 2002. 1392%% 1393%% [11] Faltstrom, P., Hoffman, P., and A. Costello, 1394%% "Internationalizing Domain Names in Applications (IDNA)", RFC 1395%% 3490, March 2003. 1396%% 1397%% [12] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 1398%% RFC 3548, July 2003. 1399%% 1400%% 1401%% Informative References 1402%% 1403%% [13] Mills, D., "Network Time Protocol (Version 3) Specification, 1404%% Implementation", RFC 1305, March 1992. 1405%% 1406%% [14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement 1407%% Protocol", RFC 2974, October 2000. 1408%% 1409%% [15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1410%% Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1411%% Session Initiation Protocol", RFC 3261, June 2002. 1412%% 1413%% [16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming 1414%% Protocol (RTSP)", RFC 2326, April 1998. 1415%% 1416%% [17] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1417%% Session Description Protocol (SDP)", RFC 3264, June 2002. 1418%% 1419%% [18] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, 1420%% "Grouping of Media Lines in the Session Description Protocol 1421%% (SDP)", RFC 3388, December 2002. 1422%% 1423%% [19] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1424%% "RTP: A Transport Protocol for Real-Time Applications", STD 64, 1425%% RFC 3550, July 2003. 1426%% 1427%% [20] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 1428%% Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 1429%% 1430%% [21] Casner, S., "Session Description Protocol (SDP) Bandwidth 1431%% Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, 1432%% July 2003. 1433%% 1434%% [22] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 1435%% Session Description Protocol (SDP)", RFC 3605, October 2003. 1436%% 1437%% [23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1438%% Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 1439%% 3711, March 2004. 1440%% 1441%% [24] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 1442%% User Agent Capabilities in the Session Initiation Protocol 1443%% (SIP)", RFC 3840, August 2004. 1444%% 1445%% [25] Westerlund, M., "A Transport Independent Bandwidth Modifier for 1446%% the Session Description Protocol (SDP)", RFC 3890, September 1447%% 2004. 1448%% 1449%% [26] International Telecommunication Union, "H.323 extended for 1450%% loosely coupled conferences", ITU Recommendation H.332, 1451%% September 1998. 1452%% 1453%% [27] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1454%% Norrman, "Key Management Extensions for Session Description 1455%% Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 1456%% 4567, July 2006. 1457%% 1458%% [28] Andreasen, F., Baugher, M., and D. Wing, "Session Description 1459%% Protocol (SDP) Security Descriptions for Media Streams", RFC 1460%% 4568, July 2006. 1461%% 1462%% [29] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 1463%% 1464%% [30] Hinden, R. and S. Deering, "IP Version 6 Addressing 1465%% Architecture", RFC 2373, July 1998. 1466%% 1467%% [31] Freed, N. and J. Klensin, "Media Type Specifications and 1468%% Registration Procedures", BCP 13, RFC 4288, December 2005. 1469%% 1470 1471 1472-endif. 1473