[OpenSIPS-Users] Fixing c=IN for OpenSIPS server

Nick Khamis symack at gmail.com
Tue Mar 19 01:09:18 CET 2013


What parts of the SDP payload are most important when manipulating
"Far End" NAT traversal. How/where do we manipulate the Contact header
as such that it does not effect preceding loose routes.

A lot of examples cover an OpenSIPS+RTPProxy on a public IP that must
handle UA behind NAT. The problem we are having is that even our
OpenSIPS+RTPProxy server is behind a NAT, and getting dead ear when
using RTP proxy, and one way (outbound) audio when not using RTP proxy
implementation. Please help....

Nick.

On 3/15/13, Ovidiu Sas <osas at voipembedded.com> wrote:
> Contact is just a SIP header that you can manipulate via
> transformations and sipmsgops functions.
> You can even remove the received header and build/append a new one.
>
> Regards,
> Ovidiu Sas
>
> On Wed, Mar 13, 2013 at 1:13 PM, Nick Khamis <symack at gmail.com> wrote:
>> Hello Ovidiu,
>>
>> Thank you so much for your response. I got blind sided when we took on
>> this new DID service provider. What is strange is that the same
>> configuration works fine with three other providers.. Anyhow, c and o
>> are squared away however, I would also like to fix the contact using
>> fix_contact(). Is there any way I can pass the public IP to the
>> function? Almost there I hope.... :)
>>
>> Nicholas.
>>
>> On 3/13/13, Ovidiu Sas <osas at voipembedded.com> wrote:
>>> When calling rtpproxy_*, use flag 'c' along with the external IP as a
>>> second parameter:
>>> http://www.opensips.org/html/docs/modules/devel/rtpproxy#id292744
>>>
>>> Regards,
>>> Ovidiu Sas
>>>
>>> --
>>> VoIP Embedded, Inc.
>>> http://www.voipembedded.com
>>>
>>> On Tue, Mar 12, 2013 at 11:38 PM, Nick Khamis <symack at gmail.com> wrote:
>>>> Hello Everyone,
>>>>
>>>> We recently took on a new DID provider that is complaining about the
>>>> "c=IN IP4 192.168.2.5." advertised by our opensips server. They are
>>>> telling us that is the reason we are not receiving any audio. For some
>>>> reason this was not an issue with other service providers.
>>>> Moving forward, is it possible to change the "c=in" of the opensips
>>>> server before sending it to our service provider?
>>>>
>>>> I have seen how nat has been fixed for UA but no example for OpenSIPS
>>>> herself. As I mentioned OpenSIPS and RTPProxy is behind the NAT box.
>>>>
>>>> Thanks in Advance,
>>>>
>>>> Nick.
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



More information about the Users mailing list