[sr-dev] improving the dialog module

[Klaus Darilion]

Am 17.03.2010 19:34, schrieb Iñaki Baz Castillo:
> 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

Dialog creation in dialog module is based on tm's transactions. Thus I 
guess a second dialog is created. Interesting would be how the in-dialog 
requests are mapped to the dialog - here a RR-cookie would be needed to 
find the proper dialog structure.

regards
klaus

>
> 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?
>
>
> Approach 2)
> - 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 NOT created as there is already an entry with same callid and
> fromtag (even if the caller route-set is different).
>
>
>
> *** Now imagine UAS replies 200 and the response arrives from UAS to P1:
>
> In the first approach TM would invoke the callback for the second
> dialog entry (OK).
>
> In the second approach TM would invoke NO callback as no dialog entry
> was generated for this INVITE transaction (OK).
>
>   so it changes its state.
> *** Now the 200 does the spiral through P2 and arrives again to P1:
>
> In the first approach TM would invoke the callback for the first
> dialog entry (OK).
>
> In the second approach TM would invoke the callback for the first (an
> unique) dialog entry (OK).
>
>
> *** Now UAC sends a re-INVITE and arrives to P1:
>
> In the first approach the dialog module tries to match the dialog and
> finds two entries with same callid and fromtag (opsss), which one to
> choose? the ONLY solution is matching the request route-set which is
> difficult as involves SIP URI comparisons (not just a string match).
> PROBLEM: what to do here?
>
> In the second approach the dialog module tries to match the dialog and
> finds the unique entry with same callid and fromtag.
>
>
> *** Now UAS sends BYE and arrives to P1:
>
> In the first approach same as above occurs, in order to determine
> which dialog entry to update it's required to inspect and match the
> request route-set (ugly!).
>
> In the second approach the unique dialog entry would be matched.
>
>
>
>
>
> 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.
>
>
> Opinions? Thanks.
>
>
>
>
>
>
>
>