[sr-dev] improving the dialog module

[Timo Reimann]

Iñaki Baz Castillo wrote:
> Hi, please help me with the dialog module in scenarios with spiral.
> IMHO there are two approachs for this case (dialog module working on
> P1):
> 
>   UAC ---------------> P1 -----------> P2 --------------> P1
> ----------------> UAS
> 
> 
> Approach 1)
> - When the INVITE arrives form UAC a dialog entry is generated.
> - When the INVITE does spiral and arrives to P1 from P2 a new dialog
> entry is created.
> - The difference between both entries is the caller route-set which
> would be null for the first entry and "sip:P2, sip:P1" for the second
> entry, right?

At this time of routing, wouldn't it just be the record-route set? Of
course, it'd yield a record set once signaling is complete. (Sorry if
I'm being too picky here.)

[snap]

Agreeing with the rest of the description you provided.


> So the main question is: when a spiral occurs, should it involve an
> unique dialog entry or two (different route-set)?
> 
> I don't see the benefict of creating two dialog entries. From SIP
> perspective it's still the same and unique dialog, but there is a
> possible vulnerability: Imagine the above case when UAS sends the BYE:
> - UAS sends BYE to P1.
> - P1 matches the unique dialog and marks it as terminated.
> - P1 relays the BYE to P2 following the loose routing mechanism.
> - P2 and UAS are "hackers". P2 ignores the BYE and doesn't relay it.
> - UAC never receives it but the dialog is marked as terminated.

I am not sure if this really needs to be handled. Generally, is Kamailio
designed to deal with misbehaving on-route proxies? There's probably a
whole bunch of problems one can think of if you try to break operations
intentionally.

The UAC should implement some way of detecting disconnected sessions and
act accordingly anyway, like observing the RTP stream and indicate an
error if there's no more data flowing.


Cheers,

--Timo