Subject: Re: [dispatch] Draft minutes from IETF 91- Issue "forking correlation"

From: <[email-masked]>
Date: Tue, 6 Jan 2015 09:14:33 +0100

Hi,
thank you for the minutes.

I would like to start the discussion on the issues and would like to dig al little bit more for the reasoning.

Due to discussions since the last meeting I had with a couple of peoples and also new use cases appearing it showed that the shown use cases does not only solve miss-behavior of UA's (or Gateways) not understanding forking, i.e. multiples responses received due to forking.

We have also service behavior where a B2BUA has to correlate multiples responses received due to forked INVITES and other scenarios like call forwarding.

So I would like to discuss the problem statement and what is needed to satisfy the people to accept the work on this issue within IETF.

So below I have rewritten the problem statement. I would like to know if people would be willing to work on this issue based on this statement. Or is there still something missing?

So I start with the evaluation part where I look in all the RFCs discussing forking, multiples early dialogs/session and the related use cases.

Here is a new proposal for the problem statement:

1.  Problem Statement

Within 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 RFC 5359  [RFC 5359  ] 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:
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:
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 RFC 3261 [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.

Thank you and Best regards

Roland

-----Ursprüngliche Nachricht-----
Von: dispatch [mailto:[email-masked]] Im Auftrag von Cullen Jennings (fluffy)
Gesendet: Freitag, 19. Dezember 2014 21:59
An: IETF Dispatch
Betreff: [dispatch] Draft minutes from IETF 91

Can be found at 

http://www.ietf.org/proceedings/91/minutes/minutes-91-dispatch

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Anton Tveretin" <[email-masked]>
Date: Sun, 11 Jan 2015 23:17:02 +0500

Dear All,
This seems to be related to the problem of semantics.
Tradidtionally, IETF defines syntax of protocols, but not semantics. However, sometimes this 
position hinders interoperability (what we see here).
To add to all my previous posts: what about From-URI in conference invitations? Should it be 
conference-URI or inviting party's AoR? Convenor, focus?