Hi Javier

After giving the article a careful read through it looks to me like my config already handles all the issues they talked about in the article. We tried these changes both with rtpproxy and with rtpengine equivalent usage and had no luck.

Thank you for sharing though!

I hope all is going well with you.

All the best.

Will Ferrer

Switchsoft Inc

On Mon, Dec 1, 2014 at 5:37 PM, Will Ferrer <will.ferrer@switchsoft.com> wrote:
Hi Javier

Thanks for the tip. Have you tried the solution given in that post yet?

Currently I am waiting for my team to get me log captures to send to Richard Fuchs at sipwise. We are trying to change our logging system to get the rtpengine related logs on a failed one way audio call.

In the mean time I may try the methods posted here.

I will post back if I do and let you know what I find.

Thanks much for your help.

All the best.

Will Ferrer

On Mon, Dec 1, 2014 at 5:30 AM, Javier Ricke <javierr.vv@gmail.com> wrote:

2014-11-20 19:06 GMT-03:00 Will Ferrer <will.ferrer@switchsoft.com>:

Hi Javier

Yes we are, but the problem only happens in %6-%8 of the calls. It happens in calls that have identical signaling to the ones that don't have the problem.

I have been speaking with Richard Fuchs at sip wise and I am going to try adding the trust address flag to sip wise and see if it helps. That hopefully will make it take the address in the c= attribute more readily.

I will update this thread once we push that live.

If any one has another suggestions though I am very open to hearing them :).

Thanks very much.

All the best.

Will Ferrer

Switchsoft Inc

On Thu, Nov 20, 2014 at 9:29 AM, Javier Ricke <javierr.vv@gmail.com> wrote:
u job behind nat?

2014-11-19 3:13 GMT-03:00 Will Ferrer <will.ferrer@switchsoft.com>:
Hi All

We are experiencing an odd problem with 1 way audio in about %6-%8 of our calls.

It seems to me that what is happening is that our kamailio installation (using rtpengine) is some times ignoring the c= attribute that the carrier is sending us, and sending our audio instead to either address in the carriers o= attribute, or just to the same address we sent our sip invite too.

We have looked at hundreds of calls and haven't found a reliable pattern why this happens some times and not others. It really happens in a lot of different scenarios with lots of different carriers and differently formatted SDP packets.

I was wondering if any one had an idea where to start for a solution, or a way to make rtpengine always send audio to the ip in the c= attribute we are receiving from the carrier.

I haven't been able to find anything so far.

Thank you much for any assistance.

All the best.

Will

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users