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

Bogdan-Andrei Iancu bogdan at voice-system.ro
Mon Jan 23 13:00:03 CET 2006


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