idnits 2.17.1 draft-ietf-mmusic-sip-caller-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 84: '...pecification, it MUST include a Requir...' RFC 2119 keyword, line 125: '...ferences. A server for a callee SHOULD...' RFC 2119 keyword, line 300: '... A server SHOULD NOT be aware of the...' RFC 2119 keyword, line 307: '...case, the server MAY elect to follow t...' RFC 2119 keyword, line 312: '... SHOULD NOT proxy or redirect to a c...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 426 has weird spacing: '...c value in t...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 26, 1999) is 9191 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 633 looks like a reference -- Missing reference section? '2' on line 636 looks like a reference -- Missing reference section? '3' on line 640 looks like a reference -- Missing reference section? '4' on line 644 looks like a reference -- Missing reference section? '5' on line 648 looks like a reference -- Missing reference section? '0' on line 246 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force MMUSIC WG 3 Internet Draft Schulzrinne/Rosenberg 4 draft-ietf-mmusic-sip-caller-00.txt Columbia U./Bell Laboratories 5 February 26, 1999 6 Expires: August 26, 1999 8 SIP Caller Preferences and Callee Capabilities 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as work in progress. 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document describes a set of extensions to SIP which allow a 34 caller to express preferences about request handling in servers. It 35 also extends the SIP Contact header to allow users to describe their 36 communications capabilities and characteristics. 38 1 Terminology 40 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 41 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 42 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 43 indicate requirement levels for compliant SIP implementations. 45 2 Introduction 47 When a SIP server receives a request, there are a number of decisions 48 it can make regarding processing of the request. These include 50 o whether to proxy or redirect the request; 52 o which URIs to proxy or redirect to; 54 o whether to fork or not; 56 o whether to search recursively or not; 58 o whether to search in parallel or sequentially; 60 o whether to return just the first 200-class response, or all 61 2xx responses. 63 The server can base these decisions on a large number of factors, 64 such as time of day, caller or callee identity, call urgency, caller 65 preferences, network status, and the content of external databases. 67 There are three parties which have an interest in influencing the 68 call processing logic at the server: (1) the administrator of the 69 server, (2) the callee, and (3) the caller. The directives of the 70 administrator are usually embedded in the configuration of the 71 server, and can be expressed, for example, in the form of SIP CGI 72 scripts [2]. The preferences of the callee can be expressed most 73 easily through a script written in the call processing language (CPL) 74 [3]. This document specifies SIP extensions which express caller 75 preferences and describe callee capabilities by adding three new 76 header fields (Request-Disposition, Accept-Contact, Reject-Contact) 77 and extending the parameter list for the Contact header field. 79 This draft is the result of partitioning the SIP call 80 control extensions draft [4] into two components, this one 81 and another on third-party call control, to be issued. 83 If the client wants to be sure that the server understands the 84 headers described in this specification, it MUST include a Require 85 option of org.ietf.sip.caller-preferences. 87 Since the Accept-Contact and Request-Disposition header are advisory 88 only, a client can save an extra round-trip time if it only includes 89 the Require option if the Reject-Contact header is present. 91 3 Design Alternatives 93 There are a number of alternatives for expressing caller preferences. 94 Caller preferences and callee preferences must "meet" at the proxy or 95 redirect server responsible for the callee, so that the appropriate 96 forwarding decision can be made. This server will always be under the 97 control of the callee or an entity trusted by the callee, so that 98 installing a call processing language script expressing caller 99 preferences is not appropriate (unless, of course, the callee would 100 like to accomodate the known preferences of a certain caller). 101 Uploading a caller preference script to every possible server is also 102 clearly not feasible. As another alternative, one could embed a 103 script in the request, to be executed by proxy or redirect servers 104 when making forwarding decisions. This would be an application-layer 105 version of active networks. However, the generality of a script does 106 not seem to be needed. It also makes combining caller and callee 107 preferences a rather difficult problem and raises possible 108 performance and security issues. Unlike the callee script, which 109 needs to handle unknown callers, with a wide range of call 110 properties, at unknown times in the future, a caller knows all but 111 the set of communications capabilities of the callee. The caller can 112 present the servers with its preferences on a call-by-call basis. 113 Callers can thus place their preferences for this particular call in 114 the request message. We propose a simple ordered list of preferences 115 to make it possible to reconcile caller and callee preferences 116 algorithmically. 118 In summary, there is a strong asymmetry in how preferences for 119 callers and callees can be presented to the network. While a caller 120 takes an active role by initiating the call, the callee takes a 121 passive role in waiting for calls. This motivates the use of callee- 122 supplied scripts and caller preferences included in the call request. 124 This asymmetry is also reflected in the appropriate relationship 125 between caller and callee preferences. A server for a callee SHOULD 126 respect the wishes of the caller to avoid certain locations, while 127 the preferences among locations has to be the callee's choice, as it 128 determines where, for example, the phone rings and whether the callee 129 incurs mobile telephone charges for incoming calls. 131 The problem of feature negotation has also been approached in a more 132 general way by [5]. However, that proposal is far more complicated 133 than appears to be needed here, with syntax that does not fit into 134 the current SIP syntax structure. 136 4 Overview 138 The extension specified in this document consists of three new header 139 fields: Reject-Contact, Accept-Contact, and Request-Disposition. The 140 first two express preferences about which URIs the client would like 141 the request to reach. The Reject-Contact header field (Section 6.3) 142 contains a list of URIs the user does not wish the request to be 143 proxied (or redirected) to. The Accept-Contact header field (Section 144 6.2) is a list of addresses that the caller would like to be proxied 145 (or redirected) to, with the strength of preferences expressed 146 through a q parameter, ranging in value from zero to one, with one 147 indicating the highest preference. The Request-Disposition header 148 field (Section 6.4) contains a set of tags which request particular 149 processing for this request, such as whether or not the caller 150 prefers proxy or redirection. 152 5 Determining Request Forwarding 154 The Accept-Contact header field indicates preferences for certain 155 destinations among those chosen by a proxy server. The Reject-Contact 156 header field describes those locations that the proxy server should 157 not direct the request to. 159 Listing only URIs is of limited use, since the caller often will not 160 know where the callee is located. For this reason, this specification 161 proposes a number of URI parameters which describe characteristics of 162 the user. These parameters include whether the location is a home or 163 work address, whether it is fixed or mobile, and what media types are 164 available. A server may know about a number of URIs for a user, along 165 with parameters describing each one, for example, through user 166 registration (REGISTER request). The combination of a URI along with 167 a set of parameters is called a contact entry; a set of contact 168 entries is called the contact list. When a request arrives with 169 either Reject-Contact or Accept-Contact header field, the server 170 performs a matching operation, described below, to create an ordered 171 list of contact addresses that reflect the joint caller's and 172 callee's preferences. 174 There is some overlap between the indication of receiver 175 capabilities in the session description message body and 176 the Accept-Contact and Reject-Contact header fields. 177 However, current session description formats cannot express 178 the preferences described here. Also, the capabilities 179 described here are fundamental to call-routing and thus 180 should not depend on the particulars of the various session 181 description formats that might be used. 183 5.1 Matching Rules 185 The server matches rules in the Accept-Contact and Reject-Contact 186 request headers to contact entries in the contact list according to 187 the following rules. 189 o If rule does not contain URI, only parameters are compared. If 190 the request header rule contains a URI, both the URI and 191 parameters must match. 193 o A URI in a rule matches a SIP URI in a contact entry if the 194 user and host parts are equal, where equality is based on 195 string equivalence. Either part may be omitted from the rule, 196 and in this case it matches any value. For example, the rule " 197 @acme.com " matches " foo@acme.com " or " bar@acme.com ", 198 while the rule " joe@ " matches " joe@acme.com " and " 199 joe@example.com ". Matches are case-insensitive. Other URIs 200 are matched according to the equality rules for that URI 201 scheme. 203 o The parameters in a rule match the parameters in a contact 204 entry if all parameters in the rule either have a matching 205 value in the contact entry, or the parameter is not present in 206 the contact entry. 208 Ignoring the parameter if it does not exist in the 209 contact list avoids that a parameter that the server 210 does not know about causes the match to fail. 212 The pseudo-code below describes the matching procedure between the 213 rule in the request header and the contact entry. For simplicity, we 214 assume that the list of parameters in each rule is stored as an 215 associative array, so that rule.para[duplex] yields the value of the 216 attribute duplex, and is undefined if duplex is not specified. 218 struct { 219 uri_t URI; /* URI */ 220 parameter_t para[]; /* list of parameters */ 221 } rule, entry; 223 boolean MATCH(rule r, entry e) { 224 boolean match; 226 match = TRUE; 227 if (r.URI != "") { 228 if (r.URI.scheme == e.URI.scheme) { 229 if (r.URI.scheme == "sip") { 230 match = (r.URI.host == "" || r.URI.host == e.URI.host) && 231 (r.URI.user == "" || r.URI.user == e.URI.user) 232 } else { 233 match = scheme-appropriate comparison; 234 } 235 } else { 236 return FALSE; 238 } 239 } 241 if(match == FALSE) return FALSE; 243 /* compare parameters */ 244 foreach parameter p in r.para[] { 245 if (isdefined(e.para[p])) { 246 if (r.para[p][0] == "!") 247 if (r.para[p] intersect e.para[p] != "") { 248 return FALSE; 249 } 250 } else { 251 if (r.para[p] is not subset of e.para[p]) { 252 return FALSE; 253 } 254 } 255 } 256 } 257 return TRUE; 258 } 260 Parameter names are matched by case-insensitive string comparison. 261 Parameter values are compared by set-comparisons. Parameter values in 262 quoted strings are interpreted as sets, with elements separated by 263 commas. The names of elements are case-insensitive. Parameter values 264 that are tokens are interpreted as sets with one element. There are 265 two cases: if the quoted-string parameter value in a rule starts with 266 an exclamation mark (!), the rule matches if the intersection of the 267 set in the rule and in the contact entry is empty. Otherwise, the 268 rule matches if the intersection is the rule set itself, i.e., if the 269 rule set is a subset of the contact entry parameter. 271 The syntax for empty intersection is ugly. Using operators 272 instead of equal may be preferable, but breaks the basic 273 SIP parser model. 275 For example, the rule 277 ;language="!en,de" 279 matches the contact entry containing 281 ;language="es,nl" 282 but not any of 284 ;language="en" 285 ;language="de,en" 286 ;language="en,es,fi" 288 As another example, the rule 290 ;duplex="full,half" 292 matches the contact entry 294 ;duplex="full" 296 but not 298 ;duplex="send-only" 300 A server SHOULD NOT be aware of the particular semantics of any of 301 the parameters. This allows for the definition of new parameters and 302 values without explicitly programming them into the servers. 304 5.2 Contact List Processing 306 It is assumed that the server has a contact list for the callee. In 307 this case, the server MAY elect to follow the procedure below for 308 merging caller preferences and callee preferences. If the server has 309 a call processing language for the callee, or some other form of 310 complex logic, the way in which the caller preferences are merged is 311 not defined, but left to the implementor. In general, the server 312 SHOULD NOT proxy or redirect to a contact entry which matches a rule 313 in the Reject-Contact request header. If the server was operating as 314 a proxy, it SHOULD behave as if it had proxied, and had received a 315 404 "Not Found" in response. If the server was acting as a redirect 316 server, if SHOULD NOT place the contact entry in the Contact header 317 in the response. The rules in the Accept-Contact header SHOULD be 318 treated as a hint, and the preferences honored when all else is 319 equal. 321 In the case when the server has a simple, preference ordered contact 322 list for the callee, the procedure is as follows. 324 The server first removes any contact entry from the contact list that 325 matches a rule in the Reject-Contact header field. 327 A contact entry may contain a priority parameter. This means that a 328 request should not be proxied or redirected to that contact entry 329 unless the request is of equal or higher priority. The priority value 330 of the request is derived from the Priority header field. If the 331 request does not contain a Priority header field, the request 332 priority is set to "non-urgent". Priorities are ordered from "non- 333 urgent" (lowest), "normal", "urgent" to "emergency" (highest). 334 Priority values not known to the server are mapped to "non-urgent". 335 The server then removes any contact entry whose priority value is 336 higher than that of the request. 338 Each rule in the Accept-Contact header field is then processed. If 339 the rule matches a contact entry, the q value of that entry is 340 updated, in order to incorporate the caller's preferences. If the 341 rule does not match a contact entry, nothing is done. This document 342 does not prescribe a certain algorithm for updating. Among many 343 possibilities, a server MAY set the q value to the average of the 344 original value specified by the callee, and the average q value of 345 the caller's rules that match the contact entry. This gives equal 346 weight to caller and callee preferences. If a rule or contact entry 347 does not have a q value, it is taken to be one (this is in agreement 348 with the HTTP defaults). 350 Note that this preference computation only determines the 351 ordering of call attempts, so that the properties of the 352 preference computation are of secondary importance. The q- 353 value ordering provides only limited flexibility to 354 indicate, for example, that a particular parameter is more 355 important than another one or that combinations of two 356 parameters should be weighed heavily. 358 If the server proxies, the contact list is then sorted according to 359 the q value. The server first attempts to contact those with the 360 highest q value in parallel. If these contact entries do not respond 361 with a 2xx or 6xx response, the server tries the entries with the 362 next-highest q value. 364 Due to round-off errors and the computation of joint 365 preferences, there may be an excessive bias here towards 366 serialization rather than parallel attempts. Maybe a server 367 should group all q values within, say, 0.1 into a single 368 parallel-search group. 370 If the server receives a redirection, and elects to recurse 371 (depending on its configuration and the preference specified in the 372 Request-Disposition header field), the contact addresses are added to 373 the contact list and the algorithm continues. Note that this may 374 cause addresses that were added by redirection to be tried before 375 contact entries in the original contact list. 377 5.3 IANA Registration 379 New URI parameters and values can be defined at any time and 380 registered with IANA. When registering new parameters and values, the 381 following information MUST be provided: 383 Contact: Name, organization, email address, and phone number of 384 person registering the attributes. 386 Attributes: A list of the new attributes being registered. For each, 387 the meaning of the attribute must be described, in sufficient 388 detail so that a user agent would be able to ascertain whether 389 the parameter applies to it, and if so, which value to use. The 390 attributes MUST also be associated with a finite set of values, 391 each of which is a valid unicode string. For each value, a 392 description of the value must be provided. 394 5.4 Use with REGISTER 396 A user agent normally registers with one or more servers, providing 397 each with a list of Contact addresses. The user agent MAY add the 398 parameters cp-param described in Section 6.2 to the Contact header 399 field. 401 Furthermore, the REGISTER request MAY contain a Require header with 402 the name of this extension if the client wants to be sure that the 403 server honors callee preferences. 405 6 Header Field Definitions 407 The table below specifies which requests can contain which headers. 409 Since all three headers specify call routing logic, they can apply to 410 any request which can normally be proxied. 412 6.1 Contact, Accept-Contact and Reject-Contact Parameters 414 This specification adds the following extension parameters to the 415 Contact header field and defines the same parameters for the Accept- 416 Contact and Reject-Contact header fields. 418 type ACK BYE INV OPT REG CAN 419 __________________________________________________ 420 Accept-Contact R - o o o o - 421 Reject-Contact R - o o o o - 422 Request-Disposition R - o o o o - 424 Table 1: Summary of header fields. "o": optional "-": not applicable, 425 "R': request header, "r": response header, "g": general header, "*": 426 needed if message body is not empty. A numeric value in the "type" 427 column indicates the status code the header field is used with. 429 cp-params = class-param | duplex-param | 430 features-param | language-param | media-param | 431 mobility-param | priority-param | service-param 432 class-param = "class" "=" <"> [] class-tag <"> 433 duplex-param = "duplex" "=" <"> [] duplex-tag <"> 434 feature-param = "feature" "=" <"> [] 1#feature-tag <"> 435 language-param = "language" "=" <"> [] 1#language-tag <"> 436 media-param = "media" "=" <"> [] 1#media-tag <"> 437 mobility-param = "mobility" "=" <"> [] mobility-tag <"> 438 service-param = "service" "=" <"> [] service-tag <"> 439 language-tag = primary-tag *( "-" subtag ) 440 primary-tag = 1*8ALPHA 441 subtag = 1*8ALPHA 442 mobility-tag = "fixed" | "mobile" 443 class-tag = "personal" | "business" 444 duplex-tag = "full" | "half" | "receive-only" | "send-only" 445 service-tag = "fax" | "IP" | "PSTN" | "ISDN" | "text" 446 media-tag = ( "*/*" | (type "/" "*") | 447 (type "/" subtype) ) 448 feature-tag = "voice-mail" | "attendant" 450 The exclamation mark in the parameter value MUST NOT be included if 451 the cp-params are included in a Contact header. 453 class: The class parameter indicates whether this terminal is found 454 in a residential or business setting. (A caller may defer a 455 personal call if only a business line is available, for 456 example.) 458 duplex: The duplex parameter lists whether the terminal can 459 simultaneously send and receive ("full"), alternate between 460 sending and receiving ("half"), can only receive ("receive- 461 only") or only send ("send-only"). Typically, a caller will 462 prefer a full-duplex terminal over a half-duplex terminal and 463 these over receive-only or send-only terminals. 465 features: The feature list enumerates additional features. It is 466 assumed that these features are orthogonal, and could occur in 467 any combination. "Voice-mail" includes the recording of any 468 multimedia stream, as appropriate. 470 language: The language parameter lists the languages spoken by the 471 caller or callee. This feature may, for example, be used to have 472 a caller automatically be directed to the appropriate attendant 473 or customer service representative. Note that this parameter has 474 a different functionality than the Accept-Language and Content- 475 Language header fields, which describe the acceptable languages 476 and languages used in the request and the media description, not 477 the actual communications. 479 media: The media tag lists the media types supported by the terminal. 480 Media types can be the standard Internet media types ("audio", 481 "video", "text", "application"), optionally followed by a 482 subtype (e.g., "text/html"). In addition, the type 483 "application/email" is defined. 485 mobility: The mobility parameter indicates if the terminal is fixed 486 or mobile. In some locales, this may affect audio quality or 487 charges. 489 service: The service tag describes what service is being provided by 490 the terminal. The "text" service refers to a device that can 491 send or receive unformatted ASCII text, such as a pager or a 492 TTY. The "IP" tag indicates a device, such as a personal 493 computer, with Internet connectivity. The "fax" tag indicates a 494 fax machine. The "PSTN" tag indicates a telephone connected to 495 the public switched telephone network. The "ISDN" tag indicates 496 a telephone connected to the Integrated Services Digital 497 Network. 499 The service tags were chosen to maximize the orthogonality 500 of the mobility and service parameters. 502 In addition, the Contact header field may contain the description- 503 param and priority-param parameters. The description parameter 504 further describes, as text, the terminal. The user agent MAY present 505 this text when it is contained in a Contact header field in a 3xx 506 response. The description parameter MUST NOT be used in the matching 507 operation described above. The priority parameter indicates the 508 minimum priority level this terminal is to be used for. It can be 509 used for automatically restricting the choice of terminals available 510 to the user, as described in the procedure above. 512 priority-param = "priority" "=" <"> priority-tag <"> 513 description-param = "description" "=" quoted-string 514 priority-tag = "emergency" | "urgent" | "normal" | "non-urgent" 516 The first example below describes a SIP terminal whose owner speaks 517 English, Spanish and German. The terminal is capable of sending and 518 receiving audio and video and can participate in a chat session. 519 However, the owner only wants callers to use the terminal if the call 520 is of priority "urgent" or higher. This Contact header would normally 521 be included in a REGISTER message. 523 Contact: Carol ;language="en,es,de" 524 ;media="audio,video,application/chat" 525 ;duplex="full" 526 ;priority="urgent" 528 6.2 Accept-Contact 530 The syntax for the Accept-Contact header is defined below: 532 Accept-Contact = "Accept-Contact" ":" 1# rule 533 rule = ( name-addr | addr-spec ) 534 [ *( ";" (cp-params | extension-param | q-param) ) ] 535 q-param = "q" "=" qvalue 536 extension-param = extension-name "=" extension-value 537 extension-name = token 538 extension-value = token | quoted-string 540 The header field specifies contact addresses which are acceptable to 541 the caller. 543 In the following example, the caller would prefer not to talk to 544 sales@acme.com She has a slight preference for fixed as opposed to 545 mobile phones. 547 Accept-Contact: sip:sales@acme.com ;q=0, 548 ;media="!video" ;q=0.1, 549 ;mobility="fixed" ;q=0.6, 550 ;mobility="!fixed" ;q=0.4 552 6.3 Reject-Contact 554 The Reject-Contact header field specifies a list of URIs that the 555 caller does not wish to communicate with. The BNF for the header is: 557 Reject-Contact = "Reject-Contact" ":" 558 1# ( ( name-addr | addr-spec ) 559 [ *( ";" new-params ) ] ) 561 6.4 Request-Disposition 563 The Request-Disposition header field specifies caller preferences for 564 how a proxy or user agent server should process a request. Its value 565 is a list of tokens, each of which specifies a particular feature. 567 When the caller specifies a feature, the server SHOULD treat it as a 568 hint, not as a requirement and MAY ignore the feature request. 570 The header field has the following syntax: 572 Request-Disposition = "Request-Disposition" ":" 573 1# (proxy-feature | cancel-feature | 574 fork-feature | recurse-feature | 575 parallel-feature | queue-feature) 576 proxy-feature = "proxy" | "redirect" 577 cancel-feature = "cancel" | "no-cancel" 578 fork-feature = "fork" | "no-fork" 579 recurse-feature = "recurse" | "no-recurse" 580 parallel-feature = "parallel" | "sequential" 581 queue-feature = "queue" | "no-queue" 583 proxy-feature: This feature indicates whether the caller would like 584 each server to proxy or redirect. 586 cancel-feature: This feature indicates whether the caller would like 587 each proxy server to send a CANCEL request downstream in 588 response to a 200 OK from the downstream server, or whether this 589 function should be left to the caller. 591 fork-feature: This feature indicates whether a proxy should fork a 592 request, or proxy to only a single address. If the server is 593 requested not to fork, the server should proxy the request to 594 the "best" address. The feature is ignored if "redirect" has 595 been requested. 597 recurse-feature: This feature indicates whether a proxy server 598 receiving a 300-class response should send requests to the 599 addresses listed in the response (i.e., recurse), or forward the 600 list of addresses upstream towards the caller. The feature is 601 ignored if "redirect" has been requested. 603 parallel-feature: For a forking proxy server, this feature indicates 604 whether the caller would like the proxy server to proxy the 605 request to all known addresses at once, or go through them 606 sequentially, contacting the next address only after it has 607 received a non-200 or non-600 final response for the previous 608 one. The feature is ignored if "redirect" has been requested. 610 queue-feature: If the called party is temporarily unreachable, e.g., 611 because it is in another call, the caller can indicate that it 612 wants to have its call queued rather than rejected immediately. 613 If the call is queued, the server returns "182 Queued". A 614 pending call be terminated by a SIP CANCEL or BYE request. 616 The normal Proxy-Require/Require/Unsupported mechanism is used to 617 indicate to the caller and/or downstream proxies that a particular 618 service is required to complete the request. Otherwise, the service 619 indication is to be taken as a hint. 621 Example: 623 Request-Disposition: proxy, recurse, parallel 625 7 Acknowledgements 627 Parameters of the terminal negotiation mechanism in Section 6.1 were 628 influenced by Scott Petrack's CMA design. Jonathan Lennox provided 629 helpful comments. 631 8 Bibliography 633 [1] S. Bradner, "Key words for use in RFCs to indicate requirement 634 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 636 [2] J. Lennox, J. Rosenberg, and H. Schulzrinne, "Common gateway 637 interface for SIP," Internet Draft, Internet Engineering Task Force, 638 Nov. 1998. Work in progress. 640 [3] H. Schulzrinne and J. Lennox, "Call processing language 641 requirements," Internet Draft, Internet Engineering Task Force, Aug. 642 1998. Work in progress. 644 [4] H. Schulzrinne and J. Rosenberg, "SIP call control services," 645 Internet Draft, Internet Engineering Task Force, Feb. 1998. Work in 646 progress. 648 [5] G. Klyne, "A syntax for describing media feature sets," Internet 649 Draft, Internet Engineering Task Force, Dec. 1998. Work in progress. 651 Full Copyright Statement 653 Copyright (c) The Internet Society (1999). All Rights Reserved. 655 This document and translations of it may be copied and furnished to 656 others, and derivative works that comment on or otherwise explain it 657 or assist in its implementation may be prepared, copied, published 658 and distributed, in whole or in part, without restriction of any 659 kind, provided that the above copyright notice and this paragraph are 660 included on all such copies and derivative works. However, this 661 document itself may not be modified in any way, such as by removing 662 the copyright notice or references to the Internet Society or other 663 Internet organizations, except as needed for the purpose of 664 developing Internet standards in which case the procedures for 665 copyrights defined in the Internet Standards process must be 666 followed, or as required to translate it into languages other than 667 English. 669 The limited permissions granted above are perpetual and will not be 670 revoked by the Internet Society or its successors or assigns. 672 This document and the information contained herein is provided on an 673 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 674 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 675 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 676 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 677 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 679 Table of Contents 681 1 Terminology ......................................... 1 682 2 Introduction ........................................ 1 683 3 Design Alternatives ................................. 2 684 4 Overview ............................................ 3 685 5 Determining Request Forwarding ...................... 4 686 5.1 Matching Rules ...................................... 4 687 5.2 Contact List Processing ............................. 7 688 5.3 IANA Registration ................................... 9 689 5.4 Use with REGISTER ................................... 9 690 6 Header Field Definitions ............................ 9 691 6.1 Contact, Accept-Contact and Reject-Contact 692 Parameters ..................................................... 9 693 6.2 Accept-Contact ...................................... 12 694 6.3 Reject-Contact ...................................... 13 695 6.4 Request-Disposition ................................. 13 696 7 Acknowledgements .................................... 14 697 8 Bibliography ........................................ 14