idnits 2.17.1 draft-ietf-sipping-overlap-01.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: ---------------------------------------------------------------------------- ** 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? == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 69 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2543 (ref. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-06) exists of draft-ietf-sipping-isup-02 -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Gonzalo Camarillo 3 Internet draft Ericsson 4 5 June 2002 Adam Roach 6 Expires: December 2002 dynamicsoft 8 Jon Peterson 9 NeuStar 11 Lyndon Ong 12 Ciena 14 Mapping of ISUP Overlap Signalling to the Session Initiation Protocol 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes a way to map ISUP overlap signalling to SIP. 37 This mechanism might be implemented when using SIP in an environment 38 where part of the call involves interworking with the Public Switched 39 Telephone Network (PSTN). 41 Camarillo/Roach/Peterson/Ong 1 42 Mapping of ISUP Overlap Signalling to SIP 44 TABLE OF CONTENTS 46 1 Introduction..................................................2 47 2 Overlap signalling in SIP....................................2 48 3 ISUP to SIP..................................................3 49 3.1 Waiting for the minimum amount of digits.....................3 50 3.2 Sending the first INVITE.....................................3 51 3.3 Sending overlap signalling to the SIP network................4 52 3.4 Applicability of this mechanism..............................5 53 3.5 Receiving multiple responses.................................5 54 3.6 Canceling pending INVITE transactions........................6 55 3.7 INVITEs reaching multiple gateways...........................6 56 4 SIP to ISUP..................................................6 57 4.1 Receiving subsequent INVITEs.................................6 58 5 Security Considerations......................................7 59 6 Conclusions..................................................7 60 8 Acknoledgements..............................................7 61 9 References...................................................7 62 10 Authors� addresses...........................................7 64 1. Introduction 66 A mapping between the Session Initiation Protocol (SIP) [1] and the 67 ISDN User Part (ISUP) [2] of SS7 is described in [3]. However, [3] 68 just takes into consideration ISUP en-bloc signalling. En-bloc 69 signalling consists of sending the complete telephone number of the 70 callee in the first signalling message. Although modern switches 71 always use en-bloc signalling, some parts of the PSTN still use 72 overlap signalling. Overlap signalling consists of sending just some 73 digits of the callee�s number in the first signalling message. 74 Further digits are sent in subsequent signalling messages. 76 2. Overlap signalling in SIP 78 SIP uses en-bloc signalling. The Request-URI of an INVITE message 79 contains the whole address of the callee. Even if the Request-URI 80 contains a tel URI instead of a SIP URI, the INVITE contains the 81 whole number. Breaking this principle would just bring undesirable 82 problems to network designers. Therefore, it is strongly recommended 83 not to use any kind of overlap signalling in a SIP network. The 84 recommended behavior is to convert overlap signalling to en-bloc at 85 the edge of the network and then use en-bloc signalling in SIP. A 86 gateway connected to a part of the PSTN where overlap signalling is 87 used can perform this conversion through the use of timers. 89 However, although its use is discouraged, some applications need to 90 use overlap signalling in order to meet service requirements (e.g., 91 establishment time). Such applications should use the mechanism 92 described in this document. This document also describes in which 93 scenarios is acceptable to use such a mechanism and when, on the 94 other hand, it is completely unacceptable to use overlap. 96 3. ISUP to SIP 98 In this scenario the gateway receives an IAM (Initial Address 99 Message) that contains just a portion of the called number. The rest 100 of the digits dialed arrive later in one or more SAMs (Subsequent 101 Address Message). 103 Camarillo/Roach/Peterson/Ong 2 104 Mapping of ISUP Overlap Signalling to SIP 106 3.1 Waiting for the minimum amount of digits 108 If the IAM contain less than the minimum amount of digits to route a 109 call, the gateway starts T35 and waits until the minimum amount of 110 digits that can represent a telephone number is received (or a stop 111 digit is received). If T35 expires before the minimum amount of 112 digits (or a stop digit) has been received a REL with cause value 28 113 is sent to the ISUP side. T35 is defined in [4] as 15-20 seconds. 115 If a stop digit is received, the INVITE message generated by the 116 gateway will contain the complete called number. Therefore, the call 117 proceeds as usual - no overlap signalling in the SIP network. 119 3.2 Sending the first INVITE 121 There are cases when the gateway, after having received the 122 minimum amount of digits, cannot know whether the number received is 123 a complete number or not. Since supporting overlap signalling in the 124 SIP network is an option that may be deemed undesirable, the gateway 125 may elect to collect digits until a timer (T10) expires or a stop 126 digit (such as #) is entered by the user (note that T10 is refreshed 127 every time a new digit is received). 129 In this case, when T10 expires, an INVITE with the digits collected 130 so far is sent to the SIP side. After this, any SAM received is 131 ignored. 133 PSTN MGC/MG SIP 134 | | | 135 |-----------IAM----------->| Starts T10 | 136 | | | 137 |-----------SAM----------->| Starts T10 | 138 | | | 139 |-----------SAM----------->| Starts T10 | 140 | | | 141 | | | 142 | T10 expires |---------INVITE---------->| 143 | | | 145 Note that T10 is defined for conversion between overlap signalling 146 (e.g., CAS) and en-bloc ISUP. PSTN switches usually implement a 147 locally defined value of timer T10, which may not be within the 4-6 148 second range recommended by [4], to convert overlap ISUP to en-bloc 149 ISUP. This document uses T10 and recommends the range of values 150 defined in [4], which seems suitable for conversion from overlap to 151 en-bloc SIP operation. The actual choice of the timer value is a 152 matter of local policy. 154 3.3 Sending overlap signalling to the SIP network 156 Although the behavior just described is recommended by this document, 157 a gateway might still decide to send overlap signalling in the SIP 158 network. In this case, the gateway should proceed as follows. 160 As soon as the minimum amount of digits is received an INVITE is sent 161 and T10 is started. This INVITE is built following the procedures 162 described in [3]. 164 Camarillo/Roach/Peterson/Ong 3 165 Mapping of ISUP Overlap Signalling to SIP 167 If a SAM arrives, T10 is refreshed and a new INVITE with the new 168 digits received is sent. The new INVITE has the same Call-ID and the 169 same From header field including the tag as the first INVITE sent, 170 but has an updated Request-URI. The new Request-URI contains all the 171 digits received so far. The To header field of the new INVITE 172 contains all the digits as well, but has no tag. 174 Note that it is possible to receive a response to the first 175 INVITE before having sent the second INVITE. In this case, the 176 response received would contain a To tag and information 177 (Record-Route and Contact) to build a Route header field. The 178 new INVITE to be sent (containing new digits) should not use any 179 of these headers. That is, the new INVITE does not contain 180 neither To tag nor Route header field. This way this new INVITE 181 can be routed dynamically by the network providing services (see 182 Section 3.7). 184 The new INVITE should, of course, contain a Cseq field. It is 185 recommended that the Cseq of the new INVITE is higher than any of the 186 previous Cseq that the gateway has generated for this Call-ID (no 187 matter for which dialog the Cseq was generated). 189 When an INVITE forks, responses from different locations might 190 arrive establishing one or more early dialogs. New requests such 191 as PRACK or COMET can be sent within every particular early 192 dialog. This implies that the Cseq number spaces of different 193 early dialogs are different. Sending a new INVITE with a Cseq 194 that is still unused by any of the remote destinations avoids 195 confusion at the destination. 197 If the gateway is encapsulating ISUP messages as SIP bodies, it 198 should place the IAM and all the SAMs received so far in this INVITE. 200 PSTN MGC/MG SIP 201 | | | 202 |-----------IAM----------->| Starts T10 | 203 | |---------INVITE---------->| 204 | | | 205 |-----------SAM----------->| Starts T10 | 206 | |---------INVITE---------->| 207 | | | 208 |-----------SAM----------->| Starts T10 | 209 | |---------INVITE---------->| 210 | | | 212 If 4xx, 5xx or 6xx final responses arrive (e.g. 484 address 213 incomplete) for the pending INVITE transactions before T10 has 214 expired, the gateway should not send any REL. A REL is sent only if 215 no more SAMs arrive, T10 expires and all the INVITEs sent have been 216 answered with a final response (different than 200 OK). 218 PSTN MGC/MG SIP 219 | | | 220 |-----------IAM----------->| Starts T10 | 221 | |---------INVITE---------->| 222 | |<---------484-------------| 223 | |----------ACK------------>| 224 | | | 225 | | | 226 | T10 expires | | 228 Camarillo/Roach/Peterson/Ong 4 229 Mapping of ISUP Overlap Signalling to SIP 231 |<----------REL------------| | 233 The best status code among all the responses received for all the 234 INVITEs that were generated is used to calculate the cause value of 235 the REL as described in [3]. 237 The computation of the best response is done in the same way as 238 forking proxies compute the best response to be returned to the 239 client for a particular INVITE. Note that the best response is 240 not always the response to the INVITE that contained more 241 digits. If the user dials a particular number and then types an 242 extra digit by mistake a 486 (Busy Here) could be received for 243 the first INVITE and a 484 (Address Incomplete) for the second 244 one (which contained more digits). 246 3.4 Applicability of this mechanism 248 This mechanism is applicable only under certain circumstances. An 249 ingress gateway may use overlap signalling in SIP when an analysis of 250 the called party number shows that it belongs to a part of the PSTN 251 where there is a variable number of digits required to form a 252 complete number and the gateway lacks the information to determine 253 the length of the number solely by interpretation of the received 254 digits. 256 Within some dialing plans in the PSTN, a phone number might be a 257 prefix of another one. This situation is not common, but it can 258 certainly occur. Where en-bloc signalling is used, this ambiguity is 259 resolved before the digits are placed in the en-bloc signalling. If 260 overlap signaling was used in this situation, a different user than 261 the one the caller intended to call might be contacted. That is why 262 in the parts of the PSTN where overlap is used, a prefix of a 263 telephone number never identifies another valid number. Therefore, an 264 ingress gateway may use overlap if, and only if, an analysis of the 265 called party number shows that it belongs to a part of the PSTN where 266 overlap signalling is used. This ensures that a particular prefix of 267 the number does not identify any other user. 269 3.5 Receiving multiple responses 271 When overlap signalling in SIP is used the ingress gateway sends 272 multiple INVITEs. Accordingly, it will receive multiple responses. 273 The responses to all the INVITEs sent except for one (normally, but 274 not necessarily the last one) are typically 400 class responses (e.g. 275 484 Address Incomplete or 490 Request Updated) that terminate the 276 INVITE transaction. 278 However, a 183 Session Progress response with a media description can 279 also be received. The media stream will typically contain a message 280 such as "The number you have just dialed does not exist". 282 The issue of receiving different 183 Session Progress responses with 283 media descriptions does not only apply to overlap signalling. When 284 vanilla SIP is used, several responses can also arrive to a gateway 285 if the INVITE forked. It is then up to the gateway to decide which 286 media stream should be played to the user. 288 However, overlap signalling adds a requirement to this process. As a 289 general rule, a media stream corresponding to the response to an 290 INVITE with a greater number of digits should be given more priority 291 than media streams from responses with less digits. 293 Camarillo/Roach/Peterson/Ong 5 294 Mapping of ISUP Overlap Signalling to SIP 296 3.6 Canceling pending INVITE transactions 298 When a gateway sends a new INVITE containing new digits, it should 299 not CANCEL the previous INVITE transaction. This CANCEL could arrive 300 before the new INVITE to an egress gateway and trigger a REL before 301 the new INVITE arrived. INVITE transactions are typically terminated 302 by the reception of 4xx responses. 304 However, once a 200 OK response has been received, the gateway should 305 CANCEL all the other INVITE transactions were generated. A particular 306 gateway might implement a timer to wait for some time before sending 307 any CANCEL. This gives time to all the previous INVITE transactions 308 to terminate smoothly without generating more signalling traffic 309 (CANCEL messages). 311 3.7 INVITEs reaching multiple gateways 313 Since every new INVITE sent by a gateway represents a new transaction 314 they can be routed in different ways. For instance, the first INVITE 315 might be routed to a particular gateway and a subsequent INVITE to 316 another. The result is that both gateways generate an IAM. Since one 317 of the IAMs (or both) has an incomplete number, it would fail, having 318 already consumed PSTN resources. It could even happen that both IAMs 319 contained complete, but different numbers (i.e., one number is the 320 prefix of the other one). 322 It has been proposed to make all the INVITEs follow the same path as 323 the first one. This proposal would resolve the problem of having 324 INVITEs hitting different gateways, but would restrict the number of 325 services the SIP network can provide. It would not be possible to 326 route a subsequent INVITE to an application server just because the 327 previous one was routed in a different way. 329 This issue should be taken into consideration before using overlap 330 signalling in SIP. If sending multiple IAMs to the PSTN is not 331 acceptable in a particular domain, overlap signalling should not be 332 used. 334 4. SIP to ISUP 336 In this scenario the gateway receives multiple INVITEs that have the 337 same Call-ID but have different Request-URIs. 339 Note that these INVITEs do not belong to they same dialog 340 because the have different To header fields. 342 4.1 Receiving subsequent INVITEs 344 An egress gateway does not have any means to know whether SIP overlap 345 signalling is being used or not. So, upon reception of an INVITE, the 346 gateway generates an IAM following the procedures described in [3]. 348 If a gateway receives a subsequent INVITE with the same Call-ID and 349 From tag as the previous one and an updated Request-URI, a SAM should 350 be generated as opposed to a new IAM. Upon reception of a subsequent 351 INVITE, the INVITE received previously is answered with 490 Request 352 Updated. 354 Camarillo/Roach/Peterson/Ong 6 355 Mapping of ISUP Overlap Signalling to SIP 357 If the gateway is attached to the PSTN in an area where en-bloc 358 signalling is used, a REL for the previous IAM and a new IAM should 359 be generated. 361 5. Security Considerations 363 No extra security risk outside these specified by [3] are foreseen. 365 6. Conclusions 367 The mechanism described in this document is intended to be used in a 368 closed environment. Using it in an open network such as the Internet 369 would cause problems such as multiple IAMs generated. If this 370 mechanism were used with telephone numbers that are ambiguous in the 371 local dial plan, calls could end up reaching a different callee than 372 the one who was supposed to receive the call if an inadvertent 373 timeout occurs. 375 Due to these problems, it is strongly recommended that this mechanism 376 is only used if a particular application must fulfil strong 377 requirements regarding establishment delay. Otherwise, the ingress 378 gateway should always perform overlap to en-bloc conversion. 380 7. Acknowledgments 382 The authors would like to thank Jonathan Rosenberg, Olli Hynonen and 383 Mike Pierce for their feedback on this document. 385 8. References 387 [1] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP: 388 Session Initiation Protocol", RFC 2543, IETF; March 1999. 390 [2] "Application of the ISDN user part of CCITT signaling system No. 391 7 for international ISDN interconnections", ITU-T Q.767 392 recommendation, February 1991. 394 [3] G. Camarillo, A. Roach, J. Peterson, L. Ong, "ISUP to SIP 395 Mapping", draft-ietf-sipping-isup-02.txt, IETF; May 2002. Work in 396 progress. 398 [4] "Signalling System No. 7 - ISDN User Part signalling procedures", 399 ITU-T Q.764 recommendation, December 1999. 401 9. Authors� Addresses 403 Gonzalo Camarillo 404 Ericsson 405 Advanced Signalling Research Lab 406 FIN-02420 Jorvas 407 Finland 408 Phone: +358 9 299 3371 409 Fax: +358 9 299 3052 410 Email: Gonzalo.Camarillo@ericsson.com 412 Adam Roach 413 dynamicsoft 414 5100 Tennyson Parkway 415 Suite 1200 416 Plano, TX 75024 417 USA 419 Camarillo/Roach/Peterson/Ong 7 420 Mapping of ISUP Overlap Signalling to SIP 422 E-Mail: 423 Voice: 425 Jon Peterson 426 NeuStar, Inc 427 1800 Sutter St Suite 570 428 Concord, CA 94520 429 USA 430 E-Mail: jon.peterson@neustar.com 432 Lyndon Ong 433 Ciena 434 10480 Ridgeview Court 435 Cupertino, CA 95014 436 E-Mail: lyOng@ciena.com 438 Full Copyright Statement 440 Copyright (c) The Internet Society (2002). All Rights Reserved. 442 This document and translations of it may be copied and furnished to 443 others, and derivative works that comment on or otherwise explain it 444 or assist in its implementation may be prepared, copied, published 445 and distributed, in whole or in part, without restriction of any 446 kind, provided that the above copyright notice and this paragraph are 447 included on all such copies and derivative works. However, this 448 document itself may not be modified in any way, such as by removing 449 the copyright notice or references to the Internet Society or other 450 Internet organizations, except as needed for the purpose of 451 developing Internet standards in which case the procedures for 452 copyrights defined in the Internet Standards process must be 453 followed, or as required to translate it into languages other than 454 English. 456 The limited permissions granted above are perpetual and will not be 457 revoked by the Internet Society or its successors or assigns. 459 This document and the information contained herein is provided on an 460 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 461 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 462 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 463 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 464 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 466 Camarillo/Roach/Peterson/Ong 8