[SR-Users] Kamailio with rtpproxy-ng and mediaproxy-ng: Error rewriting SDP

Olli Heiskanen ohjelmistoarkkitehti at gmail.com
Wed Aug 6 13:25:40 CEST 2014


Hello,

I must say this problem with Asterisk versions before 11.11 remains a
mystery, after upgrading to Asterisk 11.11 and a while of setting up
Asterisk realtime fields and also upgrading to sip.js I managed to get
calls flowing between websocket and Zoiper clients.

In case someone is having similar problems as I did, I think the most
relevant problems were in Asterisk configuration and its older version.

In addition, although this didn't completely solve my problems with the
earlier Asterisk version, it may be useful to someone working with Kamailio
and Asterisk:
http://forums.digium.com/viewtopic.php?f=1&t=90167&sid=66fdf8cc4be5d955ba584e989a23442f

Thank you Richard and everyone for helping. Even though the original
problem was never solved, all this has been extremely useful and
interesting.

cheers,
Olli




2014-07-31 20:28 GMT+03:00 Olli Heiskanen <ohjelmistoarkkitehti at gmail.com>:

> Hi,
>
> Thanks for your efforts, now after lots of hours trying different ways and
> working through my config, I'm baffled. Somehow I think I must have done
> something wrong when combining different tutorials (like use of dispatcher,
> realtime integration and websocket clients). Something I noticed was that
> before I had a rtpproxy_manage("CO"); call in NATMANAGE route. I had
> changed it to rtpengine_manage("replace-origin
> replace-session-connection"); by comparing mediaproxy-ng and rtpengine
> documentations. I wonder if this might mess up the sdp and appear in logs
> as if some flags are missing? In some of my tests the rtpengine_offer_flags
> variable had null value in some places, I didn't analyse that yet in any
> detail but that does tell me that something's happening that shoudln't.
>
> I decided to upgrade my clients to using the Onsip sip.js (0.6.1) instead
> of jssip. Also, I upgraded my Asterisk to 11.11.0. I started getting
> different results, namely a whole new set of problems; the location lookup
> keeps failing when trying to make calls from any client. I'll start
> investigating that now and try different clients etc. When I get calls
> working again I can focus on the sdp side.
>
> cheers,
> Olli
>
>
>
>
>
>
> 2014-07-24 16:44 GMT+03:00 Richard Fuchs <rfuchs at sipwise.com>:
>
> On 24/07/14 09:27 AM, Olli Heiskanen wrote:
>>
>>>
>>> That's odd... I pulled a new version from git master 4 days ago, and
>>> copied the compiled rtpengine to /usr/sbin, which is running. (although
>>> might help verifying the version if command rtpengine --version gave
>>> actual output instead of 'undefined') :)
>>>
>>> Any chance my environment might cause something like this? For example I
>>> can't use kernel packet forwarding as I'm running these on a virtual
>>> server. I don't think this problem has anything to do with the kernel
>>> module but maybe something environment related (virtual server, nat,
>>> having Asterisk on the side, etc...), or maybe the way I've written my
>>> config?
>>>
>>
>> I can't imagine what. The selection of active/passive is pretty
>> straightforward and doesn't depend on much of anything. The
>> offer/answer/delete commands as reproduced in full in the log are all the
>> input that rtpengine gets, and with the same input it should always produce
>> the same result.
>>
>> The only thing to consider is that in your pasted log, the "offer"
>> command is truncated in the SDP and so some of the flags are missing. I
>> don't think they would make a lot of difference though, and I tried a few
>> different variations and still couldn't reproduce it.
>>
>>
>> cheers
>>
>> _______________________________________________
>> 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/20140806/af607a34/attachment.html>


More information about the sr-users mailing list