On Wed, Aug 24, 2011 at 2:45 PM, Timo Reimann <timo.reimann@1und1.de> wrote:

Hey,

On 24.08.2011 13:38, marius zbihlei wrote:
> On 08/24/2011 02:32 PM, Jason Penton wrote:
>> Hi Guys,
>>
>> Have been playing around with the dialog module and spiralling and one
>> thing I have noticed is that if you spiral and dont have
>> detect_spirals enabled the dialog module will create 2 dialogs. This
>> is great and 'expected' in this case. However, as it stands there is
>> no way of distinguishing between the 2 dialogs. So for example, a BYE
>> could come in from either 'side' of the spiral and the first dialog is
>> matched - not necessarily the correct one. this is because the match
>> is purely done on callid, from and to tags (if using RFC3261 matching).

And for the record: It doesn't help if you switch to cookie-based
matching (dlg_match_mode 0 or 1). Since cookies are implemented as
hashed Call-IDs, two different dialogs spawn from a spiral situation
still map to the same entry in the hash table.

yes, sure

>> My initial thought is to have some sort of direction identifiers
>> stored in the dialog structure itself. Then using Via and contact
>> headers we can make a pretty good assumption as to which 'end' of the
>> spiral and therefore choose the correct dialog in the match algorithm.

I am not quite sure if I understand how the "ends" of a spiral and the
available dialog structures in the hash table relate to each other. From
a technical perspective, the result of an (undetected) spiraled call is
just a second transaction on the same proxy mapping to the same call. No
matter whether a request arrives from one end (caller) or the other
(callee), the message will transition both transactions and thus relate
to the same dialog. AFAICS, that's no different to a non-spiraled call.

Let me give you a scenario that may help this picture. Once again, IMS related ;)

In IMS we have different proxies (called CSCFs - Call Session Control Functions). These can behave in 'terminating' or 'originating' mode. So for an example call between users on the same IMS network, it would look something like this:

UA1 <=a=> PCSCF(Orig) <=b=> SCSCF(Orig) <=c=> SCSCF(Term) <=d=> PCSCF(Term) <=e=> UA1

So for an invite from UA1 to UA2 the INVITE will appear twice at the same PCSCF (assuming there is only one PCSCF in this case). This will result in spiraling on Kamailio right now, BUT there is no way to distinguish between the 'originating' dialog and the 'terminating' dialog. why is this a problem? well it would be nice to know in the config file in which mode you are in. I am sure there will be non ims related scenarios but I can think of any ;)

If what you're interested in is simply the direction the request came
from you may evaluate the "dir" variable programmatically which is
passed as part of each dialog callback parameter structure.

Because this wont be available in the config file AND the wrong dlg will be matched already at this point

>> some may say just enable spiral_detection. Actually, in some cases it
>> is nice to be able to track a spiral in different dialogs, which most
>> likely why the option to enable or disable spiral detection in the
>> first place

In order to get a better feel for what you wish to accomplish, could you
give an example of such a case?

Cheers,

--Timo

_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev