17 Feb
2006
17 Feb
'06
6:02 p.m.
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.
17 Feb
17 Feb
6:19 p.m.
New subject: [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.
25 Feb
25 Feb
7:33 p.m.
New subject: [Users] nathelper natping OPTIONS packets formated to not get reply?
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@voice-system.ro]
Sent: Friday, February 17, 2006 11:19 AM
To: Glenn Dalgliesh
Cc: users(a)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.
27 Feb
27 Feb
10:24 a.m.
New subject: [Users] nathelper natping OPTIONS packets formated to not get reply?
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@voice-system.ro]
Sent: Friday, February 17, 2006 11:19 AM
To: Glenn Dalgliesh
Cc: users(a)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.
6843
days inactive
6853
days old
3 comments
2 participants
participants (2)
-
Bogdan-Andrei Iancu -
Glenn Dalgliesh