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.