idnits 2.17.1
draft-ietf-insipid-logme-marking-05.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 too long lines in the document, the longest one
being 14 characters in excess of 72.
== 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 p1.ba...'
== Line 497 has weird spacing: '...orp.com p1.fo...'
-- The document date (August 14, 2016) is 2784 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 566, but not defined
== Outdated reference: A later version (-12) exists of
draft-ietf-insipid-logme-reqs-07
** Downref: Normative reference to an Informational draft:
draft-ietf-insipid-logme-reqs (ref. 'I-D.ietf-insipid-logme-reqs')
** Downref: Normative reference to an Informational RFC: RFC 7206
Summary: 3 errors (**), 0 flaws (~~), 7 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 14, 2016
5 Expires: February 15, 2017
7 Marking SIP Messages to be Logged
8 draft-ietf-insipid-logme-marking-05
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 February 15, 2017.
44 Copyright Notice
46 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 14
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 r1.barcorp.com p1.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 | |(p1 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 | (p1 inserts log-me marker. p1 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 |(p1 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 RFC 7206 [RFC7206]).
496 Alice Proxy Registrar Debug Server
497 u1.foocorp.com p1.foocorp.com r1.foocorp.com d1.foocorp.com
498 | | | |
499 |(1) INVITE | | |
500 | Session-ID: ab30317f1a784dc48ff824d0d3715d86; |
501 | remote=47755a9de7794ba387653f2099600ef2; debug
502 |----------------->| | |
503 | | | |
505 Figure 4: Log-me marking using the "debug" Session-ID: header field
506 parameter
508 5.9.2. Identifying Test Cases
510 The test case identifier is the Session-ID in the Session-ID header
511 field (described in RFC 7206 [RFC7206]). A log relates to exactly
512 one dialog and logs are distinguished by their test case identifier.
514 6. Security Considerations
516 6.1. Trust Domain
518 Since a log me marker may cause a SIP entity to log the SIP header
519 and body of a request or response, the log me marker SHOULD be
520 removed at a trust domain boundary. If a prior agreement to log
521 sessions exists with the net hop network then the log me marker might
522 not be removed.
524 6.2. Security Threats
526 6.2.1. The Log-Me Marker
528 The log me marker is not sensitive information, although it will
529 sometimes be inserted because a particular device is experiencing
530 problems.
532 The presence of a log me marker will cause some SIP entities to log
533 signalling. Therefore, this marker MUST be removed at the earliest
534 opportunity if it has been incorrectly inserted.
536 6.2.2. Activating Debug
538 Activating a debug mode affects the operation of a user agent,
539 therefore it MUST be supplied by an authorized server to an
540 authorized user agent, it MUST NOT be altered in transit, and it MUST
541 NOT be readable by an unauthorized third party.
543 6.3. Protecting Logs
545 A SIP entity that has logged information SHOULD encrypt it, such that
546 it can be decrypted only by a person authorized to examine the logged
547 information.
549 7. Augmented BNF for the "debug" Parameter
551 ABNF is described in RFC 5234 [RFC5234]
553 debug-param = "debug"
555 8. IANA Considerations
557 8.1. Registration of the "debug" Parameter
559 The following parameter is to be added to the "Header Field
560 Parameters and Parameter Values" section of the SIP parameter
561 registry:
563 +--------------+----------------+-------------------+-----------+
564 | Header Field | Parameter Name | Predefined Values | Reference |
565 +--------------+----------------+-------------------+-----------+
566 | Session-ID | debug | No | [RFCXXXX] |
567 +--------------+----------------+-------------------+-----------+
569 Table 1
571 9. References
573 9.1. Normative References
575 [I-D.ietf-insipid-logme-reqs]
576 Dawes, P. and C. Arunachalam, "Requirements for Marking
577 SIP Messages to be Logged", draft-ietf-insipid-logme-
578 reqs-07 (work in progress), July 2016.
580 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
581 Requirement Levels", BCP 14, RFC 2119,
582 DOI 10.17487/RFC2119, March 1997,
583 .
585 [RFC7206] Jones, P., Salgueiro, G., Polk, J., Liess, L., and H.
586 Kaplan, "Requirements for an End-to-End Session
587 Identification in IP-Based Multimedia Communication
588 Networks", RFC 7206, DOI 10.17487/RFC7206, May 2014,
589 .
591 9.2. Informative References
593 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
594 Specifications: ABNF", STD 68, RFC 5234,
595 DOI 10.17487/RFC5234, January 2008,
596 .
598 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session
599 Initiation Protocol (SIP) Back-to-Back User Agents",
600 RFC 7092, DOI 10.17487/RFC7092, December 2013,
601 .
603 Author's Address
605 Peter Dawes
606 Vodafone Group
607 The Connection
608 Newbury, Berkshire RG14 2FN
609 UK
611 Email: peter.dawes@vodafone.com