"If regc.check_contact is disabled, and no Expires header has been found, but the server does return one single Contact header, assumes that the server is broken/unable to return the correct Contact. In this case, get the expiration from the single Contact header in the response (thanks Alan Bond)" Thanks a lot Benny for the fix ... it solve perfectly the problem I had described in the mailing list here : http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2008-April/002687.html From now, it will be possible to register, if the Server returns a bad Contact header, even if the Server returns no Expire header. Best Regards, Electrocut Benny Prijono 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/20080504/6c9fe457/attachment.html
