idnits 2.17.1 draft-ietf-insipid-logme-marking-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 331 has weird spacing: '...orp.com p1.fo...' == Line 362 has weird spacing: '...orp.com r1.ba...' == Line 498 has weird spacing: '...orp.com p1.fo...' -- The document date (August 28, 2014) is 3501 days in the past. Is this intentional? 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: 'RFCXXXX' is mentioned on line 568, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-insipid-logme-reqs-01 ** Downref: Normative reference to an Informational draft: draft-ietf-insipid-logme-reqs (ref. 'I-D.ietf-insipid-logme-reqs') == Outdated reference: A later version (-27) exists of draft-ietf-insipid-session-id-06 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Dawes 3 Internet-Draft Vodafone Group 4 Intended status: Standards Track August 28, 2014 5 Expires: March 1, 2015 7 Marking SIP Messages to be Logged 8 draft-ietf-insipid-logme-marking-01 10 Abstract 12 SIP networks use signalling monitoring tools to diagnose user 13 reported problems and for regression testing if network or user agent 14 software is upgraded. As networks grow and become interconnected, 15 including connection via transit networks, it becomes impractical to 16 predict the path that SIP signalling will take between user agents, 17 and therefore impractical to monitor SIP signalling end-to-end. 19 This document describes an indicator for the SIP protocol which can 20 be used to mark signalling as of interest to logging. Such marking 21 will typically be applied as part of network testing controlled by 22 the network operator and not used in regular user agent signalling. 23 However, such marking can be carried end-to-end including the SIP 24 user agents, even if a session originates and terminates in different 25 networks. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 1, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 63 3. Motivating Scenario . . . . . . . . . . . . . . . . . . . . . 3 64 4. Skeleton Diagnostic Procedure . . . . . . . . . . . . . . . . 4 65 5. Protocol for Log-Me Marking . . . . . . . . . . . . . . . . . 5 66 5.1. Configuration for Log-Me Marking . . . . . . . . . . . . 5 67 5.2. Starting and Stopping Log-Me Marking . . . . . . . . . . 5 68 5.3. End Points of Log-Me Marking . . . . . . . . . . . . . . 6 69 5.3.1. Originating and Terminating User Agent . . . . . . . 6 70 5.3.2. Originating Edge Proxy and Terminating Edge Proxy . . 7 71 5.4. Maintaining State . . . . . . . . . . . . . . . . . . . . 7 72 5.5. Missing Log-me Marker in Dialog Being Logged . . . . . . 9 73 5.6. Logging Multiple Simultaneous Dialogs . . . . . . . . . . 10 74 5.7. Forked Requests . . . . . . . . . . . . . . . . . . . . . 10 75 5.8. B2BUA Handling of Log-Me Marked Dialogs . . . . . . . . . 10 76 5.8.1. All B2BUA Roles . . . . . . . . . . . . . . . . . . . 10 77 5.8.2. Proxy-B2BUA . . . . . . . . . . . . . . . . . . . . . 10 78 5.8.2.1. Terminating Behaviour . . . . . . . . . . . . . . 10 79 5.8.3. Signaling-only and SDP-Modifying Signaling-only . . . 11 80 5.8.3.1. Terminating Behaviour . . . . . . . . . . . . . . 11 81 5.8.3.2. Originating Behaviour . . . . . . . . . . . . . . 11 82 5.8.4. Media Relay, Media Aware, Media Termination . . . . . 11 83 5.9. 'Log-Me' Marker . . . . . . . . . . . . . . . . . . . . . 11 84 5.9.1. Header Field Parameter for Session-ID . . . . . . . . 11 85 5.9.2. Identifying Test Cases . . . . . . . . . . . . . . . 12 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 6.1. Trust Domain . . . . . . . . . . . . . . . . . . . . . . 12 88 6.2. Security Threats . . . . . . . . . . . . . . . . . . . . 12 89 6.2.1. The Log-Me Marker . . . . . . . . . . . . . . . . . . 12 90 6.2.2. Activating Debug . . . . . . . . . . . . . . . . . . 12 91 6.3. Protecting Logs . . . . . . . . . . . . . . . . . . . . . 12 92 7. Augmented BNF for the "debug" Parameter . . . . . . . . . . . 12 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 94 8.1. Registration of the "debug" Parameter . . . . . . . . . . 13 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 96 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 97 9.2. Informative References . . . . . . . . . . . . . . . . . 13 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 100 1. Introduction 102 If users experience problems with setting up sessions using SIP, 103 their service provider needs to find out why by examining the SIP 104 signalling. Also, if network or user agent software or hardware is 105 upgraded regression testing is needed. Such diagnostics apply to a 106 small proportion of network traffic and can apply end-to-end, even if 107 signalling crosses several networks possibly belonging to several 108 different network operators. It may not be possible to predict the 109 path through those networks in advance, therefore a mechanism is 110 needed to mark a session as being of interest so that SIP entities 111 along the signalling path can provide diagnostic logging. This 112 document describes a solution that meets the requirements for such a 113 'log me' marker for SIP signalling as defined in draft-ietf-insipid- 114 logme-reqs [I-D.ietf-insipid-logme-reqs]. 116 2. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 3. Motivating Scenario 124 Signalling for SIP session setup can cross several networks, and 125 these networks may not have common ownership and also may be in 126 differrent countries. If a single operator wishes to perform 127 regression testing or fault diagnosis end-to-end, the separate 128 ownership of networks that carry the signalling and the explosion in 129 the number of possible signalling paths through SIP entities from the 130 originating to the terminating user make it impractical to pre- 131 configure logging of an end-to-end SIP signalling of a session of 132 interest. 134 The figure below shows an example of a signalling path through 135 multiple networks. 137 +------------------+ +------------------+ 138 | COUNTRY A | | COUNTRY B | 139 | Operator A | | Operator A | 140 | | | | 141 | SIP Phones | | SIP Phones | 142 | | //| | 143 +------------------+ // +------------------+ 144 | // 145 | // 146 ,'```', // +------------------+ 147 .`',.' `..'``',<==// | COUNTRY B | 148 ,' Operator A `', | Operator A | 149 ; Backbone Network ..'-------| | 150 ', ,., .'` | PSTN phones | 151 '.,.`'.,,,.` `''` | | 152 || +------------------+ 153 || 154 \/ 155 +------------------+ 156 | | 157 | Transit Network | 158 | | 159 | |\\ 160 +------------------+ \\ 161 | \\ 162 | \\ 163 +------------------+ \\ +------------------+ 164 | COUNTRY D | \\ | COUNTRY C | 165 | Operator C | \\=>| Operator B | 166 | | | | 167 | SIP Phones | | SIP Phones | 168 | | | | 169 +------------------+ +------------------+ 171 Figure 1: Example signalling path through multiple networks 173 4. Skeleton Diagnostic Procedure 175 The skeleton diagnostic procedure is as follows: 177 o The user's user agent is placed in debug mode. The user agent 178 logs its own signalling and inserts a log me marker into SIP 179 requests for session setup 181 o All SIP entities that the signalling traverses, from the first 182 proxy the user agent connects to at the edge of the network to the 183 destination user agent, can detect that the log me marker is 184 present and can log SIP requests and responses that contain the 185 marker if configured to do so. 187 o Subsequent responses and requests in the same dialog are logged. 189 o Logging stops, either because the dialog has ended or because a 190 'stop event', typically expiry of a certain amount of time, 191 occurred 193 o The user's user agent and any other SIP entity that has logged 194 signalling sends logs to a server that is co-ordinating 195 diagnostics. 197 5. Protocol for Log-Me Marking 199 This clause describes the protocol solution to the log-me 200 requirements described in draft-ietf-insipid-logme-reqs 201 [I-D.ietf-insipid-logme-reqs]. 203 5.1. Configuration for Log-Me Marking 205 Configuration of a user agent or proxy to perform log-me marking can 206 be done in any way that is convenient to the configured entity. For 207 example, an XML file might be used to list conditions for starting 208 and stopping based on time. 210 09:00:00 211 09:10:00 213 Figure 2: Simple example log-me configuration 215 Logging is on a per-dialog basis and individual logs are 216 differentiated by their test identifier, which is defined in 217 Section 5.9.2 of this document. Therefore, an individual log for an 218 individual dialog is closed when that dialog ends. Logging is 219 typically done separately from regualar operation, which means that 220 tests can be designed to be short enough to troubleshoot quickly and 221 to limit the size of individual logs. If logging is configured so 222 that everything is logged for a specified number of minutes then 223 several separate dialogs might start and finish meaning that several 224 logs may be generated, each one distinguished by its test identifier. 226 5.2. Starting and Stopping Log-Me Marking 228 A proxy or user agent needs to determine when it needs to log-me mark 229 a SIP request or response. A user agent or proxy log-me marks a 230 request or response for two reasons: either it is configured to do so 231 or it has detected that a dialog is being log-me marked and maintains 232 state to ensure that all requests and responses in the dialog are 233 log-me marked. A regression test might be configured to log-me mark 234 all SIP dialogs created during a given time period whereas a 235 troubleshooting test might be configured to mark a dialog based on 236 criteria specific to a reported fault. When configuration has caused 237 a user agent or proxy to start log-me marking requests and responses, 238 marking continues until the dialog ends. 240 5.3. End Points of Log-Me Marking 242 Log-me marking is initiated on a dialog creating side controlled by 243 configuration. The dialog terminating side detects an incoming log- 244 me marker and reacts accordingly. 246 5.3.1. Originating and Terminating User Agent 248 In the simplest case, an originating user agent will insert a log-me 249 marker in the dialog-creating SIP request and all subsequent SIP 250 requests within that dialog. The log-me marker is carried to the 251 terminating user agent and the terminating user agent echoes the log- 252 me marker in responses. If the terminating user agent sends an in- 253 dialog request on a dialog that is being log-me marked, it inserts a 254 log-me marker and the originating user agent echoes the log-me marker 255 in responses. This basic case suggests the following principles: 257 o The originating user agent is configured for debug 259 o The terminating user agent is not configured for debug and cannot 260 initiate log-me marking. 262 o The originating user agent logs its own signalling and inserts a 263 log me marker into the dialog-creating SIP request and subsequent 264 in-dialog SIP requests. 266 o The terminating user agent can detect that a dialog is of interest 267 to logging by the existence of a log-me marker in an incoming 268 dialog-creating SIP request. 270 o The terminating user agent MUST echo a log-me marker in responses 271 to a SIP request that included a log-me marker. 273 o If the terminating user agent has detected that a dialog is being 274 log-me marked, it inserts a log-me marker in any in-dialog SIP 275 requests that it sends. 277 5.3.2. Originating Edge Proxy and Terminating Edge Proxy 279 Some user agents might not support log-me marking. In order to test 280 sessions involving such user agents, the log-me marker is inserted by 281 edge proxies on the originating and terminating sides. The log-me 282 marker is carried to the terminating user agent but the terminating 283 user agent is not able to echo the log-me marker in responses to that 284 request. Therefore the terminating edge proxy inserts a log-me 285 marker in reponses to the request. Likewise, if the terminating user 286 agent sends an in-dialog request, the terminating edge proxy inserts 287 a log-me marker and the originating edge proxy echoes the log-me 288 marker in responses to that request. This case suggests the 289 following principles: 291 o The originating edge proxy is configured for debug. 293 o The terminating edge proxy is not configured for debug and cannot 294 initiate log-me marking. 296 o The originating edge proxy logs its own signalling and inserts a 297 log me marker into SIP requests for session setup. 299 o The terminating edge proxy can detect that a dialog is of interest 300 to logging by the existence of a log-me marker in an incoming SIP 301 request. 303 o The terminating edge proxy MUST echo a log-me marker in responses 304 to a SIP request that included a log-me marker. 306 o If the terminating edge proxy has detected that a dialog is being 307 log-me marked, it inserts a log-me marker in in-dialog SIP 308 requests from the terminating user agent. 310 o The originating edge proxy echoes the log-me marker in responses 311 to in-dialog requests received from the terminating side. 313 5.4. Maintaining State 315 If a proxy inserts a log-me marker in a SIP request (because a user 316 agent did not) then it must ensure that a log-me marker is also 317 inserted in responses to that request. A proxy on the terminating 318 side that receives a SIP reqeust with a log-me marker may also ensure 319 that responses to that requset contain a log-me marker by inserting 320 one if the terminating user agent did not. Entities that perform 321 this log-me marking or checking must maintain a record of which 322 dialogs are being log-me marked. 324 In the figure below, the edge proxy in the originating network 325 maintains state to ensure log-me marking of SIP requests and in the 326 terminating network the registrar maintains state to ensure log-me 327 marking of SIP responses. Such behaviour is useful for logging if 328 end devices do not insert or echo a log-me marker. 330 Alice Proxy Registrar 331 u1.foocorp.com p1.foocorp.com r1.foocorp.com 332 | | | 333 |(1) INVITE | | 334 | (u1 does not insert log-me marker in SIP request) 335 |----------------->| | 336 | |(2) INVITE | 337 | | 'log-me' marker 338 | | (p1 inserts log-me marker. p1 maintains 339 | | state and inserts log-me marker in all 340 | | requests on this dialog) 341 | |----------------->| 342 | | |(3) INVITE 343 | | | 'log-me' marker 344 | | |--------> (to barcorp) 345 | | | 346 | | | 347 | | | 348 | | |(8) 200 OK 349 | | | 'log-me' marker 350 | |(9) 200 OK |<-------- (from barcorp) 351 | | 'log-me' marker 352 | |<-----------------| 353 |(10) 200 OK | | 354 | 'log-me' marker | 355 |<-----------------| | 356 | | | 357 |(11) ACK | | 358 |---------------------------------------------------------> 359 | | | 361 Proxy Registrar Bob 362 p1.barcorp.com r1.barcorp.com u1.barcorp.com 363 | | | 364 (3) INVITE | | 365 'log-me' marker | | 366 ----->|(from foocorp) | | 367 | | | 368 |(4) INVITE | | 369 | 'log-me' marker | 370 |----------------->| | 371 | |(r1 detects that this dialog is 372 | | being log-me marked) 373 | | | 374 | | | 375 | |(5) INVITE | 376 | 'log-me' marker 377 | |----------------->| 378 | | | 379 | |(6) 200 OK | 380 | | (u1 does not echo LogMe: 381 | | to SIP response)| 382 | |<-----------------| 383 |(7) 200 OK | | 384 |'log-me' marker | | 385 | (r1 inserts log-me marker. r1 maintains 386 | state and inserts log-me marker in all 387 | responses on this dialog) 388 |<-----------------| | 389 | | | 390 (8) 200 OK | | 391 'log-me' marker | | 392 <----| | | 393 | | | 394 (11) ACK | | 395 from foocorp) -------------------------->| 396 | | | 397 | | | 398 | |(12) re-INVITE | 399 | |<-----------------| 400 | |(in-dialog request) 401 | | | 402 |(13) re-INVITE | | 403 |'log-me' marker | | 404 |<-----------------| | 405 |(r1 inserts log-me marker into in-dialog 406 | requests sent from the terminating user agent) 407 | | | 409 Figure 3: Maintaining state for log-me marking 411 5.5. Missing Log-me Marker in Dialog Being Logged 413 A terminating user agent or terminating edge proxy that has been 414 echoing markers in responses for a given dialog might receive a SIP 415 request that has not been log-me marked. Since log-me marking is 416 done per dialog, this is an error. In such cases, the proxy SHOULD 417 consider log-me marking to have ended and MUST NOT mark a response to 418 the unmarked request, responses to subsequent requests in the dialog, 419 or in-dialog requests sent from the terminating side. Similarly, 420 log-me marking that begins mid-dialog is an error case and the 421 terminating user agent or edge proxy MUST NOT log-me mark responses 422 to the marked request, responses to subsequent requests in the 423 dialog, or in-dialog requests from the terminating side. 425 5.6. Logging Multiple Simultaneous Dialogs 427 An originating or terminating user agent and SIP entities on the 428 signaling path can log multiple SIP dialogs simultaneously, these 429 dialogs are differentiated by their test identifier. 431 5.7. Forked Requests 433 Log-me marking is copied into forked requests. 435 5.8. B2BUA Handling of Log-Me Marked Dialogs 437 The log-me marking behaviour of a B2BUA needs to be consistent with 438 its purpose of troubleshooting user problems and regression testing. 439 For example, a B2BUA that does no more than transcoding media can 440 simply copy log-me marking from UAS to UAC whereas a B2BUA that 441 performs varied and complex signalling tasks such as distributing 442 calls in a call centre needs flexible configuration so that log-me 443 marking can target specific B2BUA functions. 445 B2BUA behaviour is described below for each of the B2BUA types 446 described in RFC7092 [RFC7092]. Behaviour described in this clause 447 applies only to dialogs that are being log-me marked. 449 5.8.1. All B2BUA Roles 451 For dialogs that are being log-me marked, all B2BUAs MUST log-me mark 452 in-dialog SIP requests that they generate on their own, without 453 needing explicit configuration to do so. This rule applies to both 454 the originating and terminating sides of a B2BUA. 456 5.8.2. Proxy-B2BUA 458 5.8.2.1. Terminating Behaviour 460 A Proxy-B2BUA SHOULD copy log-me marking in requests and responses 461 from its terminating to the originating side without needing explicit 462 configuration to do so. 464 5.8.3. Signaling-only and SDP-Modifying Signaling-only 466 5.8.3.1. Terminating Behaviour 468 A signaling-only B2BUA SHOULD NOT copy log-me marking in requests and 469 responses from its terminating to its originating side. Whether a 470 dialog that a signaling-only B2BUA terminates causes log-me marking 471 of a dialog on its originating side SHOULD be controlled by explicit 472 configuration of the originating side, in the same way that a UAC 473 requires configuration to control log-me marking. 475 5.8.3.2. Originating Behaviour 477 Whether a signaling-only B2BUA log-me marks SIP requests that it 478 generates on its own SHOULD be controlled by explicit configuration 479 of the originating side, in the same way that a UAC requires 480 configuration to control log-me marking. 482 5.8.4. Media Relay, Media Aware, Media Termination 484 Log-me marking behaviour is independent of B2BUA media-plane 485 functionality. Behaviour of signaling/media plane B2BUA roles is 486 therefore dictated only by the signaling plane role as described in 487 Section 5.8.2 and Section 5.8.3 in this document. 489 5.9. 'Log-Me' Marker 491 5.9.1. Header Field Parameter for Session-ID 493 A new header field parameter called debug is defined to be used with 494 the Session-ID header field (described in draft-ietf-insipid-session- 495 id [I-D.ietf-insipid-session-id]). 497 Alice Proxy Registrar Debug Server 498 u1.foocorp.com p1.foocorp.com r1.foocorp.com d1.foocorp.com 499 | | | | 500 |(1) INVITE | | | 501 | Session-ID: ab30317f1a784dc48ff824d0d3715d86; | 502 | remote=47755a9de7794ba387653f2099600ef2; debug 503 |----------------->| | | 504 | | | | 506 Figure 4: Log-me marking using the "debug" Session-ID: header field 507 parameter 509 5.9.2. Identifying Test Cases 511 The test case identifier is the Session-ID in the Session-ID header 512 field (described in draft-ietf-insipid-session-id 513 [I-D.ietf-insipid-session-id]). A log relates to exactly one dialog 514 and logs are distinguished by their test case identifier. 516 6. Security Considerations 518 6.1. Trust Domain 520 Since a log me marker may cause a SIP entity to log the SIP header 521 and body of a request or response, the log me marker SHOULD be 522 removed at a trust domain boundary. If a prior agreement to log 523 sessions exists with the net hop network then the log me marker might 524 not be removed. 526 6.2. Security Threats 528 6.2.1. The Log-Me Marker 530 The log me marker is not sensitive information, although it will 531 sometimes be inserted because a particular device is experiencing 532 problems. 534 The presence of a log me marker will cause some SIP entities to log 535 signalling. Therefore, this marker MUST be removed at the earliest 536 opportunity if it has been incorrectly inserted. 538 6.2.2. Activating Debug 540 Activating a debug mode affects the operation of a user agent, 541 therefore it MUST be supplied by an authorized server to an 542 authorized user agent, it MUST NOT be altered in transit, and it MUST 543 NOT be readable by an unauthorized third party. 545 6.3. Protecting Logs 547 A SIP entity that has logged information SHOULD encrypt it, such that 548 it can be decrypted only by a person authorized to examine the logged 549 information. 551 7. Augmented BNF for the "debug" Parameter 553 ABNF is described in RFC 5234 [RFC5234] 555 debug-param = "debug" 557 8. IANA Considerations 559 8.1. Registration of the "debug" Parameter 561 The following parameter is to be added to the "Header Field 562 Parameters and Parameter Values" section of the SIP parameter 563 registry: 565 +--------------+----------------+-------------------+-----------+ 566 | Header Field | Parameter Name | Predefined Values | Reference | 567 +--------------+----------------+-------------------+-----------+ 568 | Session-ID | debug | No | [RFCXXXX] | 569 +--------------+----------------+-------------------+-----------+ 571 Table 1 573 9. References 575 9.1. Normative References 577 [I-D.ietf-insipid-logme-reqs] 578 Dawes, P., "Requirements for Marking SIP Messages to be 579 Logged", draft-ietf-insipid-logme-reqs-01 (work in 580 progress), July 2014. 582 [I-D.ietf-insipid-session-id] 583 Jones, P., Pearce, C., Polk, J., and G. Salgueiro, "End- 584 to-End Session Identification in IP-Based Multimedia 585 Communication Networks", draft-ietf-insipid-session-id-06 586 (work in progress), April 2014. 588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 589 Requirement Levels", BCP 14, RFC 2119, March 1997. 591 9.2. Informative References 593 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 594 Specifications: ABNF", STD 68, RFC 5234, January 2008. 596 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 597 Initiation Protocol (SIP) Back-to-Back User Agents", RFC 598 7092, December 2013. 600 Author's Address 601 Peter Dawes 602 Vodafone Group 603 The Connection 604 Newbury, Berkshire RG14 2FN 605 UK 607 Email: peter.dawes@vodafone.com