[Users] nathelper natping OPTIONS packets formated to not get reply?

[Bogdan-Andrei Iancu]

Hi Glen,

thanks for the update - I guess we can leave it like this as the main 
purpose is achieved - to make the client to sent a response back (the 
reply code is totally irrelevant).

regards,
bogdan

Glenn Dalgliesh wrote:

>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:bogdan at voice-system.ro] 
>Sent: Friday, February 17, 2006 11:19 AM
>To: Glenn Dalgliesh
>Cc: users at 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.
>>
>> 
>>
>>    
>>
>
>  
>