If the SDP is correct, then you might have specific issues related to your
specific deployment case. Snippets from others config files won't help. You
really need to investigate and understand your particular issue that you
are facing and fix it accordingly.
Regards,
Ovidiu Sas
On Oct 8, 2015
On 10/08/2015 09:09 AM, Ovidiu Sas wrote:
> If the SDP is correct, then you might have specific issues related to
> your specific deployment case. Snippets from others config files won't
> help. You really need to investigate and understand your particular
> issue that you are facing and fix it
I struggled with this setup for a while using rtpproxy, i eventually went
with rtpengine because it seems to have more features and is still
maintained.
I wrote a quick how-to (mostly for myself to remember)
If the SDP is correct, then you might have specific issues related to your
specific deployment case. Snippets from others config files won't help. You
really need to investigate and understand your particular issue that you
are facing and fix it accordingly.
Regards,
Ovidiu Sas
On Oct 8, 2015
On 30-09-15 13:29, Fred Posner wrote:
Without a version of rtpproxy using the -A flag, you'll need to either
(1) update to a different version of rtpproxy or (2) skip rtpproxy and
have your asterisk handle all the rtp.
I tried rtpproxy v2, with the -A flag in bridge mode ( -A
Dirk,
in case of a change, i would suggest to evaluate the use of rtpengine (
https://github.com/sipwise/rtpengine)
Regards,
Bruno
2015-09-30 13:15 GMT+02:00 Dirk Teurlings - SIGNET B.V. <
dteurli...@signet.nl>:
> On 30-09-15 12:23, Fred Posner wrote:
>
>>
>> Are you using -A flag in rttproxy?
Dirk,
have you tried to grab some trace with with sngrep? Maybe you'll be able to
figure out what's happening.
Regards,
Bruno
2015-09-30 11:30 GMT+02:00 Dirk Teurlings - SIGNET B.V. <
dteurli...@signet.nl>:
> On 30-09-15 11:28, Daniel Tryba wrote:
>
>> A quick and dirty workaround might be the
On 30-09-15 12:23, Fred Posner wrote:
Are you using -A flag in rttproxy?
Unfortunately we're running a version of RTPPROXY at the moment that
doesn't have this flag. I'm considering upgrading to rtproxy 2.0, but
will need to test whether this doesn't affect anything else.
It's preferred
On 09/30/2015 07:15 AM, Dirk Teurlings - SIGNET B.V. wrote:
> On 30-09-15 12:23, Fred Posner wrote:
>>
>> Are you using -A flag in rttproxy?
>>
>
> Unfortunately we're running a version of RTPPROXY at the moment that
> doesn't have this flag. I'm considering upgrading to rtproxy 2.0, but
> will
On 30-09-15 11:10, Daniel Tryba wrote:
The asterisk doesn't need to know the network topology beyond its connection
with kamailio, so you need to fix it at the place of traversal between public
and private: kamailio.
Agreed, I was looking for a workaround at this point, but to no avail.
On Wednesday 30 September 2015 11:17:54 Dirk Teurlings - SIGNET B.V. wrote:
> Agreed, I was looking for a workaround at this point, but to no avail.
A quick and dirty workaround might be the topoh module (which might break
other things though).
___
On 30-09-15 11:28, Daniel Tryba wrote:
A quick and dirty workaround might be the topoh module (which might break
other things though).
Already tried that as well, but that doesn't mask the private IP in the
important places. It only hides them in the via and record-route headers.
Cheers,
On 09/30/2015 04:22 AM, Dirk Teurlings - SIGNET B.V. wrote:
> Hi,
>
> CLIENTS <-> (NAT) <-> INTERNET <-> KAMAILIO(4.2.5) with
> RTPPROXY(v1) <-> PRIVATE LAN <-> ASTERISK (v1.8)
>
>
> Any pointer or help would be greatly appriciated.
>
> Cheers,
> Dirk
>
Are you using -A flag in
On Wednesday 30 September 2015 10:22:51 Dirk Teurlings - SIGNET B.V. wrote:
> CLIENTS <-> (NAT) <-> INTERNET <-> KAMAILIO(4.2.5) with
>RTPPROXY(v1) <-> PRIVATE LAN <-> ASTERISK (v1.8)
> I'm kind of stuck as to where I need to fix this. I tried using the
> externaddr option in Asterisk to
> On 30 Sep 2015, at 11:10, Daniel Tryba wrote:
>
> On Wednesday 30 September 2015 10:22:51 Dirk Teurlings - SIGNET B.V. wrote:
>> CLIENTS <-> (NAT) <-> INTERNET <-> KAMAILIO(4.2.5) with
>> RTPPROXY(v1) <-> PRIVATE LAN <-> ASTERISK (v1.8)
>
>> I'm kind of stuck as to
If you have kamailio bound to both private and public interfaces, then
you need to run rtpproxy in bridge mode (vanilla rtpproxy).
Another option is to get rid of the rtpproxy altogether and let
asterisk handle the media, but you will need to make sure that:
- kamailio is rewriting IPs in SDP
16 matches
Mail list logo