[SR-Users] One way audio calls

[Will Ferrer]

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 at gmail.com> wrote:

> i have the same problem :(
> look this
> http://saghul.net/blog/2010/05/06/atravesando-el-nat-con-opensips-1-6-y-mediaproxy/
>
> 2014-11-20 19:06 GMT-03:00 Will Ferrer <will.ferrer at 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 at gmail.com>
>> wrote:
>>
>>> u job behind nat?
>>>
>>> 2014-11-19 3:13 GMT-03:00 Will Ferrer <will.ferrer at 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 at 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 at 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 at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20141201/73559099/attachment.html>