[SR-Users] Handling RFC3578 (Overlap Dialing) in Kamailio/ Asynchronious transaction handling

[Olle E. Johansson]

On 04 Feb 2014, at 18:58, Alex Balashov <abalashov at evaristesys.com> wrote:

> On 02/04/2014 12:54 PM, Olle E. Johansson wrote:
> 
>> And you assume a lot of things - that your invites are sent to the same
>> server, which may not be the case. DNS lookups and load balancing/failover
>> is done on a per transaction basis.
> 
> In fairness, RFC 3578 does offer a fair bit of commentary on this caveat:
> 
>   However, having subsequent INVITEs routed in different ways brings
>   some problems as well.  The first INVITE, for instance, might be
>   routed to a particular gateway, and a subsequent INVITE, to another.
>   The result is that both gateways generate an IAM.  Since one of the
>   IAMs (or both) has an incomplete number, it would fail, having
>   already consumed PSTN resources.
> 
>   [...]
> 
>   Routing in SIP can be controlled by the administrator of the network.
>   Therefore, a gateway can be configured to generate SIP overlap
>   signalling in the way described below only if the SIP routing
>   infrastructure ensures that INVITEs will only reach one gateway.
>   When the routing infrastructure is not under the control of the
>   administrator of the gateway, the procedures of Section 2 have to be
>   used instead.
> 
> And, while I agree that this is ridiculous and is in conflict with the basic spirit of SIP, somehow 3578 did become an RFC... I am as puzzled by that as you may be.  :-)

That's applying a strict route. IMS has some similar overrides too... Ouch.

Regardless, it doesn't talk about overlapping INVITE transactions, just a series
of INVITE transactions.

/O