> <mailto:
timo.reimann@1und1.de>> wrote:
>
> >> 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 ;)