16 Mar
2010
16 Mar
'10
4:06 p.m.
2010/3/16 Timo Reimann <timo.reimann(a)1und1.de>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(a)aliax.net>