Ok, I tested with standard natping with the received field with the default format of sip:<ip address>:<port> and allow though some clients respond differently to OPTIONS packet without username, in all cases I tested they did respond.
Unless you have other info I think we can leave this as is... Thanks for the help User_Agent No Username With Username =============== ======================= =================== InstantVoice Not Found OK eyeBeam 3004t OK OK X-Lite release 1103m OK OK 20a/050106 OK OK Asterisk PBX OK OK Axon 1.06 Not Implemented Not Implemented Cisco ATA 186 v3.1.0 Not Found OK Cisco ATA 186 v3.2.0 Not Found OK FXS_GW (1asipfxs.107b) OK OK FXSO_GW OK OK Grandstream BT100 1.0.6.7 OK OK Grandstream HT386 1.0.2.2 OK OK Grandstream HT487 1.0.5.16 OK OK Grandstream HT487 1.0.5.18 OK OK Grandstream HT487 1.0.6.7 OK OK Grandstream HT496 1.0.0.8 OK OK Grandstream HT496 1.0.2.16 OK & No Such Call OK & No Such Call Linksys/PAP2-2.0.10(LSc) Not Found OK Linksys/PAP2-2.0.12(LS) Not Found OK Linksys/PAP2-3.1.3(LS) Not Found OK Sipura/SPA2000-2.0.13(g) Not Found OK Sipura/SPA2002-3.1.2(a) Not Found OK Sipura/SPA2000-3.1.5 Not Found OK SJphone/1.50.271d (SJ Labs) Method Not Allowed OK SJphone/1.60.289a (SJ Labs) Method Not Allowed OK Welltech SipPhone V3.0 OK OK Welltech SipPhone V5809 OK OK -----Original Message----- From: Bogdan-Andrei Iancu [mailto:[EMAIL PROTECTED] Sent: Friday, February 17, 2006 11:19 AM To: Glenn Dalgliesh Cc: users@openser.org Subject: Re: [Users] nathelper natping OPTIONS packets formated to not get reply? Hi Glenn, no problem :) just keep me up to date if indeed the lack/presence of username in the TO hdr makes any difference. As we are close to make a new release on 1.0.x branch, it will be a nice fix to have . regards, bogdan Glenn Dalgliesh wrote: >Well I am feeling a little embarrassed at this point but it seems that my >data may not have been exactly correct with regard to natpings not working >without username in the TO field of OPTIONS packets. > >First my original test scenario was to ngrep for OPTIONS packets generated >from OpenSer and see if I was getting response without Username in the TO >field. Then I would send an OPTIONS using sipsak thru openser and see if I >got a reply. Based on this test it appeared that it was the lack of Username >in the TO field. But then after recording results with my work round in >place which rewrote the received field. I found that I was still not getting >consistent results on replies to OPTIONS packets this lead me to start >looking to see if the OPTIONS packets where ever reaching the dest... >It turns out that the OPTIONS packets were not reaching the dest and it >seems that the reason was that the Cisco router btw OPENSER and the Internet >was dropping a very high percentage of out bound packets under bursty >situations such as hundreds of OPTIONS packets being sent to it at once. I >have resolved this issues and now I am getting consistant results from the >natping OPTIONS packets. > >I will follow up with one more test which is to remove my work around >related to the received field and retest the results. However, I will have >to wait until I can test this after hours inorder to make this change. > >Thanks and sorry for the bad data but as you can see it wasn't do to lack of >thought :) > > >FYI: your patch did seem to added the natping FROM field to the TO field >after I retest we can figure out if that is really necessary. > > > _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
