24 Sep
2014
24 Sep
'14
3:16 p.m.
Hi,
I switched from rtpproxy module to the rtpproxy-ng module lately, and
noticed a strange behavior. In my branch route to the device, I have two
statements:
fix_nated_sdp("1");
rtpproxy_offer();
The first command appends a line with "direction:active" to the SDP. The
second one puts the RTP proxy in the stream. This worked all well with the
old rtpproxy module. But with the new rtpproxy-ng module, I get an empty
line after the SDP body, just before the "direction:active" line in the
SDP, which makes the packet invalid.
I tried changing the order of both statements, but without any difference.
What I saw is, that the old module just sent some basic parameters to the
rtpproxy and got only IP and port back. The new module sends the complete
SDP to the rtpengine and gets back the "fixed" SDP.
Has anyone ever seen this? Is there a way to fix it?
Best Regards,
Sebastian
24 Sep
24 Sep
3:26 p.m.
Sebastian Damm writes:
I switched from rtpproxy module to the rtpproxy-ng
module lately, and
noticed a strange behavior. In my branch route to the device, I have two
statements:
fix_nated_sdp("1");
rtpproxy_offer();
i would make only one of the above calls depending on if the destination
supports direction:active or not.
-- juha
3:30 p.m.
On Wed, Sep 24, 2014 at 3:26 PM, Juha Heinanen <jh(a)tutpro.com> wrote:
Sebastian Damm writes:
But what if I don't know what NAT situation is present for this call? I
just know, that it's some kind of NAT. I disabled the fix_nated_sdp part
for now, but I would enable it again if possible.
Sebastian
fix_nated_sdp("1");
rtpproxy_offer();
i would make only one of the above calls depending on if the
destination
supports direction:active or not.
3:43 p.m.
Sebastian Damm writes:
But what if I don't know what NAT situation is
present for this call? I
just know, that it's some kind of NAT. I disabled the fix_nated_sdp part
for now, but I would enable it again if possible.
if you don't know about the capabilities of the destination, then just
use media proxy.
-- juha
29 Sep
29 Sep
6:58 p.m.
On 09/24/14 09:16, Sebastian Damm wrote:
Hi,
I switched from rtpproxy module to the rtpproxy-ng module lately, and
noticed a strange behavior. In my branch route to the device, I have two
statements:
fix_nated_sdp("1");
rtpproxy_offer();
The first command appends a line with "direction:active" to the SDP. The
second one puts the RTP proxy in the stream. This worked all well with
the old rtpproxy module. But with the new rtpproxy-ng module, I get an
empty line after the SDP body, just before the "direction:active" line
in the SDP, which makes the packet invalid.
I tried changing the order of both statements, but without any
difference. What I saw is, that the old module just sent some basic
parameters to the rtpproxy and got only IP and port back. The new module
sends the complete SDP to the rtpengine and gets back the "fixed" SDP.
Has anyone ever seen this? Is there a way to fix it?
This is caused by rewriting the SDP body twice. The rtpproxy module only
rewrites small parts of the SDP, while rtpproxy-ng substitutes the
entire SDP body, which is why you run into conflicts when there's
another function touching the SDP body. Calling msg_apply_changes()
between the two calls fixes that, but may have side effects. I would
suggest the same as Juha did.
cheers
3517
days inactive
3522
days old
4 comments
3 participants
participants (3)
-
Juha Heinanen -
Richard Fuchs -
Sebastian Damm