[Users] Trying to find a solution to a sticky problem here.

[Arek Bekiersz]

Hi,

Douglas Garstang wrote:
> Hmmm. Then I tried putting a record_route() right at the beginning of the route {} block. Actually I watched the packets with ngrep and I can see a Record-Route: header with OpenSER's IP address, but refers are still being sent directly from the phone to Asterisk.
> Any ideas?


IMHO this is UA problem. Try to upgrade UA, otherwise put pressure on 
vendor to change that. Sometimes you shall be able to persuade vendor to 
make such adjustments.

My UAs always send requests thru proxy, including REFER. I have over 10 
different vendors. I can send trace logs on priv email to proove that 
fact, if vendor is reluctant to admit he's got a bug.

Generally I'm fed up with SIP vendors and SIP operators doing what they 
want.. Every UA vendor understands SIP differently.. Like my last vendor 
whose device behind NAT puts public IPs everywhere. Or one of old 
providers, that always send OK, wherever the call to PSTN was successful 
or not :-) He was one of the biggest intl carriers. Great :)


-- 
Regards,
Arek Bekiersz



Anyone agrees
>  
> 
>>>If this is not enough, because you are outside of a dialog or have 
>>>particularly stupid UA - my SIP routing is based on domains. 
>>>So UAs are 
>>>always configured to use proxy and proxy is in textual format 
>>>of a realm 
>>>(FQDN). Thus, they will never send any dialog initiating request 
>>>ommiting proxy. Or they are very stupid UAs :-)
>>>
>>>Conclusion: trusted peers on (*) and IP-based policy on SER 
>>>works well 
>>>for me.
>>>
>>>-- 
>>>Regards,
>>>Arek Bekiersz
>>>
>>>
>>>
>>>
>>>Douglas Garstang wrote:
>>>
>>>>Trying to find a solution to a sticky problem here.
>>>>
>>>>We have 3 OpenSER systems. Phones register with the OpenSER 
>>>
>>>systems, and after they authenticate the user, pass the 
>>>registration info using OpenSER's send() command to all 
>>>Asterisk boxes sitting behind them. Each asterisk system then 
>>>knows about every phone.
>>>
>>>>For this to work, I had to turn off authentication in 
>>>
>>>Asterisk for both registrations and invites. If it's on, 
>>>asterisk sends a 407 Proxy Auth required to the phone in 
>>>addition to OpenSER. This confuses the phone, as it's now 
>>>receiving two 407 proxy auth requests, and it basically just 
>>>drops the second request on the floor. 
>>>
>>>>This is obviously a big security problem and it can't stay 
>>>
>>>this way. I thought maybe if authentication was on in 
>>>Asterisk, that considering by the time it receives the 
>>>authenticated register or invite from OpenSER, the MD5 
>>>password was already contained in the packet, that Asterisk 
>>>wouldn't ask again. It does. :(
>>>
>>>>We could use IP tables to only allow connections from the 
>>>
>>>OpenSER systems, but that doesn't always work. When a caller 
>>>transfers a call, the phones will send a REFER message 
>>>directly to Asterisk, so all the phones would have to also be 
>>>in the ip tables allow list. Not an elegent solution.
>>>
>>>>We could run mediaproxy on OpenSER and force all RTP 
>>>
>>>streams back through it. Might work, but it might also break 
>>>other stuff. We could then configure ip tables to only allow 
>>>RTP streams from the OpenSER systems.
>>>
>>>>It might be possible to configure OpenSER to perform the 
>>>
>>>logic necessary to make it talk to Asterisk properly, but 
>>>it's beyond my abilities and time.
>>>
>>>>Anyone ever done this? Anyone got any ideas?
>>>>
>>>>Doug
>>>
>>_______________________________________________
>>Users mailing list
>>Users at openser.org
>>http://openser.org/cgi-bin/mailman/listinfo/users
>>
> 
> 
> 
> 




Perceval R&D Team
arek at perceval.net

------------------------------------------------------------------------
Perceval Technologies sa/nv  Rue Tenbosch, 9  B-1000 Brussels
	Tel: +32-2-6409194 (ext.213) Fax: +32-2-6403154
         Direct: +32-2-6418775
URL: http://www.perceval.net/
E-mail for general informations: info at perceval.net
E-mail for technical informations: helpdesk at perceval.net
------------------------------------------------------------------------

This e-mail message contains legally PRIVILEGED and CONFIDENTIAL
information intended for the use of the addressee only. If you are not
the intended recipient of this message, please notify the undersigned
by telephone or e-mail reply and destroy this message and any
attachments.
Any views or opinions presented in this e-mail are solely those of
the author and do not necessarily represent those of Perceval. The
integrity and security of this message cannot be guaranteed and it may
be subject to data corruption, interception, unauthorised amendment,
viruses and unforesee