Internet DRAFT - draft-jesske-dispatch-forking-answer-correlation

draft-jesske-dispatch-forking-answer-correlation







dispatch                                                     R.J. Jesske
Internet-Draft                                          Deutsche Telekom
Intended status: Informational                              4 March 2024
Expires: 5 September 2024


Correlation of multiple responses of forked INVITES in Back to Back User
                                 Agents
          draft-jesske-dispatch-forking-answer-correlation-04

Abstract

   This document describe how a correlation of multiple responses of a
   forked INVITE in Back to Back User Agents can apply.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 5 September 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components



Jesske                  Expires 5 September 2024                [Page 1]

Internet-Draft     forking answer correlation in B2BUA        March 2024


   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Consideration of RFC's on SIP signalling procedures under
           consideration for forking use cases . . . . . . . . . . .   5
     2.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  RFC3261 Session Initiation Protocol . . . . . . . . . . .   6
     2.3.  RFC3960 Early Media and Ringing Tone Generation in the
            Session Initiation Protocol (SIP)  . . . . . . . . . . .   7
     2.4.  RFC3262 Reliability of provisional responses  . . . . . .   8
     2.5.  RFC3312 Integration of Resource Management and Session
            Initiation Protocol (SIP)  . . . . . . . . . . . . . . .   8
     2.6.  RFC3841 Caller Preferences for the Session Initiation
            Protocol (SIP) . . . . . . . . . . . . . . . . . . . . .   9
     2.7.  RFC5393 Addressing an Amplification Vulnerability in
            Session Initiation Protocol (SIP) Forking Proxies  . . .   9
     2.8.  RFC6228 Session Initiation Protocol (SIP) Response Code for
            Indication of Terminated Dialog  . . . . . . . . . . . .  10
     2.9.  RFC3326 The Reason Header Field for the Session Initiation
            Protocol (SIP) . . . . . . . . . . . . . . . . . . . . .  10
     2.10. Conclusions . . . . . . . . . . . . . . . . . . . . . . .  10
   3.  Requirements on forking in SIP networks interconnecting with
           other SIP networks  . . . . . . . . . . . . . . . . . . .  11
   4.  Forking use cases . . . . . . . . . . . . . . . . . . . . . .  11
     4.1.  Normal Forking use case . . . . . . . . . . . . . . . . .  11
     4.2.  Multiples provisional responses without SDP . . . . . . .  13
     4.3.  Forking use case with provisional responses with SDP using
           100rel  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     4.4.  Forking use case with provisional responses with SDP using
           100rel and preconditions  . . . . . . . . . . . . . . . .  18
     4.5.  Forking use case with early media played  . . . . . . . .  22
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  24
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  24
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  24
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  26
   Appendix A.  Appendix . . . . . . . . . . . . . . . . . . . . . .  26
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  26









Jesske                  Expires 5 September 2024                [Page 2]

Internet-Draft     forking answer correlation in B2BUA        March 2024


1.  Problem Statement

   Within RFC3261 [RFC3261] the handling of multiples early responses
   received from different UAS for one sent INVITE is described as basis
   feature.  Such behavior results usually in case of forking or also
   when an INVITE is forwarded to another target.

   The forking feature described in RFC3261 [RFC3261] allows to spread
   the INVITE request towards multiples registered UA's for one identity
   but is present at different locations.

   A forwarding as described in RFC3960 [RFC3960]of a SIP Dialog may
   result in multiples early dialogs(181 and 180 with different to
   tags).  A 181 response may also initiate an early dialog.

   There are scenarios within the scope of this document where multiple
   responses received should be multiplexed to a single dialog to avoid
   complexity or miss behavior for the originating network/UAC:

   1.  When a SIP entity (B2BUA) provides a service within the SIP path
   where multiples early responses received must be multiplexed into a
   single dialog.

   2.  Providing interconnecting between different networks with
   different behavior where a the originating network implementations do
   not wish, have restrictions or may not able handle multiples
   responses while the destination still deliver multiples responses or
   early dialogs.

   3.  Providing interconnection where the terminating service provider
   will have or must have control what kind of early dialog information
   should be provided to the originating network based on bilateral
   agreement, service provider policy or regulatory policy.

   4.  Service provider providing the forking feature or interconnecting
   to networks providing multiples early dialogs to INVITES would like
   to increase the reliability of the network in increasing successful
   calls even if UAC do not really support the correct handling of
   multiples early dialogs.  Please Note that this scenario is assuming
   that old or faulty implementations are existing.  This is real life
   and service provider are already using healing functions within B2BUA
   but it is clear that the correct way is to replace or correct faulty
   implementations of SIP.

   Scenario 1:






Jesske                  Expires 5 September 2024                [Page 3]

Internet-Draft     forking answer correlation in B2BUA        March 2024


   A service example may be a directory service providing a early
   dialog/session with a Interactive Voice Response (IVR) system for
   requesting a destination number where the user will be automatically
   forwarded to a identity where a couple of UAS are registered within
   the SIP network.  Thus the INVITE will be forked and result in
   multiples responses to the INVITE sent by the SIP entity providing
   the service.  It could be also a normal call forwarding scenario
   providing a short announcement to the UAC indicating the forwarding.
   Due to the fact that a early session was already provided by the
   service it needs an mapping of the multiples responses towards the
   UAC to provide the ringing state, tone or provide further
   announcements.

   Scenario 2:

   Due to the fact that the world of SIP networks is steadily growing
   and SIP networks based on IETF RFC 3261 are existing with different
   flavors like based on pure SIP, 3GPP IMS or ETSI TISPAN NGN and many
   others.  Now connecting these networks which may be operated by
   different service provides may result in complexity due to signaling,
   charging or even worse in faulty cases.  Providing voice services via
   SIP over restricted access capabilities may need restrictions with
   regard to numbers of early sessions provided in backward direction or
   signaling load.

   Other service providers do only allow single dialog over
   interconnection to avoid charging complexity with too many early
   sessions or early dialogs.

   Also equipment and UAC not understanding or misbehaving when
   receiving multiples responses may be in focus when restricting the
   interconnection use case to a single early dialog.

   Scenario 3:

   Within this scenario the terminating service provider apply specific
   policy.  This may be either in guaranteeing his customers to provide
   forking to for all entities registered for a specific identity, or
   allow only specific announcements (e.g in a specific language) passed
   through or to ensure the bilateral agreements with other operators
   where only single dialog is mandated.  Also in forwarding scenarios
   some originating networks do not wish to have a forwarding indication
   (i.e. 181) or early session in backward direction.

   Scenario 4:






Jesske                  Expires 5 September 2024                [Page 4]

Internet-Draft     forking answer correlation in B2BUA        March 2024


   As already stated this is a real life scenario but seen from
   implementation point of view the wrong approach.  The real solution
   is to replace or correct faulty implementations of SIP.

   But nevertheless the problem existing is that feature forking is not
   really supported by all UAC in that way that a connection between UAC
   and one of the UAS will succeed in a successful communication even
   one of the UAS sends a 200 OK for the INVITE.  This apply also to
   networks having B2BUA's (e.g.  PSTN interworking Gateways or Session
   Border Controller) in the path which should understand multiples
   responses and handle it correctly.

   Providing solutions for scenarios 1-3 will also provide a possibility
   for service provider to support scenario 4.

   This document evaluates the existing forking mechanism described in
   RFC3261 [RFC3261] and further RFC_s extending SIP for early dialog
   handling, resource handling and reliability of provisional responses.
   Also directives and SIP extensions will be investigated where forking
   or fraud based on forking may be avoided.  It will result in
   different use cases and solutions for the above mentioned scenarios
   where multiples responses are received by B2BUA and may be
   multiplexed to a single dialog.

   This document describes how a correlation/multiplexing for multiples
   early dialogs and other received Responses can done within a B2BUA.
   The possible roles of a B2BUA is described in the taxonomy document
   RFC7029 [RFC7029] The role of the B2BUA is a Signaling/Media Plane
   B2BUA Role.  Thus many possible use cases which will be possible
   looking on the used features are considered in this document.

   It is NOT within the scope of this document to deploy new SIP
   procedures but it is within the scope to use existing SIP procedures
   to describe the proper multiplexing.

2.  Consideration of RFC's on SIP signalling procedures under
    consideration for forking use cases

2.1.  Overview

   The following sections shows the documentation for forking in
   different RFCs and what is missing to apply a correlation of
   multiples early dialogs.  Also what procedures should apply for a
   correct handling of multiples early dialogs.







Jesske                  Expires 5 September 2024                [Page 5]

Internet-Draft     forking answer correlation in B2BUA        March 2024


2.2.  RFC3261 Session Initiation Protocol

   SIP defined in RFC3261 [RFC3261]describes how forking should apply.
   In Section 10 of RFC3261 [RFC3261] it is defined that registration
   creates bindings in a location service for a particular domain that
   associates an address-of-record URI with one or more contact
   addresses.  Thus when receiving an INVITE with a Request-URI that
   matches the address-of-record, the proxy will forward the request to
   the contact addresses registered to that address-of-record.  Proxy
   behavior in RFC3261 [RFC3261] section 16.6 of describes that a
   stateful proxy MAY choose to "fork" a request, routing it to multiple
   destinations.  Any request that is forwarded to more than one
   location MUST be handled statefully.  Forking apply serial or
   parallel.  Thus the forking proxy is either waiting for a final
   response or a timeout before sending the INVITE to the next contact
   or sent the INVITE parallel to the contacts registered for one
   address of record.  Considering the forking proxy when the INVITE was
   sent one or multiple provisional responses may arrive before one or
   more final responses are received.  As RFC3261 [RFC3261] describes
   these provisional responses may create "early dialogs". and will be
   forwarded to the UAC.

   This concludes that receiving provisional responses may either create
   early dialogs or will be ignored by the UAC.

   The UAC procedures allow receiving one or more provisional responses.
   The description how to be have exactly is not given by RFC3261
   [RFC3261].  Under Section 12.1 "Creation of a Dialog" describes that
   early dialogs will be established by non final 101-199 responses.  No
   more hints given within this section (e.g. 12.2.1.2 Processing the
   Responses) how to behave when receiving multiples provisional
   responses.  The termination of early dialogs is clear described that
   if the dialog is terminated (with BYE) all early dialogs are also
   terminated.  The termination of early dialogs will also be processed
   when receiving a final non 200 OK response.

   For session creation the description of response handling to an sent
   INVITE is more precise.  Within section 13.1 it is stated that a UA
   will open multiples dialogs when receiving multiples 200OK to an
   forked INVITE which are then within the same call.  Within section
   13.2.2.1 1xx Responses it is stated that Provisional responses for an
   INVITE request can create "early dialogs".  Early dialogs are only
   needed for sending requests to its peer within the dialog before the
   initial INVITE transaction completes.  This imply that if the UAC
   does not support the creation of "early dialogs" that provisional
   responses will be ignored by the UAC.  Provisional responses may
   contain the same exact SDP answer sent prior to the answer within the
   final 2xx response.  Editors Note: It is not stated in RFC3261 what



Jesske                  Expires 5 September 2024                [Page 6]

Internet-Draft     forking answer correlation in B2BUA        March 2024


   happen in cases of early dialogs arriving with different SDP and also
   receiving RTP for that dialogs. i.e. more information will deliver
   RFC3960 "Early Media and Ringing Tone Generation in the Session
   Initiation Protocol (SIP)"

   Note that it is not clearly stated what happen if the SDP is
   different between provisional response and final answer.  It is
   assumed that such information will be ignored by the UA.

   The conclusion is that rules for UAC on responses in general and
   merged requests are defined.  For the normal RFC3261 [RFC3261]
   forking use case only final Responses (200 OK) will be considered to
   create a dialog/session.  This also apply when provisional responses
   due to other services (e.g. 181 in case of forwarding) will arrive at
   the UAC.

   A couple of rules with regard to responses when forwarding it to the
   UAC apply to the forking proxy.  1xx and 2xx response will be
   forwarded immediately.  For 6xx Responses the proxy SHOULD cancel all
   client pending transactions.  The Response-Context as defined in
   RFC3261 [RFC3261] Section 16.7 Response Proceeding" does describe how
   the forking proxy should behave when receiving responses from
   different branches.  According to the rules in this section the proxy
   will hold the received non 2xx final responses until for all INVITE
   transactions a final response is received.  The Forking proxy has to
   choose a final response.  One free chosen out of of the lowest
   response class stored.  Preference to that response giving additional
   information affecting resubmission (such as 401, 407, 415, 420, and
   484 if the 4xx class is chosen) A 503 should be changed to 500.

   Thus with regard to non 2xx and 1xx final responses the forking proxy
   has to aggregate and act as central element

   Conclusion is that RFC3261 [RFC3261] describes the possibility of
   forking a INVITE, the forking proxy behavior and the UAC behavior to
   either ignore all provisional responses or open multiples early
   dialogs and accept one or more final responses.

2.3.  RFC3960 Early Media and Ringing Tone Generation in the Session
      Initiation Protocol (SIP)

   As for early media and Forking RFC3960 [RFC3960] describes two models
   for providing early media.  There are the gateway model and the
   Application Server model described.  Both have their constrains with
   forking.  The gateway model will present all early media streams to
   the user in cases where the UAC will not choose one media stream it
   will confuse the human hearing this mix of media streams.  Also
   bandwidth restrictions will end in bad quality.



Jesske                  Expires 5 September 2024                [Page 7]

Internet-Draft     forking answer correlation in B2BUA        March 2024


   The application Server model is based on an early-session disposition
   type which will not be supported by every UAC.

   This RFC does not describe the possibility of multiplexing multiples
   early media streams to one.  Or a choosing mechanism for UAC which of
   the early dialog should be used to play the announcement.

   Since this RFC does not consider B2BUA with media awareness as
   defined in RFC7029 [RFC7029] some possible functionality is missing
   where media can be correlated.

2.4.  RFC3262 Reliability of provisional responses

   The RFC describing the reliability of provisional Responses RFC3262
   [RFC3262] does not describe directly interactions with forking.  It
   defines the PRACK method and describes the procedures to make a
   provisional response reliable.  Thus the SDP of a 200OK is not longer
   needed.

   The important statement is that user agents that support this 100rel
   MUST support all offer/answer exchanges that are possible based on
   the rules in Section 13.2 of RFC3261 [RFC3261], based on the
   existence of INVITE and PRACK as requests, and 2xx and reliable 1xx
   as non-failure reliable responses.  Thus with forking the UAC has to
   make each received provisional Response reliable.  Specific
   procedures for a forking proxy does not exist since it has only to
   pass the responses.

2.5.  RFC3312 Integration of Resource Management and Session Initiation
      Protocol (SIP)

   RFC3313 [RFC3312] describing the precondition mechanism is not
   mentioning any interactions with forking relevant issues.

   Since RFC3262 [RFC3262] is a precondition to apply to the procedures
   of RFC3313 [RFC3312].  Following that the UAC has to make the
   resourcereservation with each forking branch where the provisional
   response is stating 100rel required.  The UAC will have to implement
   complex procedures to make the ressource reservation to all received
   SDP.  And it could lead to the same problems as stated for the early
   media use case.  Also network procedures may be influences.  I.e
   B2BUA with media awareness as defined in RFC7029 [RFC7029] have to
   reserve resources and have to proceed correctly like in releasing
   brances where capacity restirctions will aply within the media
   reservation functionality.






Jesske                  Expires 5 September 2024                [Page 8]

Internet-Draft     forking answer correlation in B2BUA        March 2024


2.6.  RFC3841 Caller Preferences for the Session Initiation Protocol
      (SIP)

   RFC3841 [RFC3841] describes extensions to the Session Initiation
   Protocol (SIP) which allow a caller (UAC) to express preferences
   about request handling in servers.

   One of the caller preferences defined in RFC3841 [RFC3841].  is a
   method to signal the "fork-directive" to indicate that the UAC does
   not wish that SIP proxy will fork the INVITE request.  This directive
   is a optional SIP feature the forking proxy is not forced to apply to
   the directive sent by the UAC.  Also not each network element
   providing forrking has implemented this directive.

   The parallel-directive does indicate how a SIP proxy may fork the
   request.  Either "parallel" or "sequential"

   A B2BUA with media awareness as defined in RFC7029 [RFC7029] may use
   this directive to avoid multiples provisional responses sent back due
   to forking.  But as said it will not give security for avoiding
   forking.  Thia may a tool for interconnection between service
   providers.

2.7.  RFC5393 Addressing an Amplification Vulnerability in Session
      Initiation Protocol (SIP) Forking Proxies

   To avoid too many forkings (possible early Dialogs) RFC5393 [RFC5393]
   defines the Max-Breadth header to avoid to many forked Requests
   caused by froking proxies.  But there is no effect on correlating the
   responses.  This helps to reduce a cascading of multiples forkings in
   the forward path.  The number in the header gives the maximum
   branches (parallel possible early dialogs) of a forked request.
   Exceeding the maximum will result in error responses 440

   A Max-Breadth of 1 restricts a request to pure serial forking rather
   than restricting it from being forked at all.

   RFC5393 [RFC5393] specifies normative changes to the SIP protocol.
   And it mandates if a SIP proxy receives a request with no Max-Breadth
   header field value, it MUST add one, with a value that is RECOMMENDED
   to be 60.  Seent from theory a parallel forking could be avoinded but
   nevertheless not all SIP networks will have implemented this RFC and
   will understnd these extensions.








Jesske                  Expires 5 September 2024                [Page 9]

Internet-Draft     forking answer correlation in B2BUA        March 2024


2.8.  RFC6228 Session Initiation Protocol (SIP) Response Code for
      Indication of Terminated Dialog

   RFC6228 [RFC6228]defines a new response code to close early dialogs
   proper.  In case where a forking proxy realizes that a 200 OK has
   been processed the proxy can sent 199 responses to the other open
   dialogs.  This helps in case of correlation when early dialogs has
   been sent till the end user.

   In consideration with the rules defined in RFC3261 for forking proxy
   a received non 2xx final to an initial dialog initiation request that
   it recognizes as terminating one or more early dialogs associated
   with the request.  The forking proxy generates normally (e.g. non
   100rel, no final response sent) 199 response upstream for each of the
   terminated early dialogs.

2.9.  RFC3326 The Reason Header Field for the Session Initiation
      Protocol (SIP)

   RFC3326 [RFC3326] defines the Reason header and describes one use
   where the INVITE is forked and results in a rejection, the error
   response may never be forwarded to the client unless all the other
   branches also reject the request.  This problem is known as the
   "Heterogeneous Error Response Forking Problem", or HERFP.  It is
   foreseen that a solution to this problem may involve encapsulating
   the final error response in a provisional response.  The Reason
   header field is a candidate to be used for such encapsulation.  In
   this case the forking proxy will release the dialogs.

   This will help to analyse problems with forking but will

2.10.  Conclusions

   All above mentioned RFCs and procedures describes a piece of the
   whole picture how forking apply and what procedures are useabel for
   such cases.  It is also fact that UA's and B2BUA's (e.g.  PSTN GW)
   are existing that will not support multiples early dialogs.  Also the
   support of caller preferences is not secured or implemented by UAC
   and also SIP forking proxies.  Service providers will provide forking
   independent what the source will support or not.  Thus the only
   solution seen is to describe procedures which apply in B2BUA to
   support an correlation of multiples early dialogs and other received
   18x Responses.








Jesske                  Expires 5 September 2024               [Page 10]

Internet-Draft     forking answer correlation in B2BUA        March 2024


3.  Requirements on forking in SIP networks interconnecting with other
    SIP networks

   To improve interoperability with devices which do not support
   forking, a service provider shall have the possibility to use a B2BUA
   to multiplex multiple downstream dialogs into a single dialog toward
   the caller."

   The B2BUA providing such possibility must have to understand where
   the SIP dialog request is coming from and if this originating network
   or entity or UA can or cannot support multiples responses.  This
   could be also assumed by Service Level Agreements (SLA) between the
   interconnection partners.

   The main requirement is to have an entity that can receive multiples
   responses based on forked INVITES which now can be correlated to one
   single dialog towards the originating entity.

   To act proactive the B2BUA should also be possible to include and
   handle preferences (e.g. non forking wished) based on the originating
   and terminating network.


4.  Forking use cases

4.1.  Normal Forking use case

   SIP defined in RFC3261 [RFC3261]describe how forking should apply.
   Also rules for UA for responses and merged requests are defined.
   Since the provisional response is not final there should be no
   influence on the call stated due to media.  An SDP sent in a 18x must
   be the same as for the final response.  The numbers in brackets shows
   the INVITES/early dialogs created.


















Jesske                  Expires 5 September 2024               [Page 11]

Internet-Draft     forking answer correlation in B2BUA        March 2024


   UAC           Proxy    Forking Proxy       UAS_2   UAS_3   UAS_4
   |             |             |                |       |       |
   |-- INVITE -->|             |                |       |       |
   |             |-- INVITE -->|-- INVITE (2) ->|       |       |
   |             |             |-- INVITE (3) --------->|       |
   |             |             |-- INVITE (4) ----------------->|
   |             |             |<-- 18x (2) ----|       |       |
   |<- 18x (2) --|<- 18x (2) --|                |       |       |
   |             |             |<-- 18x (3) ------------|       |
   |<- 18x (3) --|<- 18x (3) --|                |       |       |
   |             |             |<-- 18x (4) --------------------|
   |<- 18x (4) --|<- 18x (4) --|                |       |       |
   |             |             |                |       |       |
   |             |             |<-- 200 (4) --------------------|
   |             |<- 200 (4) --|                |       |       |
   |<- 200 (4) --|             |                |       |       |
   |-- ACK (4) ->|             |                |       |       |
   |             |--- ACK (4) >|                |       |       |
   |             |             |--- ACK (4) ------------------->|
   |             |             |                |       |       |
   |             |             |--CANCEL (2)--->|       |       |
   |             |             |<-- 200 (2) ----|       |       |
   |             |             |<-- 487 (2) ----|       |       |
   |             |             |--- ACK (2)---->|       |       |
   |             |             |                |       |       |
   |             |             |--- CANCEL(3) --------->|       |
   |             |             |<-- 200 (3) ------------|       |
   |             |             |<-- 487 (3) ------------|       |
   |             |             |--- ACK (3)------------>|       |
   |             |             |                |       |       |
                   Figure 1: Example Call Flow Forking



                                  Figure 1

   As you can see, this figure shows the normal forking case where each
   UA sends a 18x either with or without SDP.  UAS_4 sends a final
   response and the forking proxy has to cancel all other open
   provisional responses.  The 487 is sent back to the forking proxy on
   each early dialog (2) and (3) created in the UAS.

   Further possible scenarios are that two or three UAS will answer the
   call with 200 in time so that the UAC has now three open sessions
   which is not really the goal when a user would like to communicate
   with only one person.





Jesske                  Expires 5 September 2024               [Page 12]

Internet-Draft     forking answer correlation in B2BUA        March 2024


   Figure 1 shows an normal example of forking.  With receiving 18x the
   UAC has to open transaction.  So only UAA_4 answers the dialog
   correctly.  It is task of the forking proxy to cancel the remaining
   open early dialogs


4.2.  Multiples provisional responses without SDP

   This section describes the use case where multiples 18x responses are
   sent back which doesn't contain any SDP.  This use case appear when
   the UAS instances where the INVITE is forked without any specific
   requirements and support of specific extensions like 100rel

   In this specific case the B2BUA has not to anchor the media and acts
   only as signalling B2BUA and has to maintain the signalling legs




































Jesske                  Expires 5 September 2024               [Page 13]

Internet-Draft     forking answer correlation in B2BUA        March 2024


   UAC         B2BUA    Forking Proxy       UAS_2   UAS_3   UAS_4
   |              |               |                |     |     |
   |-INVITE(1)F1->|               |                |     |     |
   |              |- INVITE F2 -->|- INVITE F3(2)->|     |     |
   |              |               |- INVITE F4(3)------->|     |
   |              |               |- INVITE F5(4)------------->|
   |              |               |<-- 18x (2) F6--|     |     |
   |<- 18x (1) F8-|<- 18x (2) F7 -|                |     |     |
   |              |               |<-- 18x (3) F9--------|     |
   |              |<- 18x (3) F10-|                |     |     |
   |              |               |                |     |     |
   |              |               |<-- 18x (4) F11-------------|
   |              |<- 18x (4) F12-|                |     |     |
   |              |               |                |     |     |
   |              |               |                |     |     |
   |              |               |<-- 200 SDP (4)F13----------|
   |              |<- 200 (4) F14-|                |     |     |
   |<- 200(1) F15-|               |                |     |     |
   |              |               |- CANCEL F16 -->|     |     |
   |              |               |<- 200 (2) F17 -|     |     |
   |              |               |<- 487 (2) F18 -|     |     |
   |              |               |-- ACK (2) F19->|     |     |
   |              |               |                |     |     |
   |              |               |- CANCEL (3) F20 ---->|     |
   |              |               |<----200 (3) F21 -----|     |
   |              |               |<--- 487 (3) F22 -----|     |
   |              |               |---- ACK (3) F23 ---->|     |
   |              |               |                |     |     |
   |- ACK(1) F24->|               |                |     |     |
   |              |- ACK (4) F26->|                |     |     |
   |              |               |--- ACK (4) F27------------>|

                      Figure 2: Example Call Flow

                                  Figure 2

   The B2BUA will maintain a Dialog between UAC and the incoming part of
   the B2BUA (UAS) And acts as UAC towards the terminating network
   (UAS_2, UAS_3 and UAS_4).  The INVITE F1 will have another Call-Id as
   INVITE F2, also the to-tags are different.

   The first 18x (F7) will be passed towards the UAC.  The tags (to-tag,
   from-tag), call-id etc will be stored by the B2BUA.  The 18x sent
   towards the UAC will contain the to-tag, Call-Id of INVITE F1 and the
   from-tag is generated by the B2BUA.  With arriving further 18x (F10,
   F12) the B2BUA has to store the status of the to-tags etc and will
   not forward the 180 to the UA.




Jesske                  Expires 5 September 2024               [Page 14]

Internet-Draft     forking answer correlation in B2BUA        March 2024


   With arriving arriving the 200OK (F14) at the B2BUA with the SDP sent
   back form UAS_4 the B2BUA will sent a 200 OK towards the UAC.  In
   this case the B2BUA re-written the to-tag, from-tan and call-id as
   already done or response 18x F7.

   As for normal forking the forking proxy is responsible for canceling
   the open dialogs with the CANCEL F16 and F20.  The CANCEL will be
   initiated with receiving/sending the final 200 OK response And ACK
   F24 finalizes the call initiation.

   The B2BUA has normally not to anchor signalling plane i.e as
   signalling B2BUA.  Such option may be applied when sending the INVITE
   F2 towards the UAS.  In cases where the received INVITE has no tags
   included which indicate the possibility of 100 rel, preconditions or
   early media the B2BUA may handle this specific call as a stateless
   proxy.

4.3.  Forking use case with provisional responses with SDP using 100rel

   This section describes use case where 100rel will be used.  This
   apply in networks where announcements will be played reliability.
   The mechanism for making the provisional responses reliable is
   described in RFC3262 [RFC3262].  A B2BUA doing correlation in between
   allows only one early dialog sent back to the UAC.  The B2BUA has to
   anchor the SIP Dialogs as well as the media reservation streams.

   This use case apply where multiples 18x responses are sent back with
   different SDP content.  This use case appear when the UAS instances
   where the INVITE is forked to will use different codecs.  E.G one UAS
   is a video phone answering with a video codec the other one a mobile
   phone and a further one using a DECT entity.

   And one or more UAS will require reliability of provisional
   responses.  Please Note that such a behavior could be also caused by
   an application server playing specific announcements which acts on
   behalf of the UAS

   There is the possibility based on the request if the 100rel mechanism
   will only be used between B2BUA and UAS or really end to end.  In
   case where the 100rel is stated as supported it is not mandatory to
   use it.  When the UAS want to have the 18x reliable it will set the
   100rel into the require header field.  In that case where a 18x is
   sent back with a 100rel required then the B2BUA may play the role of
   anchoring the media and apply the 100rel between B2BUA and UAS and
   let the UAC to B2BUA connection as unreliable.






Jesske                  Expires 5 September 2024               [Page 15]

Internet-Draft     forking answer correlation in B2BUA        March 2024


   Please note that this is only needed in cases where the media
   anchoring has to do some manipulation of the media e.g.  transcoding
   of codecs.

   Where the B2BUA decides to pass the required 100rel header field the
   UAC will send then the PRACK and waits for the 200 OK.  In case there
   are further 18x with equal other type of SDP arriving at the B2BUA .
   B2BUA has to keep handle the 100rel and sent the PRACK to the UAS.

   Preconditions: INVITE 100rel supported is set and in 18x a SDP with
   100rel required is sent back

   UAC         B2BUA        Forking Proxy        UAS_2 UAS_3 UAS_4
   |              |               |                |     |     |
   |- INVITE F1-->|               |                |     |     |
   |              |- INVITE F2 -->|- INVITE F3(2)->|     |     |
   |              |               |- INVITE F4(3)------->|     |
   |              |               |- INVITE F5(4)------------->|
   |              |               |<-18x SDP(2)F6--|     |     |
   |              |<-18x SDP(2)F7-|                |     |     |
   |<-18xSDP(1)F8-|               |                |     |     |
   |- PRACK(1)F9->|               |                |     |     |
   |              |- PRACK(2)F10->|                |     |     |
   |              |               |- PRACK(2) F10->|     |     |
   |              |               |<-- 200  F11(2)-|     |     |
   |              |<- 200 (2)F12--|                |     |     |
   |<- 200(1) F13-|               |                |     |     |
   |              |               |<-- 18x (3) F14-------|     |
   |              |<- 18x (3)F15--|                |     |     |
   |              |- PRACK(2)F16->|                |     |     |
   |              |               |- PRACK (3) F17 ----->|     |
   |              |               |<---200 (3) F18 ------|     |
   |              |<- 200 (3)F19--|                |     |     |
   |              |               |                |     |     |
   |              |               |                |     |     |
   |              |               |<-- 18x (4) F20-------------|
   |              |<- 18x (4)F21 -|                |     |     |
   |              |- PRACK(4)F22->|                |     |     |
   |              |               |- PRACK(4) F23 ------------>|
   |              |               |<-- 200(4) F24 -------------|
   |              |<- 200 (4)F25 -|                |     |     |
   |              |               |                |     |     |
   |              |               |                |     |     |
   |              |               |<-- 200 SDP (4)F26----------|
   |              |<-200SDP(4)F27-|                |     |     |
   |<UPDATE(1) F28|               |                |     |     |
   |- 200 (1)F29->|               |                |     |     |
   |<- 200(1) F30-|               |                |     |     |



Jesske                  Expires 5 September 2024               [Page 16]

Internet-Draft     forking answer correlation in B2BUA        March 2024


   |              |               |-CANCEL(2) F31->|     |     |
   |              |               |<--200 (2) F32--|     |     |
   |              |               |<--487 (2) F33--|     |     |
   |              |               |---ACK (2) F34->|     |     |
   |              |               |                |     |     |
   |              |               |- CANCEL (3) F35 ---->|     |
   |              |               |<----200 (3) F46 -----|     |
   |              |               |<----487 (3) F37 -----|     |
   |              |               |<----ACK (3) F38 -----|     |
   |              |               |                |     |     |
   |              |               |                |     |     |
   |- ACK(2) F39->|               |                |     |     |
   |              |- ACK (4) F40->|                |     |     |
   |              |               |--- ACK (4) F41------------>|


              Figure 3: Example Call Flow with 100rel


                                  Figure 3

   F1: INVITE SDP offer A1 (Codec A, Codec B)Dialog 1 F3: INVITE SDP
   offer A2 (Codec A, Codec B)Dialog 2 F4: INVITE SDP offer A2 (Codec A,
   Codec B)Dialog 3 F5: INVITE SDP offer A2 (Codec A, Codec B)Dialog 4
   F7: 18x SDP answer A2 (Codec A) Dialog 2 F8: 18x SDP answer A1 (Codec
   A) Dialog 1 F9: PRACK no SDP Dialog 1 F10: PRACK no SDP Dialog 2 F12:
   200 OK(PRA) Dialog 2 F13: 200 OK(PRA) Dialog 1 F15: 18x SDP answer A3
   (Codec B) Dialog 3 F16: PRACK no SDP Dialog 3 F19: 200 OK(PRA) Dialog
   3 F21: 18x SDP answer A4 (Codec A,Codec B) Dialog 4 F22: PRACK no SDP
   Dialog 4 F25: 200 OK(PRA) Dialog 4 F27: 200 OK(INV) Dialog 4 F28:
   UPDATE SDP offer A4 (Codec A,Codec B) Dialog 1 F29: 200 OK(UPD) SDP
   answer A4 (Codec A,Codec B) Dialog 1 F30: 200 OK(INV) SDP Answer A4
   (Codec A,Codec B) Dialog 1

   Call will be forked to 3 end devices.  UAS_2 answers with 18x (F6-F7)
   containing a SDP and 100rel required.  18x (F8) is passed to the UAC
   and made reliable with PRACK (F9-F13) Further 18x (F15/F21) arrive at
   the B2BUA.  The B2BUA stores the to tag for the call context.  The
   B2BUA will answer the 18x (F15/F21) and made it reliable with PRACK
   (F16-F19/F22-F24).  And also update the SDP negotiated between B2BUA
   and UAC with further UPDATE messages.  No further activity is done
   towards the UAC.  The B2BUA does not need any media awareness for
   this procedures as long there is no need for transcoding or other
   manipulation of media.

   With arriving of a 200 OK (F27) at the B2BUA from UAS_4 the B2BUA has
   to construct first an UPDATE (F28) in the case that the SDP differs
   from the last 18x (F28) sent to the UAC.  The 200 OK (F26) received



Jesske                  Expires 5 September 2024               [Page 17]

Internet-Draft     forking answer correlation in B2BUA        March 2024


   by the B2BUA and triggers the final response to the UAC (F27).
   Editors NOTE: Clarification needed if the UPDATE or 200OK INVITE must
   be sent first.  Problem could be that media clipping may appear.  and
   if so, what needs the 200 OK to contain in the SDP.

   Also all other open Call legs are canceled (F31-44) by normal forking
   proxy procedures as described in RFC3261 [RFC3261].

4.4.  Forking use case with provisional responses with SDP using 100rel
      and preconditions

   This section describes use case where preconditions will be used.
   This apply in mobile networks where resource reservation is needed.
   Also normal networks may use preconditions when access bandwith is
   problematic . The recondition mechanism in RFC3312 [RFC3312] shows
   the needed additional procedures.  A B2BUA doing correlation in
   between to allows only one early dialog sent back to the UAC.  The
   B2BUA has to anchor the SIP Dialogs as well as the media reservation
   streams.

   This use case apply where multiples 18x responses are sent back with
   different SDP content.  This use case appear when the UAS instances
   where the INVITE is forked to will use different codecs.  E.G one UAS
   is a video phone answering with a video codec the other one a mobile
   phone and a further one using a DECT entity.

   This section describes the use case where the UAC sends a dialog
   request with 100rel and preconditions supported/required and the
   UAS_2 apply to the requested mechanisms.  The B2BUA has to have media
   awareness and also 3PCC capabilities.

   With applying preconditions the resource reservation needs to be
   finalized before 200 OK is sent.  In this scenario where the SIP call
   is forked and the first UAS answers with a 183 containing 100rel and
   preconditions requires an the correct SDP answer UAC, and UAS starts
   their resource reservation mechanism (F5-F18).  The B2BUA acts as
   signalling and media-aware functionality between the Forking Server
   and the UAC.

   When the UAS_3 will send back also an 183 containing SDP and their
   required header is set to 100rel and preconditions the B2BUA has to
   reserve the resources towards the UAS (F30-F37).  This use case
   assumes that the leg between the UAC and B2BUA will not be updated to
   avoid to many codec renegotiation and resource reservation.  Thus the
   B2BUA will renegotiate when the final 200 OK will arrive at the
   B2BUA.





Jesske                  Expires 5 September 2024               [Page 18]

Internet-Draft     forking answer correlation in B2BUA        March 2024


   UAC         B2BUA       Forking Proxy         UAS_2 UAS_3 UAS_4
   |              |               |                |     |     |
   |- INVITE F1-->|               |                |     |     |
   |              |- INVITE F2 -->|- INVITE F3(2)->|     |     |
   |              |               |- INVITE F4(3)------->|     |
   |              |               |<-- 183 (2) F5--|     |     |
   |              |<- 183 (2) F6 -|                |     |     |
   |<- 183 (1) F7-|               |                |     |     |
   |- PRACK(1)F8->|               |                |     |     |
   |              |- PRACK(2)F9-->|                |     |     |
   |              |               |- PRACK(2) F10->|     |     |
   |              |               |<-- 200  F11(2)-|     |     |
   |              |<- 200 (2) F12-|                |     |     |
   |<- 200(1) F13-|               |                |     |     |
   |UPDATE(1)F13->|               |                |     |     |
   |              | UPDATE(2)F14->|                |     |     |
   |              |               |- UPDATE(2)F15->|     |     |
   |              |               |<-- 200  F16(2)-|     |     |
   |              |<- 200 (2) F17-|                |     |     |
   |<- 200(1) F18-|               |                |     |     |
   |              |               |<-- 180 (2) F19-|     |     |
   |              |<- 180(2) F20 -|                |     |     |
   |<- 180(1) F21-|               |                |     |     |
   |-PRACK(1)F22->|               |                |     |     |
   |              |- PRACK(2)F23->|                |     |     |
   |              |               |- PRACK(2) F24->|     |     |
   |              |               |<-- 200  F25(2)-|     |     |
   |              |<- 200 (2) F26-|                |     |     |
   |<- 200(1) F27-|               |                |     |     |
   |              |               |<-- 183 (3) F28-------|     |
   |              |<- 183 (3) F29-|                |     |     |
   |              |- PRACK(3)F30->|                |     |     |
   |              |               |- PRACK F4(3)F31----->|     |
   |              |               |<----200 (3) F32 -----|     |
   |              |<- 200 (3) F33-|                |     |     |
   |              |               |                |     |     |
   |              |- UPDATE  F34->|                |     |     |
   |              |               |- UPDATE  F35 ------->|     |
   |              |               |<----200 (3) F36 -----|     |
   |              |<- 200 (3) F37-|                |     |     |
   |              |               |                |     |     |
   |              |               |<-- 200 SDP (3)F40----|     |
   |              |<- 200 (4) F41-|                |     |     |
   |<- UPDATE F42-|               |                |     |     |
   |-- 200 F43  ->|               |                |     |     |
   |<- UPDATE F44-|               |                |     |     |
   |-- 200 F45  ->|               |                |     |     |
   |<-- 200 F46  -|               |                |     |     |



Jesske                  Expires 5 September 2024               [Page 19]

Internet-Draft     forking answer correlation in B2BUA        March 2024


   |              |               |- CANCEL F47 -->|     |     |
   |              |               |<-- 200  F48(2)-|     |     |
   |              |               |<--487 (3) F49 -|     |     |
   |              |               |<--ACK (3) F50 -|     |     |
   |- ACK(1) F51->|               |                |     |     |
   |              |- ACK (3) F52->|                |     |     |
   |              |               |--- ACK (3) F53------>|

              Figure 4: Example Call Flow with preconditions


                                  Figure 4


   F1:  INVITE   SDP offer A1 (Codec A, Codec B)
   F7:  183      SDP answer A1 (Codec A)
   F13: UPDATE       SDP offer A2 (Codec A) UAC resources reserve
   F28: 200 OK       SDP Answer A2 (Codec A) UAS resources reserved
   F45: UPDATE       SDP offer A3 (Codec B)
   F46: 200 OK       SDP Answer A3 (Codec B)
   F47: UPDATE       SDP offer A4 (Codec B) 2BUA resources reserved
   F48: 200 OK       SDP Answer A4 (Codec B) UAS resources reserved
   F49: 200 OK       Final Response


                                  Figure 5

   Where the B2BUA decides to pass the required 100rel the UAC will send
   then the PRACK and waits for the 200 OK.  In case there are further
   18x with other type of SDP arriving at the B2BUA the UAC needs to be
   informed about change of codec.  The UAC has again to sent the PRACK.

   Editor's Note: Question is if the above described mechanism would be
   a proper mechanism since the later renegotiation + resource
   reservation could cause media clipping.  Figure 5 shows the other
   possibility.

   UAC         B2BUA       Forking Proxy         UAS_2 UAS_3
   |              |               |                |     |
   |- INVITE F1-->|               |                |     |
   |              |- INVITE F2 -->|- INVITE F3(2)->|     |
   |              |               |- INVITE F4(3)------->|
   |              |               |<-- 183 (2) F5--|     |
   |              |<- 183 (2) F6 -|                |     |
   |<- 183 (1) F7-|               |                |     |
   |- PRACK(1)F8->|               |                |     |
   |              |- PRACK(2)F9-->|                |     |
   |              |               |- PRACK(2) F10->|     |



Jesske                  Expires 5 September 2024               [Page 20]

Internet-Draft     forking answer correlation in B2BUA        March 2024


   |              |               |<-- 200  F11(2)-|     |
   |              |<- 200 (2) F12-|                |     |
   |<- 200(1) F13-|               |                |     |
   |UPDATE(1)F13->|               |                |     |
   |              | UPDATE(2)F14->|                |     |
   |              |               |- UPDATE(2)F15->|     |
   |              |               |<-- 200  F16(2)-|     |
   |              |<- 200 (2) F17-|                |     |
   |<- 200(1) F18-|               |                |     |
   |              |               |<-- 180 (2) F19-|     |
   |              |<- 180(2) F20 -|                |     |
   |<- 180(1) F21-|               |                |     |
   |-PRACK(1)F22->|               |                |     |
   |              |- PRACK(2)F23->|                |     |
   |              |               |- PRACK(2) F24->|     |
   |              |               |<-- 200  F25(2)-|     |
   |              |<- 200 (2) F26-|                |     |
   |<- 200(1) F27-|               |                |     |
   |              |               |<-- 183 (3) F28-------|
   |              |<- 183 (3) F29-|                |     |
   |              |- PRACK(3)F30->|                |     |
   |              |               |- PRACK F4(3)F31----->|
   |              |               |<----200 (3) F32 -----|
   |              |<- 200 (3) F33-|                |     |
   |              |               |                |     |
   |              |- UPDATE  F34->|                |     |
   |              |               |- UPDATE  F35 ------->|
   |              |               |<----200 (3) F36 -----|
   |              |<- 200 (3) F37-|                |     |
   |<- UPDATE F38-|               |                |     |
   |-- 200 F39  ->|               |                |     |
   |<- UPDATE F40-|               |                |     |
   |-- 200 F41  ->|               |                |     |
   |<- UPDATE F42-|               |                |     |
   |<-- 200 F43  -|               |                |     |
   |              |               |<-- 200 SDP (3)F44----|
   |              |<- 200 (4) F45-|                |     |
   |<-- 200 F46  -|               |                |     |
   |              |               |- CANCEL F47 -->|     |
   |              |               |<-- 200  F48(2)-|     |
   |- ACK(2) F49->|               |                |     |
   |              |- ACK (4) F50->|                |     |
   |              |               |--- ACK (4) F51------>|

      Figure 5: Example Call Flow with preconditions


                                  Figure 6



Jesske                  Expires 5 September 2024               [Page 21]

Internet-Draft     forking answer correlation in B2BUA        March 2024


   F1:  INVITE   SDP offer A1 (Codec A, Codec B)
   F7:  183          SDP answer A1 (Codec A)
   F13: UPDATE       SDP offer A2 (Codec A) UAC resources reserved
   F28: 200 OK       SDP Answer A2 (Codec A) UAS resources reserved
   F38: UPDATE       SDP offer A3 (Codec B)
   F39: 200 OK       SDP Answer A3 (Codec B)
   F40: UPDATE       SDP offer A4 (Codec B) 2BUA resources reserved
   F44-46 200 OK Final Response

                                  Figure 7

4.5.  Forking use case with early media played

   This use case describes the case where early media is played due to
   application server actions. e.g playing a ring tone or a specific
   announcement sent back.

   Note: More work is needed to describe the use case.

   UAC         B2BUA        Forking Proxy        UAS_2 UAS_3 UAS_4
   |              |               |                |     |     |
   |- INVITE F1-->|               |                |     |     |
   |              |- INVITE F2 -->|- INVITE F3(2)->|     |     |
   |              |               |- INVITE F4(3)------->|     |
   |              |               |- INVITE F5(4)------------->|
   |              |               |<-18x SDP(2)F6--|     |     |
   |              |<-18x SDP(2)F7-|                |     |     |
   |<-18xSDP(1)F8-|               |                |     |     |
   |- PRACK(1)F9->|               |                |     |     |
   |              |- PRACK(2)F10->|                |     |     |
   |              |               |- PRACK(2) F10->|     |     |
   |              |               |<-- 200  F11(2)-|     |     |
   |              |<- 200 (2)F12--|                |     |     |
   |<- 200(1) F13-|               |                |     |     |
   |              | (Announcement)|                |     |     |
   |<==============================================|     |     |
   |              |               |                |     |     |
   |              |               |                |     |     |
   |              |               |<-- 18x (3) F14-------|     |
   |              |<- 18x (3)F15--|                |     |     |
   |              |- PRACK(2)F16->|                |     |     |
   |              |               |- PRACK (3) F17 ----->|     |
   |              |               |<---200 (3) F18 ------|     |
   |              |<- 200 (3)F19--|                |     |     |
   |              |               |                |     |     |
   |              | (Announcement)|                |     |     |
   |              |<=====================================|     |
   |              |               |                |     |     |



Jesske                  Expires 5 September 2024               [Page 22]

Internet-Draft     forking answer correlation in B2BUA        March 2024


   |              |               |                |     |     |
   |              |               |<-- 18x (4) F20-------------|
   |              |<- 18x (4)F21 -|                |     |     |
   |              |- PRACK(4)F22->|                |     |     |
   |              |               |- PRACK(4) F23 ------------>|
   |              |               |<-- 200(4) F24 -------------|
   |              |<- 200 (4)F25 -|                |     |     |
   |              |               |                |     |     |
   |              | (Announcement)|                |     |     |
   |              |<===========================================|
   |              |               |                |     |     |
   |              |               |                |     |     |
   |              |               |<-- 200 SDP (4)F26----------|
   |              |<-200SDP(4)F27-|                |     |     |
   |<UPDATE(1) F28|               |                |     |     |
   |- 200 (1)F29->|               |                |     |     |
   |<- 200(1) F30-|               |                |     |     |
   |              |               |-CANCEL(2) F31->|     |     |
   |              |               |<--200 (2) F32--|     |     |
   |              |               |<--487 (2) F33--|     |     |
   |              |               |---ACK (2) F34->|     |     |
   |              |               |                |     |     |
   |              |               |- CANCEL (3) F35 ---->|     |
   |              |               |<----200 (3) F46 -----|     |
   |              |               |<----487 (3) F37 -----|     |
   |              |               |<----ACK (3) F38 -----|     |
   |              |               |                |     |     |
   |              |               |                |     |     |
   |- ACK(2) F39->|               |                |     |     |
   |              |- ACK (4) F40->|                |     |     |
   |              |               |--- ACK (4) F41------------>|


              Figure 6: Example Call Flow with announcement


                                  Figure 8














Jesske                  Expires 5 September 2024               [Page 23]

Internet-Draft     forking answer correlation in B2BUA        March 2024


   F1:  INVITE      SDP offer A1  (Codec A, Codec B)Dialog 1
   F3:  INVITE      SDP offer A2  (Codec A, Codec B)Dialog 2
   F4:  INVITE      SDP offer A2  (Codec A, Codec B)Dialog 3
   F5:  INVITE      SDP offer A2  (Codec A, Codec B)Dialog 4
   F7:  18x                 SDP answer A2 (Codec A) Dialog 2
   F8:  18x                 SDP answer A1 (Codec A) Dialog 1
   F9:  PRACK               no SDP Dialog 1
   F10: PRACK               no SDP Dialog 2
   F12: 200 OK(PRA) Dialog 2
   F13: 200 OK(PRA) Dialog 1
   F15: 18x                 SDP answer A3 (Codec B) Dialog 3
   F16: PRACK               no SDP Dialog 3
   F19: 200 OK(PRA) Dialog 3

   F21: 18x                 SDP answer A4 (Codec A,Codec B) Dialog 4
   F22: PRACK               no SDP Dialog 4
   F25: 200 OK(PRA) Dialog 4
   F27: 200 OK(INV) Dialog 4

   F28: UPDATE              SDP offer A4  (Codec A,Codec B) Dialog 1
   F29: 200 OK(UPD) SDP answer A4 (Codec A,Codec B) Dialog 1
   F30: 200 OK(INV) SDP Answer A4 (Codec A,Codec B) Dialog 1


                                  Figure 9

5.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

6.  Security Considerations

   Currently no further security considerations are needed beyond
   considerations made in the referred RFC's for SIP RFC3261 [RFC3261],
   reliability of provisional responses RFC3262 [RFC3262] and resource
   management RFC3312 [RFC3312].

7.  Acknowledgments

   The author like to thank Paul Kyzivat for his extensive review and
   comments on the first draft version.

8.  Normative References





Jesske                  Expires 5 September 2024               [Page 24]

Internet-Draft     forking answer correlation in B2BUA        March 2024


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <https://www.rfc-editor.org/info/rfc3261>.

   [RFC3262]  Rosenberg, J. and H. Schulzrinne, "Reliability of
              Provisional Responses in Session Initiation Protocol
              (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002,
              <https://www.rfc-editor.org/info/rfc3262>.

   [RFC3312]  Camarillo, G., Ed., Marshall, W., Ed., and J. Rosenberg,
              "Integration of Resource Management and Session Initiation
              Protocol (SIP)", RFC 3312, DOI 10.17487/RFC3312, October
              2002, <https://www.rfc-editor.org/info/rfc3312>.

   [RFC3326]  Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
              Header Field for the Session Initiation Protocol (SIP)",
              RFC 3326, DOI 10.17487/RFC3326, December 2002,
              <https://www.rfc-editor.org/info/rfc3326>.

   [RFC3841]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
              Preferences for the Session Initiation Protocol (SIP)",
              RFC 3841, DOI 10.17487/RFC3841, August 2004,
              <https://www.rfc-editor.org/info/rfc3841>.

   [RFC3960]  Camarillo, G. and H. Schulzrinne, "Early Media and Ringing
              Tone Generation in the Session Initiation Protocol (SIP)",
              RFC 3960, DOI 10.17487/RFC3960, December 2004,
              <https://www.rfc-editor.org/info/rfc3960>.

   [RFC5393]  Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B.
              Campen, "Addressing an Amplification Vulnerability in
              Session Initiation Protocol (SIP) Forking Proxies",
              RFC 5393, DOI 10.17487/RFC5393, December 2008,
              <https://www.rfc-editor.org/info/rfc5393>.

   [RFC6026]  Sparks, R. and T. Zourzouvillys, "Correct Transaction
              Handling for 2xx Responses to Session Initiation Protocol
              (SIP) INVITE Requests", RFC 6026, DOI 10.17487/RFC6026,
              September 2010, <https://www.rfc-editor.org/info/rfc6026>.





Jesske                  Expires 5 September 2024               [Page 25]

Internet-Draft     forking answer correlation in B2BUA        March 2024


   [RFC6141]  Camarillo, G., Ed., Holmberg, C., and Y. Gao, "Re-INVITE
              and Target-Refresh Request Handling in the Session
              Initiation Protocol (SIP)", RFC 6141,
              DOI 10.17487/RFC6141, March 2011,
              <https://www.rfc-editor.org/info/rfc6141>.

   [RFC6228]  Holmberg, C., "Session Initiation Protocol (SIP) Response
              Code for Indication of Terminated Dialog", RFC 6228,
              DOI 10.17487/RFC6228, May 2011,
              <https://www.rfc-editor.org/info/rfc6228>.

   [RFC7029]  Hartman, S., Wasserman, M., and D. Zhang, "Extensible
              Authentication Protocol (EAP) Mutual Cryptographic
              Binding", RFC 7029, DOI 10.17487/RFC7029, October 2013,
              <https://www.rfc-editor.org/info/rfc7029>.

9.  Informative References

   [TS24.229] 3GPP, "IP multimedia call control protocol based on
              Session Initiation Protocol (SIP) and Session Description
              Protocol (SDP); Stage 3", 17 March 2014.

Appendix A.  Appendix


Author's Address

   Roland Jesske
   Deutsche Telekom
   Heinrich-Hertz-Strasse 3-7
   64307 Darmstadt
   Germany
   Phone: +4961515812766
   Email: r.jesske@telekom.de

















Jesske                  Expires 5 September 2024               [Page 26]