[asterisk-dev] dialog matching

Steve Murphy murf at digium.com
Wed Dec 19 18:06:06 CST 2007


Olle--

I thought to double check with you... the price of missing something is
pretty high.

Put on your thinking cap, pull out some paper and a pencil, turn off the
cell phone... this is going to require
some thought!


For reference, here's the search loop in find_call:


        dialoglist_lock();
        for (p = dialoglist; p; p = p->next) {
                /* In pedantic, we do not want packets with bad syntax
to be connected to a PVT */
                int found = FALSE;
                if (ast_strlen_zero(p->callid))
                        continue;
                if (req->method == SIP_REGISTER)
                        found = (!strcmp(p->callid, callid));
                else
                        found = (!strcmp(p->callid, callid) &&
                           (!pedanticsipchecking || !tag ||
ast_strlen_zero(p->theirtag) || !strcmp(p->theirtag, tag))) ;

                ast_debug(5, "= %s Their Call ID: %s Their Tag %s Our
tag: %s\n", 
                                                 found ? "Found" : "No
match", p->callid, p->theirtag, p->tag);

                /* If we get a new request within an existing to-tag -
check the to tag as well */
                if (pedanticsipchecking && found  && req->method !=
SIP_RESPONSE) {     /* SIP Request */
                        if (p->tag[0] == '\0' && totag[0]) {
                                /* We have no to tag, but they have.
Wrong dialog */
                                found = FALSE;
                        } else if (totag[0]) {                  /* Both
have tags, compare them */
                                if (strcmp(totag, p->tag)) {
                                        found = FALSE;          /* This
is not our packet */
                                }
                        }
                        if (!found)
                                ast_debug(5, "= Being pedantic: This ...
request: Call ID: %s Ourtag <null> Totag %s Method %s\n", 
                                       p->callid, totag,
sip_methods[req->method].text);
                }


                if (found) {
                        /* Found the call */
                        sip_pvt_lock(p);
                        dialoglist_unlock();
                        return p;
                }
        }
        dialoglist_unlock();

The object: remove the loop, and replace it with astobj2 hash table
lookups.

I checked Luigi's astobj2 branch, where he put dialogs in a table, but
he implements the above as a linear traversal, which is not my goal. I
want to improve performance, not just convert the code to be astobj2
based...

There seem to be two main modes: with pedanticsipchecking ON, and
pedanticsipchecking OFF.

________________________________________________________________________


Things are simple in OFF mode:

fundamentally, whether req->method is SIP_REGISTER or not, found is true
when a dialog's callid matches.
No code after setting found could disqualify this choice.


________________________________________________________________________


Things get more complex in pedanticsipchecking ON mode:

It seems split into whether req->method is SIP_REGISTER/SIP_RESPONSE  or
not:

If req->method is SIP_REGISTER:

   if match(p->callid,callid)  AND (!totag[0] ||  (p->tag[0] &&
match(p->tag,totag)) 

else 

    If req->method is SIP_RESPONSE:

            If callid matches AND ( empty(p->theirtag)  ||
match(p->theirtag,tag)) 

    else

            If callid matches AND  (!totag[0] ||  (p->tag[0] &&
match(p->tag,totag)) 
                                        AND ( empty(p->theirtag)  ||
match(p->theirtag,tag))  

(I notice in the code that there is :     ... ||  !tag  || ...   which
will never be true, and can be dropped)


________________________________________________________________________

I'm finding that coding the above via hashtable lookups to be
mind-bending. I've got ideas as how to handle it, and I'm "hashing" it
out, (pardon the really, really bad pun there).

What I'd like to do, is verify that my refactoring of the logic  above
is indeed correct, and some explanation as to how dialogs can be created
without unique callid's and when such are created, how the other fields
are affected, namely, the from/to tag/headers as they are recorded in
the dialog structures... Can you help me? I'm hoping there may be a
simplifying assumption or two that will make things easier.

Many thanks,

murf


-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20071219/cd6c5fa8/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20071219/cd6c5fa8/attachment-0001.bin 


More information about the asterisk-dev mailing list