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@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@111.15.13.67.
CSeq: 1 OPTIONS.
Content-Length: 0.
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@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@111.15.13.67.
CSeq: 1 OPTIONS.
Content-Length: 0.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@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@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@111.15.13.67.
CSeq: 1 OPTIONS.
Content-Length: 0.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@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@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@111.15.13.67.
CSeq: 1 OPTIONS.
Content-Length: 0.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@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@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@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@111.15.13.67.
CSeq: 1 OPTIONS.
Content-Length: 0.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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?
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.
do you think that placing a static dummy username (if missing) into the TO will fix the problem?
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@voice-system.ro] Sent: Monday, January 23, 2006 7:00 AM To: Glenn Dalgliesh Cc: users@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@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@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@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@111.15.13.67.
CSeq: 1 OPTIONS.
Content-Length: 0.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
**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@voice-system.ro] Sent: Monday, January 23, 2006 7:00 AM To: Glenn Dalgliesh Cc: users@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@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@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@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@111.15.13.67.
CSeq: 1 OPTIONS.
Content-Length: 0.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Glen,
I think the best and simple solution will be to configure a complete static TO hdr to be used for constructing the OPTIONS ping. The TO uri (as value) has no relevance in routing or request acceptance, so it should not produce any side effects. Anyhow the current TO is an IP with port which also has no relevance for the UAC...
If you want I can send you a patch to test before putting in on CVS.
regards, bogdan
Glenn Dalgliesh wrote:
**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@voice-system.ro] Sent: Monday, January 23, 2006 7:00 AM To: Glenn Dalgliesh Cc: users@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@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@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..
-
Bogdan-Andrei Iancu -
Glenn Dalgliesh