Sorry for the bad ascii table :( the same in an image : http://www.monsterup.com/image.php?url=upload/1210003361.jpg On Mon, May 5, 2008 at 6:00 PM, Tanguy Floc'h <electrocut at gmail.com> wrote: > I agree with you Alan, I had the same problem a few minutes ago : > with "pjsip_cfg()->regc.check_contact" disabled, it will fail anyway with > a "unregister success", if more than once user have registered to the > account. (if we assume 'Contact: header' is missing) > > Another problem with the fix you proposed : > > if (expiration == NOEXP) > expiration = -1; > else if (expiration == 0 && contact_cnt > 0 && contact[0]->expires > 0) > expiration = contact[0]->expires; > > > is that you don't know if 'contact[0]->expires' is your expire value ... > or if it is 'contact[1]->expires' > > > If 'contact[0]->expires' is taken as the "good expire value", only if the > "Contact header recognation" (like when "check_contact" is enabled) has > failed ... if could solve a part of the problem, but not all. > > If my assumption is right (I haven't tested it) finally, it should be : > > > -------------------+-----------------------+-------------------------------------------+ > | only | only > | | > | No Expire header | bad Contact Info | No > Expire header + Wrong Contact Info | > > ------------------|------------------+-----------------------+-------------------------------------------| > 1st fix | | > | > | > (contact_cnt = 0) | ok if register<2 | ok | > ok if register<2 | > | | > | | > ------------------+------------------+-----------------------+-------------------------------------------+ > > 2nd fix | ok | > | ok > | > (contact_cnt > 0) | but multi-unreg | ok | > but multi-unreg problem | > | problem | > | | > > ------------------+------------------+-----------------------+-------------------------------------------+ > 2nd fix + | | > | | > + the idea above | | > | ok | > (test contact | ok | ok | > but multi-unreg problem | | > header recogn. 1st| | > | | > ------------------+------------------+-----------------------+-------------------------------------------+ > > > > I hope we will managed to find the best solution for this issue :) > > Regards, > > Electrocut > > > On Sun, May 4, 2008 at 2:06 PM, Benny Prijono <bennylp at pjsip.org> wrote: > > > Hi Alan, > > > > First of all, I think this issue has come up several times on this > > list, so I've just added this entry in the FAQ to explain the > > rationale why PJSIP behaves this way, and also few solutions to cope > > with it: http://trac.pjsip.org/repos/wiki/FAQ#regc > > > > I do like your solution. And while this is server problem (regardless > > of how popular it is; if it's broken, then it needs to be fixed, IMO), > > in the SVN trunk we already have couple of settings to deal with this, > > so if we want to handle this, why not go all the way. So I've just > > added the trick (to get the expiration value from the single Contact, > > if Expires header is not present) in the latest SVN version. Thanks > > for the suggestion. > > > > Now enjoy the bank holiday. :) > > > > Cheers > > Benny > > > > On Sun, May 4, 2008 at 2:38 AM, Alan J. Bond <alan.bond at wintology.com> > > wrote: > > > > > > > > > > > > > > > Hi again, > > > > > > > > > > > > Have done the debugging. Here is the fix but remember I'm very new to > > this > > > code so please scrutinise carefully. Comments for clarity only, > > please > > > amend per your normal standards. > > > > > > > > > > > > The value of expires= on the end of a Contact: header is indeed parsed > > > correctly and placed in the pjsip_contact_hdr structure. The problem > > is in > > > sip_reg.c toward the end of this function where it is discarded and > > not > > > passed to the callback handler. This change assumes that any SIP > > servers > > > that exhibit this behaviour are only going to do so when returning a > > single > > > Contact: header. You may know different. > > > > > > > > > > > > static void tsx_callback(void *token, pjsip_event *event) > > > > > > { > > > > > > : > > > > > > : > > > > > > : > > > > > > V > > > > > > > > > > > > } > > > > > > > > > > > > /* Increment busy flag temporarily to prevent regc from > > > > > > * being destroyed. > > > > > > */ > > > > > > ++regc->busy; > > > > > > > > > > > > /* Call callback. */ > > > > > > > > > > > > /* Change to cope with old SER implementations that append */ > > > > > > /* expires= to Contact: and do not create Expires: header */ > > > > > > /* 20080504 BEGIN -----------------------------------------*/ > > > > > > > > > > > > /* if (expiration == NOEXP) expiration = -1; */ > > > > > > > > > > > > if (expiration == NOEXP) > > > > > > expiration = -1; > > > > > > else if (expiration == 0 && contact_cnt == 1 && > > contact[0]->expires > > > > 0) > > > > > > expiration = contact[0]->expires; > > > > > > > > > > > > /* 20080504 END -------------------------------------------*/ > > > > > > > > > > > > call_callback(regc, PJ_SUCCESS, tsx->status_code, > > > > > > (rdata ? &rdata->msg_info.msg->line.status.reason > > > > > > : pjsip_get_status_text(tsx->status_code)), > > > > > > rdata, expiration, > > > > > > contact_cnt, contact); > > > > > > > > > > > > /* Decrement busy flag */ > > > > > > --regc->busy; > > > > > > } > > > > > > > > > > > > /* Delete the record if user destroy regc during the callback. */ > > > > > > if (regc->_delete_flag && regc->busy==0) { > > > > > > pjsip_regc_destroy(regc); > > > > > > } > > > > > > } > > > > > > > > > > > > Please let me know if you think this will screw up other > > implementations. > > > > > > > > > > > > Best Regards, > > > > > > Alan. > > > _______________________________________________ > > > Visit our blog: http://blog.pjsip.org > > > > > > pjsip mailing list > > > pjsip at lists.pjsip.org > > > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > > > > > > > _______________________________________________ > > Visit our blog: http://blog.pjsip.org > > > > pjsip mailing list > > pjsip at lists.pjsip.org > > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080505/88dbb48c/attachment-0001.html
