On 25.10.2012 16:27, Juha Heinanen wrote:
Klaus Darilion writes:
Is it really worth differing between nated and non-nated clients?
yes, because operator of sip proxy would save in hardware costs.
In my setup I always treat every user as natted user - this makes the
config much more simple
Klaus Darilion writes:
> Is it really worth differing between nated and non-nated clients?
yes, because operator of sip proxy would save in hardware costs.
> In my setup I always treat every user as natted user - this makes the
> config much more simpler. But I haven't had projects with huge us
On 19.10.2012 21:40, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
But in this case the call is completed, because negative response codes
are absorbed by tm, 200ok being sent back, so no need to destroy any rtp
session. iirc, for all branches of a parallel fork there is one rtp
sessi
Daniel-Constantin Mierla writes:
> You can set a transaction flag when you force rtpproxy for a branch,
> then in onreply route, if you get a 200ok from a branch not involving
> rtp relay and that flag is set, then destroy the rtp relaying session.
that is exactly what i tried to do, but it req
Hello,
you can commit, but add it also to force_rtp_proxy, where it should be
just ignored -- in this way rtpproxy_manage() can be used for all
requests and replies with same parameter.
Cheers,
Daniel
On 10/20/12 9:17 AM, Juha Heinanen wrote:
the patch below adds 't' flag to rtpproxy_destro
On 10/19/12 9:40 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
But in this case the call is completed, because negative response codes
are absorbed by tm, 200ok being sent back, so no need to destroy any rtp
session. iirc, for all branches of a parallel fork there is one rtp
sessio
the patch below adds 't' flag to rtpproxy_destroy flags. if 't' flag is
present when rtpproxy_destroy is called, to tag is not included in D
command sent to rtpproxy thus causing destroy of the full call.
't' flag can be used to avoid piling up of unused rtpproxy calls by
making it possible to ca
Daniel-Constantin Mierla writes:
> But in this case the call is completed, because negative response codes
> are absorbed by tm, 200ok being sent back, so no need to destroy any rtp
> session. iirc, for all branches of a parallel fork there is one rtp
> session in rtpproxy (cannot tell about ot
On 10/19/12 9:11 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
why is that? in failure_route I call rtpproxy_mange() which calls
unforce_rtp_proxy() which destroys the initiated session.
as explained in earlier messages of this thread, the situation unused
rtp sessions pile up happ
Daniel-Constantin Mierla writes:
> why is that? in failure_route I call rtpproxy_mange() which calls
> unforce_rtp_proxy() which destroys the initiated session.
as explained in earlier messages of this thread, the situation unused
rtp sessions pile up happens, e.g., when call parallel forks and
On 10/19/12 8:30 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Popping in late, maybe I missed some parts, but I want to clarify that
all these cases discussed here were not tested with rtpproxy
application, right?
yes, they are all tested with real mediaproxy-ng rtpproxy server.
Daniel-Constantin Mierla writes:
> Popping in late, maybe I missed some parts, but I want to clarify that
> all these cases discussed here were not tested with rtpproxy
> application, right?
yes, they are all tested with real mediaproxy-ng rtpproxy server.
> For the archive, default config fil
Popping in late, maybe I missed some parts, but I want to clarify that
all these cases discussed here were not tested with rtpproxy
application, right?
For the archive, default config file destroys the rtp relaying session
in failure_route, when all branches are completed, doing it in onreply
Richard Fuchs writes:
> There's two timeouts, configurable through command line options, one is
> for active calls and defaults to 60 seconds, the other one is for
> silenced and not fully established calls and defaults to 1 hour. Calls
> will be cleared if no RTP traffic nor any re-invite has bee
On 10/19/12 11:16, Juha Heinanen wrote:
> i have not see in any document description about how long rtp proxy
> keeps the call state after it has received US command, but no matching
> LS command. is there a timer that clears those hanging calls once in a
> while and sip proxy config writer does
Richard Fuchs writes:
> I suppose it could make sense to change mediaproxy's behaviour to ignore
> the to-tag given in the delete message if it hadn't received a lookup
> for that particular branch yet.
richard,
thanks for your reply. that would solve the problem that currently there
is no way t
Hi,
While I can't really answer your question, the logic in mediaproxy-ng is
that if the to-tag is given in the "D"elete message, it has to match the
to-tag that was previously given in the "L"ookup message alongside with
the from-tag. If no to-tag is given in the delete message, then only the
fro
i made more tests on deleting rtpprxy session when 480 is received. in
this test there is only one uas registered for AoR t...@test.fi. when
it times out and replies with 480, sip proxy makes exactly same call
rtpproxy_manage("FROW3");
first in onreply route and then i failure route. t
Juha Heinanen writes:
> Oct 19 15:50:15 siika mediaproxy-ng[12832]: Got valid command from
> udp:127.0.0.1:56183: 18594_12 D
> ptonjivixvat...@siika.tutpro.com;z9hG4bKqxklorkm wnzdf shsqn
> Oct 19 15:50:15 siika mediaproxy-ng[12832]:
> [ptonjivixvat...@siika.tutpro.com] Tags didn't match for de
i made rtpproxy test in setup where two sip phones have registered the
same AoR t...@test.fi. one is behind nat and the other is not. when i
call this AoR, my sip proxy executes
rtpproxy_manage("FROW3");
in branch route of the branch that is behind nat.
syslog shows:
Oct 19 15:49:59 siika /us
20 matches
Mail list logo
