9 Feb
2006
9 Feb
'06
6:26 p.m.
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@voice-system.ro]
Sent: Monday, January 23, 2006 7:00 AM
To: Glenn Dalgliesh
Cc: users(a)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@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@intervoz.com.br;tag=ec30e9b7.
To: sip:111.16.187.102:5060.
Call-ID: b3fdcfa3-71a82db5-445151(a)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@voice-system.ro]
Sent: Friday, January 20, 2006 3:44 PM
To: Glenn Dalgliesh
Cc: users(a)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@intervoz.com.br;tag=ec30e9b7.
To: sip:111.16.187.102:5060.
Call-ID: b3fdcfa3-71a82db5-445151(a)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@intervoz.com.br;tag=ec30e9b7.
To: sip:111.16.187.102:5060.
Call-ID: b3fdcfa3-71a82db5-445151(a)111.15.13.67.
CSeq: 1 OPTIONS.
Content-Length: 0.
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users