[sr-dev] Proposal: New Dialog Module Design

[Iñaki Baz Castillo]

2010/3/20 Timo Reimann <Timo.Reimann at 1und1.de>:
> Two remarks:
>
> (1) Under "dialog_out table", the following is stated:
>
> "A response arrives to the proxy and TM modules invokes the Dialog module
> callback for the previously generated dialog.
>
> *Such callback ignores the response if its Call-ID or From-tag doesn't match
> the entry in dialog_in table with same hash_id*[...]"
>
> I do not think the module has to check whether the response's Call-ID and
> From-tag match the entry in the dialog_in table because a mismatch should
> never happen: When the tm callback to dlg_reply() was registered in
> dlg_onreq(), the hash ID of the very dialog created during dlg_onreq() was
> passed as argument to tm's registration function. And since the tm module
> makes sure that you cannot receive a response-based callback for a different
> transaction than the one the registration was carried out from, the dialog
> that the response-triggered callback will point to must be the right one.

At transaction layer just the branch and CSeq is inspected in order to
match response with its corresponding client transaction. So the
following could occur (due to a spoofed reply):

### Request sent from proxy to Bob:
INVITE sip:bob at example.org SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4;branch=aaaaaaaa
From: sip:alice at example.org;tag=1111
Call-ID: 11111111
CSeq: 1 INVITE

### Spoofed response frmo Bob (matches the transaction but not the dialog):
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 1.2.3.4;branch=aaaaaaaa
From: sip:alice at example.org;tag=2222
Call-ID: 22222222
CSeq: 1 INVITE


So in this case, the fact that TM matches the response against an
existing client transaction doesn't mean that the response is valid
according to dialog rules so such values (From tag and Call-ID) should
be matched by the Dialog module.

Do you agree? or do I miss something yet?




> (2) The "Spiral" example only shows one possible implementation with two
> dialog states created for an effectively single dialog. However, during the
> thread on the mailing list that started off the re-design proposal, we
> discussed another approach where a single dialog state is maintained for
> spirals only (denoted "dialog continuation" by myself).
>
> Is there a reason why this approach isn't taken into consideration on the
> wiki page? If it's just a matter of time and effort, I'd be glad to add some
> text and another example in order to let people comment on this further.
> Like I said before, I really consider having dialog callback users deal with
> module deficits the worse choice if a better option is available.

It's just a proposal, of course comments and suggestions are more than
welcome :)

Could you please point me to your suggestion about "dialog continuation"?
However, if we want a new spiral not no create a new dialog then it
would be easily feasible just by adding a constrain when creating a
dialog upon receipt of an INVITE:

"If there is already an entry in dialog_in table with same From-tag
and Call-ID then the new INVITE is part of a spiral and no new dialog
is created for it".

Would it make sense? Certainly I'm thinking it would be just better.


Regards.




-- 
Iñaki Baz Castillo
<ibc at aliax.net>