[Users] nathelper natping OPTIONS packets formated to not get reply?
Glenn Dalgliesh
glenn at routerboy.com
Fri Feb 10 18:10:51 CET 2006
**Answer inline in messages
Hi Glen,
good job with the testing!! thanks a lot.
first, just to be sure, the missing username is in the TO hdr as
originally posted, right?
**Yes, you are correct I used the fU address and it should be the tU
the idea is to find a compromised between how correct the OPTIONS should
be build and how efficient (in terms of speed and complexity).
In order to set the right username I will need to also get from the
usrloc the AOR of the user. this involves changes and penalties in the
usrloc interaction, thinks I'm trying to avoid.
**I not totally clear about the above. I think your are saying is that
rather than changing the info in the received field to contain
"sip:$tU@$si:$sp" that natping would have to build the proper uri from the
info in locations table during each transaction and this would create a very
large performance hit.
do you think that placing a static dummy username (if missing) into the
TO will fix the problem?
**Well I am not sure. Is it possible to have a Registration packet without a
username in the To field?
regards,
bogdan
Glenn Dalgliesh wrote:
>Well sorry for the deal between post but wanted to find the time to run
some
>tests. Below is a table showing results of some tests I did related to
which
>clients response to options packets with and without username.
>Overwhelmingly, UA's don't seem to respond to OPTIONS packets without
>username. I have implemented a work around using AVP which is also below
but
>I thought you might want to see this based on my findings.
>
>
>User_Agent No Username With Username
>====================================================================
>InstantVoice No Response OK
>HT488 1.0.2.5 OK OK
>Eyebeam 3004t No Response OK
>X-Lite release 1103m No Response OK
>X-Lite release 1105d No Response OK
>20a/050106 No Response OK
>Asterisk PBX OK OK
>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 No Response OK
>Grandstream BT100 1.0.6.7 OK OK
>Grandstream HT487 1.0.5.16 OK OK
>Grandstream HT487 1.0.5.18 No Response OK
>Grandstream HT487 1.0.6.7 No Response OK
>Grandstream HT488 1.0.2.16 No Response Not Implemented
>Grandstream HT496 1.0.0.8 No Response OK
>Grandstream HT496 1.0.2.16 No Response OK & No Such Call
>Linksys/PAP2-3.1.3(LS) No Response OK
>SIP201 (lp201sip.101) OK OK
>Sipura/SPA2000-2.0.13(g) Not Found OK
>Sipura/SPA2002-3.1.2(a) Not Found OK
>SJphone/1.50.271d (SJ Labs) No Response Method Not Allowed
>SJphone/1.60.289a (SJ Labs) No Response Method Not Allowed
>Welltech SipPhone V3.0 No Response OK
>Welltech SipPhone V5809 No Response OK
>
>
>I do the following before I save location to all registration packets. In
>order to add username to the received field.
>avp_subst("i:42","/(sip:)(.*)$/\1$fU@\2/");
>
>-----Original Message-----
>From: Bogdan-Andrei Iancu [mailto:bogdan at voice-system.ro]
>Sent: Monday, January 23, 2006 7:00 AM
>To: Glenn Dalgliesh
>Cc: users at openser.org
>Subject: Re: [Users] nathelper natping OPTIONS packets formated to not get
>reply?
>
>Hi,
>
>indeed, if received uri is set, usrloc returns it received as contact
>uri. Again, that's so due simplicity reasons.
>On the other hand, an uri without username is a compliant SIP URI
>(according to RFC).
>I see no reasons for the TO to be rejected in this format.
>
>Regards,
>Bogdan
>
>
>Glenn Dalgliesh wrote:
>
>
>
>>Well actually the UA registers correctly and is reachable but natping
seems
>>to built the To hdr from the received field of the location table which
>>
>>
>only
>
>
>>has source ip and port of the registered packet and not the username
>>
>>
>>Exmample of locations table entry:
>>Username domain contact
>>
>>2120051099 sip:2120051099 at 172.16.1.1:5060
>>received
>>sip:111.16.187.102:5060
>>
>>The resulting natping packet from this would be
>>
>>U 2006/01/20 16:27:10.410848 111.15.13.67:5060 -> 111.16.187.102:5060
>>
>>/OPTIONS sip:111.16.187.102:5060 SIP/2.0./
>>Via: SIP/2.0/UDP 111.15.13.67:5060;branch=0.
>>From: sip:ping at intervoz.com.br;tag=ec30e9b7.
>>To: sip:111.16.187.102:5060.
>>Call-ID: b3fdcfa3-71a82db5-445151 at 111.15.13.67.
>>CSeq: 1 OPTIONS.
>>Content-Length: 0.
>>
>>As you can see if appears to use the received field.
>>
>>-----Original Message-----
>>From: Bogdan-Andrei Iancu [mailto:bogdan at voice-system.ro]
>>Sent: Friday, January 20, 2006 3:44 PM
>>To: Glenn Dalgliesh
>>Cc: users at openser.org
>>Subject: Re: [Users] nathelper natping OPTIONS packets formated to not get
>>reply?
>>
>>Hi Glenn,
>>
>>nathelper, when building the OPTIONS ping, for To hdr, the registered
>>contact is used (due simplicity reasons). So the client seams to
>>register contacts without username. interesting is why isn't it accept
>>them back :).
>>
>>regards,
>>bogdan
>>
>>Glenn Dalgliesh wrote:
>>
>>
>>
>>
>>
>>>I was looking at packet traces of the OPTIONS packets generated by
>>>natping and it appears that at least in my implementation of OpenSer
>>>1.0.0 the "To: sip" line has no username which causes many UA's
>>>require in order to respond to the OPTIONS packet. I was wondering if
>>>this was intentional or if it would be possible to change this
>>>behavior or at least make it an configurable option. I think a lot
>>>could be done/determined based on the results of the reply; including
>>>determining if the packet is really reaching the UA. I realize that
>>>some UA's may not support this feature but I think more do than not.
>>>
>>>Just my observations/thoughts. Please give me reasons for this being a
>>>good or bad idea..
>>>
>>>*Current Packet:*
>>>
>>>U 2006/01/20 16:27:10.410848 111.15.13.67:5060 -> 111.16.187.102:5060
>>>
>>>/OPTIONS sip:111.16.187.102:5060 SIP/2.0./
>>>
>>>Via: SIP/2.0/UDP 111.15.13.67:5060;branch=0.
>>>
>>>From: sip:ping at intervoz.com.br;tag=ec30e9b7.
>>>
>>>To: sip:111.16.187.102:5060.
>>>
>>>Call-ID: b3fdcfa3-71a82db5-445151 at 111.15.13.67.
>>>
>>>CSeq: 1 OPTIONS.
>>>
>>>Content-Length: 0.
>>>
>>>*Suggested Packet:*
>>>
>>>U 2006/01/20 16:27:10.410848 111.15.13.67:5060 -> 111.16.187.102:5060
>>>
>>>/OPTIONS sip:*<username from location table>*@111.16.187.102:5060
>>>SIP/2.0./
>>>
>>>Via: SIP/2.0/UDP 111.15.13.67:5060;branch=0.
>>>
>>>From: sip:ping at intervoz.com.br;tag=ec30e9b7.
>>>
>>>To: sip:111.16.187.102:5060.
>>>
>>>Call-ID: b3fdcfa3-71a82db5-445151 at 111.15.13.67.
>>>
>>>CSeq: 1 OPTIONS.
>>>
>>>Content-Length: 0.
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>Users mailing list
>>>Users at openser.org
>>>http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>>
>>>
>>>
>>_______________________________________________
>>Users mailing list
>>Users at openser.org
>>http://openser.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>>
>
>
>
More information about the sr-users
mailing list