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
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users
Perceval R&D Team
[EMAIL PROTECTED]
------------------------------------------------------------------------
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: [EMAIL PROTECTED]
E-mail for technical informations: [EMAIL PROTECTED]
------------------------------------------------------------------------
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
_______________________________________________
Users mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users
