El Viernes, 29 de Mayo de 2009, Iñaki Baz Castillo escribió:
El Viernes, 29 de Mayo de 2009, Thomas Gelf escribió:
Dan Pascu schrieb:
NAT issues are handled per branch, and so should RTP issues in case
of NAT problems. Functions like nat_keepalive and engage_media_proxy
take away a lot
El Sábado, 30 de Mayo de 2009, Dan Pascu escribió:
however, the changes
need to be done in dialog and tm not in mediaproxy, so it's a larger issue
to discuss here than enabling a mediaproxy function to work in a branch
route
Hi, does tm module also require changes for this purpose? I don't
Dan Pascu wrote:
On Saturday 30 May 2009, Thomas Gelf wrote:
engage_media_proxy doesn't terminate the media session until the dialog is
destroyed.
Hmmm... but it issues update commands (= use_media_proxy?) at each
Re-INVITE, does it?
It calls the equivalent of use_media_proxy for the
Iñaki Baz Castillo wrote:
I consider the redirect interception a real-world example and I'm pretty
sure others will think so too. Or consider some announcement mechanism,
with a 183-announcement from a media server (saying you're low on credit
or whatever) before sending a second branch to a
2009/5/29 Dan Pascu d...@ag-projects.com:
b) A is calling B, both with public IP. B issues a conditional
call forward (30x) to C, with C being behind NAT. As far as
I understood the module there is no way to engage Mediaproxy
in this scenario.
It depends on what you do. If you
On Friday 29 May 2009, Thomas Gelf wrote:
...this part leads me to the question, how such edge cases could
be automagically solved in the future.
Quite frankly I know of no generic solution to future undefined problems. That
is a fantasy. What we have is a solution with a given complexity that
Dan Pascu schrieb:
NAT issues are handled per branch, and so should RTP issues in case
of NAT problems. Functions like nat_keepalive and engage_media_proxy
take away a lot of pain from the script writer - and should therefore
be designed to behave flawlessly in most/all cases.
Again, this
El Viernes, 29 de Mayo de 2009, Thomas Gelf escribió:
Dan Pascu schrieb:
NAT issues are handled per branch, and so should RTP issues in case
of NAT problems. Functions like nat_keepalive and engage_media_proxy
take away a lot of pain from the script writer - and should therefore
be
On Saturday 30 May 2009, Thomas Gelf wrote:
engage_media_proxy doesn't terminate the media session until the dialog is
destroyed.
Hmmm... but it issues update commands (= use_media_proxy?) at each
Re-INVITE, does it?
It calls the equivalent of use_media_proxy for the initial INVITE, on
Hi list,
I really like engage_media_proxy() as it really makes life easier.
However, currently it is dialog-based and cannot be called in a
branch_route. This has some side-effect:
a) if a call is forked to two users, one behind NAT and one with
non-symmetric router and STUN or on public IP,
For scenario b I suspect you could just call a route from within the
failure route and engage the media proxy there. I know you will be
able to make the function call without error, just never tested it to
see if it has any undesired side effects. Like not actually working.
Richard Revels
Hi Richard,
thank you for your reply! I stopped using other routes to force
OpenSIPS into doing forbidden things a while ago. Mostly this
caused other issues - and usually there IS a reason why certain
methods are only allowed in certain route types ;-)
In this special case moving
On Thursday 28 May 2009, Thomas Gelf wrote:
Hi list,
I really like engage_media_proxy() as it really makes life easier.
However, currently it is dialog-based and cannot be called in a
branch_route. This has some side-effect:
a) if a call is forked to two users, one behind NAT and one with
13 matches
Mail list logo
