[sr-dev] improving the dialog module

[Iñaki Baz Castillo]

2010/3/16 Timo Reimann <timo.reimann at 1und1.de>:

> Interesting idea. Let me ask two questions:
>
> (1) I re-checked when dialog state is modified exactly for responses
> (and believe I have to doubt what I initially claimed to be true):
>
> So, taking into account that (serial
> and parallel) forking proxies will *forward* responses only when all
> forking attempts have finally failed or one succeeded,

Early dialogs are created when a provisional response with a different
To-tag arrives, and of course all the provisional responses (different
early-dialogs) are relayed by the proxy to the UAC.


> wouldn't that
> automatically implement your "dialog-outs will properly adjust
> dialog-in's state" approach and render dialog-outs unnecessary? Or am I
> wrong on the assumption how forking works?

Not sure, but I think you miss the case in which parallel forking (or
serial forking) is performed by a proxy (P2) behind kamailio (P1):

  UAC ------------ P1 -------------- P2 ---------------UAS1,UAS2,UAS3
(different To-tags)

In this case, for each early-dialog (different To-tag) P1 will receive
such response within the same outgoing transaction (P1 just created a
single outgoing transaction to relay the INVITE to P2).

Theorically onlye the UAC cares about dialogs, and not a proxy. If a
proxy must be aware of dialogs (dialog module) it should handle all
the early-dialogs, and it doesn't matter if different early-dialogs
have been originated due to forking in local proxy or in a proxy in
the path (after the local proxy).

I'm not sure, however, if this replies your question. If not please
explain it to me again.



> (2) How would your approach deal with unconfirmed requests traversing
> the same proxy multiple times, i.e., what has been denoted as
> "spiraling" in this thread, as in this example:
>
> UA1 --> P1 --> P2 --> P1 --> UA2
>
> Will that result in the creation of two dialog(-in)s?

As the INVITE from P2 to P1 is a different transaction, it should
create a new dialog-in entry. In order to distinguish which INVITE
transaction each response belongs to, the dialog module should also
store the INVITE branch (in both the dialog-in entry and dialog-out
entry/entries pointing to the dialog-in entry).

Unfortunatelly in order to match in-dialog requests (as ACK,
re-INVITE, UPDATe, BYE...) with the proper dialog-in entry, it would
also be needed to store route-set information for each dialog-in
entry.

This is, in you example if UA1 sends an in-dialog re-INVITE, the only
difference between INVITE from UA1 to P1 and the INVITE from P2 to P1
would be the route set.


Other approach would be avoiding creating two dialog-in entries for
such spiral case. This is, when the INVITE arrives from P2 to P1, P1
would create a new dialog-in entry as there is already a dialog-in
entry with same Call-ID and From-tag.

Not sure which approach is better, perhaps the second one (from SIP
point of view, the spiral is still a single dialog!).


-- 
Iñaki Baz Castillo
<ibc at aliax.net>