Thank you very much for you answer. So now, I know that this problem comes from Registrar which are not 100 % standard-compliant. I've read all the RFC yet lol. Sometimes, it's impossible to disable contact header checking ... because of the "expire value" : For example, with this message : SIP/2.0 200 OK Via: SIP/2.0/UDP 172.17.20.226:1265;rport;branch=z9hG4b... To: <sip:101 at 172.17.20.226> From: <sip:101@172.17.20.226>;tag=c8b125... Call-ID: 99ed82... CSeq: 22778 REGISTER User-Agent: NCH Swift Sound Axon 1.30 Contact: <sip:101 at 172.17.20.226:1265>;expires=300; Content-Length: 0 if I drop the Contact header checking, the ";expires=300" value won't be taken into account. End because there is no "Expires=300" information, in this 200/OK SIP reply ... pjsip won't be able find the read the expire value in this message, and also consider the registration as a "successful unregister". So, if one Registrar server decides to modify the Contact header, sometimes disabling "contact header checking" can help, sometimes it will just replace one problem with another ;-) Thanks, Electrocut Benny Prijono wrote: > Sorry for the late reply. The main problem was the registrars modify > the Contact header in the response, which is strictly prohibited by > the standard. We have discussion on this list before about using > fix_nated_register() vs fix_nated_contact() in (Open)SER. > > Having said that, disabling contact header checking should work for > this scenario. I'll check why it doesn't work when I get back. > > Thanks > Benny > > On Sat, Apr 19, 2008 at 8:43 AM, Tanguy Floc'h <electrocut at gmail.com> wrote: > >> I again ! >> >> Apparently, I must be missing something, when I try to uses STUN, or to >> setup my public IP myself (2 NATs traversal solutions) >> >> To make a simple test, I launch pjsua with theses parameters : >> --local-port=5070 --ip-addr=89.226.*.*--id=sip:mylogin at kiwak.net >> --registrar=sip:kiwak.net --realm=* --username=mylogin --password=secret >> >> The Registrar reply : >> Don't contain my contact header, as I sent it in my REGISTER request, so, at >> the end, the result will me considered will be considered as a successful >> Unregister ... >> Disable "contact header checking", is not a solution. >> >> (SIP messages at the end of my post) >> >> Its is really problematic, because if you keep on trying, you will indead >> Register many times : >> - My the provider believes I have registered many times. >> - Pjsua thinks it is only several "Successful Unregister". >> >> I'm being a classic "NAT" router, and I've tried with several providers, >> with the same issue : >> ippi.fr >> kiwak.net >> sip.voipbuster.com >> sip.blueface.ie >> >> (Everything is working fine when I use neither STUN nor manual Public IP >> address.) >> >> So, What's wrong with me, when I use pjsua ? I guess I AM the problem ... >> because I hope somebody has already succefully use pjsua with the --ip-addr >> or --stun-srv parameters lol ;-) >> >> >> Regards >> >> Electrocut >> >> // the SIP messages : (I've only masked public IP when I pasted on the >> mailing list) >> >> Note : I notice that the REGISTER messages are sent with rport mode ... >> Maybe I shouldn't use rport mode, if I want to choose my incoming UDP ports >> myself, right ? >> >> 1/4 >> >> REGISTER sip:kiwak.net SIP/2.0 >> Via: SIP/2.0/UDP >> 89.226.*.*:5070;rport;branch=z9hG4bKPj0af90b641ae54c1e97f4f6 >> 3e37ff7e70 >> Max-Forwards: 70 >> From: <sip:mylogin@xxxxxxxxx>;tag=f2ccdb6be99441f98074790dfaa777a6 >> To: <sip:mylogin at kiwak.net> >> Call-ID: afa938e26bb94beb9681ef80641c947d >> CSeq: 38762 REGISTER >> >> User-Agent: PJSUA v0.8.0-trunk/win32 >> Contact: <sip:mylogin at 89.226.*.*:5070> >> Expires: 300 >> Content-Length: 0 >> >> >>>>> 14:12:53.265 pjsua_acc.c Registration sent >>>>> >> 2/4 >> >> SIP/2.0 401 Unauthorized >> Via: SIP/2.0/UDP >> 10.10.10.5:5070;branch=z9hG4bKPj0af90b641ae54c1e97f4f63e37ff7e7 >> 0;received=89.226.*.*;rport=5070 >> From: <sip:mylogin@xxxxxxxxx>;tag=f2ccdb6be99441f98074790dfaa777a6 >> To: <sip:mylogin at kiwak.net>;tag=as2b21f2a1 >> Call-ID: afa938e26bb94beb9681ef80641c947d >> CSeq: 38762 REGISTER >> User-Agent: Asterisk PBX >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY >> Supported: replaces >> WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="57c1e908" >> Content-Length: 0 >> >> 3/4 >> >> REGISTER sip:kiwak.net SIP/2.0 >> Via: SIP/2.0/UDP >> 89.226.*.*:5070;rport;branch=z9hG4bKPjaaefbed1996a4b128c5fe9 >> 9548d05ff4 >> Max-Forwards: 70 >> From: <sip:mylogin@xxxxxxxxx>;tag=f2ccdb6be99441f98074790dfaa777a6 >> To: <sip:mylogin at kiwak.net> >> Call-ID: afa938e26bb94beb9681ef80641c947d >> CSeq: 38763 REGISTER >> >> User-Agent: PJSUA v0.8.0-trunk/win32 >> Contact: <sip:mylogin at 89.226.*.*:5070> >> Expires: 300 >> Authorization: Digest username="mylogin", realm="asterisk", >> nonce="57c1e908", >> uri="sip:kiwak.net", response="2ec7e9176877369c5f0bcc3c51856747", >> algorithm=MD5 >> >> Content-Length: 0 >> >> 4/4 >> >> >> SIP/2.0 200 OK >> Via: SIP/2.0/UDP >> 10.10.10.5:5070;branch=z9hG4bKPjaaefbed1996a4b128c5fe99548d05ff >> 4;received=89.226.*.*;rport=5070 >> From: <sip:mylogin@xxxxxxxxx>;tag=f2ccdb6be99441f98074790dfaa777a6 >> To: <sip:mylogin at kiwak.net>;tag=as2b21f2a1 >> Call-ID: afa938e26bb94beb9681ef80641c947d >> CSeq: 38763 REGISTER >> User-Agent: Asterisk PBX >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY >> Supported: replaces >> Expires: 300 >> Contact: <sip:mylogin at 10.10.10.5:5070>;expires=300 >> Date: Sat, 19 Apr 2008 12:12:57 GMT >> Content-Length: 0 >> >> >> >>> 14:12:53.437 pjsua_acc.c sip:mylogin at kiwak.net: unregistration >> success >> >> >> >> >> On Thu, Apr 17, 2008 at 10:26 AM, Tanguy Floc'h <electrocut at gmail.com> >> wrote: >> >> >> >>> Hi ! >>> >>> I think there is a problem, when pjsip tries to get the Expire value, from >>> >> the 200 OK >> >>> Reply coming from a REGISTER Request. >>> >>> The problem is for SIP messages like these, when "Expires" value had not >>> >> its own header field : >> >>> SIP/2.0 200 OK >>> Via: SIP/2.0/UDP 172.17.20.226:1265;rport;branch=z9hG4b... >>> To: <sip:101 at 172.17.20.226> >>> From: <sip:101@172.17.20.226>;tag=c8b125... >>> Call-ID: 99ed82... >>> CSeq: 22778 REGISTER >>> User-Agent: NCH Swift Sound Axon 1.30 >>> Contact: <sip:101 at 172.17.20.226:1265>;expires=300; >>> Content-Length: 0 >>> >>> As you can see, expires value has not its own header field (like "Expires: >>> >> 300"), but is put at the end of the "Contact" header field (.. ; >> expires=300;) >> >>> That's what happen in this case : >>> >>> When receiving the 200 OK Reply, from the REGISTER Request, the function >>> >> tsx_callback() in sig_reg.c tries to find the "Expires= ?" header field : >> >>> (line 718) >>> expires = (pjsip_expires_hdr*)pjsip_msg_find_hdr(msg, PJSIP_H_EXPIRES, >>> >> NULL); >> >>> but can't find this field in the SIP message. >>> >>> If PJSIP_REGISTER_CLIENT_CHECK_CONTACT Param is set to 1, it is not a >>> >> problem if expire field can not be found in SIP 200/Ok Reply, because the >> previous (and lower) value >> >>> (from the REGISTER Request) will be taken into account instead : >>> >>> (line 760) >>> if (contact[i]->expires >= 0 && contact[i]->expires < expiration) >>> expiration = contact[i]->expires; >>> >>> But if PJSIP_REGISTER_CLIENT_CHECK_CONTACT Param is set to 0 (that's my >>> >> case), expiration value is set to -1, just before the callback is called, >> line 810 in sig_reg.c >> >>> Consequently, when the callback function regc_cb in pjsua_acc.c test the >>> >> expiration value, it believes that it is a "succefful UNregistration", >> instead of Registration (because expiration < 1) >> >>> A way to fix the problem could be : >>> - To read expires value in "pjsip_contact_hdr->expires", if >>> >> "pjsip_contact_hdr->ivalue" doesn't exist >> >>> or >>> - to compare the Expiration value, even if >>> >> PJSIP_REGISTER_CLIENT_CHECK_CONTACT is disable, so the previous value will >> be taken into account instead. >> >>> Thanks ! >>> >>> Electrocut >>> >>> >> _______________________________________________ >> 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/20080420/87722a01/attachment.html
