Electrocut, I think perhaps you have not noticed the complete replacement sip_reg.c attached to my post. Changing the contact_cnt == 0 to > 0 was just to poke it about some. I've taken all that code out and replaced it with a latency adjusted client-side timer based solution for the very reason you've pointed out below. These changes are much more violent I'm afraid, but from my testing it seems to work fine with multiple clients.. Give that a go and let me know how you get on. Be aware that I started with 0.8.0 release code, not the SVN stuff so be careful not to leap-frog other changes. I think the only situation where this wouldn't work is if the server tried to force the client to register more often than it requested, but that would be easily sorted by changing the expire time at the client. I've never seen a SIP server do that but I'm sure there'll be one out there somewhere :-). Alan. From: pjsip-bounces@xxxxxxxxxxxxxxx [mailto:pjsip-bounces at lists.pjsip.org] On Behalf Of Tanguy Floc'h Sent: 05 May 2008 17:00 To: pjsip list Subject: Re: Parsing expires from REGISTER reply 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<mailto: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<mailto: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<mailto: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<mailto: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/5bfd21b6/attachment-0001.html
