20 Mar
2010
20 Mar
'10
3 a.m.
2010/3/20 Timo Reimann <Timo.Reimann(a)1und1.de>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@example.org SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4;branch=aaaaaaaa
From: sip:alice@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@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(a)aliax.net>