Maybe a bit offtopic, but I can't find a rtpengine mailinglist and know the Sipwise guys are reading this list.
Since upgrading to 4.2.x and rtpengine instead of rtpproxy I'm seeing problems with calls being terminated by upstream provider after a bit more than 5m. The INVITE process looks okay, the only difference with before as far as I can see is the rtcp attribute in the SDP body.
According to http://kamailio.org/docs/modules/4.2.x/modules/rtpengine.html#rtpengine.f.rt... and https://github.com/sipwise/rtpengine rtcp offering can be disabled. But neither rtcp-mux-demux nor rtcp-mux-accept have any impact on the adding of the a=rtcp:port attribute in SDP.
rtpengine_manage("trust-address replace-origin replace-session-connection rtcp-mux-accept ICE=remove"); or rtpengine_manage("trust-address replace-origin replace-session-connection rtcp-mux-demux ICE=remove");
have no effect op the INVITE to the upstream.
kamailio: 4.2.5 rtpengine: 4.1.0.0+0~mr4.1.0.0
Hello,
maybe you can just removed with textops or sdpops functions plus msg_apply_changes().
Cheers, Daniel
On 04/08/15 18:02, Daniel Tryba wrote:
Maybe a bit offtopic, but I can't find a rtpengine mailinglist and know the Sipwise guys are reading this list.
Since upgrading to 4.2.x and rtpengine instead of rtpproxy I'm seeing problems with calls being terminated by upstream provider after a bit more than 5m. The INVITE process looks okay, the only difference with before as far as I can see is the rtcp attribute in the SDP body.
According to http://kamailio.org/docs/modules/4.2.x/modules/rtpengine.html#rtpengine.f.rt... and https://github.com/sipwise/rtpengine rtcp offering can be disabled. But neither rtcp-mux-demux nor rtcp-mux-accept have any impact on the adding of the a=rtcp:port attribute in SDP.
rtpengine_manage("trust-address replace-origin replace-session-connection rtcp-mux-accept ICE=remove"); or rtpengine_manage("trust-address replace-origin replace-session-connection rtcp-mux-demux ICE=remove");
have no effect op the INVITE to the upstream.
kamailio: 4.2.5 rtpengine: 4.1.0.0+0~mr4.1.0.0
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
On Wednesday 05 August 2015 16:05:52 Daniel-Constantin Mierla wrote:
maybe you can just removed with textops or sdpops functions plus msg_apply_changes().
Somehow that doesn't work for me... The a=rtcp line remains whatever/whereever I try to use sdp_remove_line_by_prefix("a=rtcp") or replace_body_all("^a=rtcp:*", "") the line is send to the callee.
But in a semi related thread: http://lists.sip-router.org/pipermail/sr-users/2015-August/089436.html
write_sdp_pv might be the answer (4.3.x+)
On 08/10/2015 05:45 AM, Daniel Tryba wrote:
On Wednesday 05 August 2015 16:05:52 Daniel-Constantin Mierla wrote:
maybe you can just removed with textops or sdpops functions plus msg_apply_changes().
Somehow that doesn't work for me... The a=rtcp line remains whatever/whereever I try to use sdp_remove_line_by_prefix("a=rtcp") or replace_body_all("^a=rtcp:*", "") the line is send to the callee.
You may have to call msg_apply_changes() before rewriting the SDP. But are you actually certain that the a=rtcp line causes the problems? Because that would be pretty weird.
Cheers
On Monday 10 August 2015 07:37:43 Richard Fuchs wrote:
You may have to call msg_apply_changes() before rewriting the SDP.
I tried:
rptengine_manage msg_apply_changes sdp_remove_line_by_prefix/replace_body_all
But are you actually certain that the a=rtcp line causes the problems? Because that would be pretty weird.
No. But as far as I can see the a=rtcp is the only difference between the old setup (kamailio 3.x and rtpproxy) and the new setup (kamailio 4.2.x and rtpengine). I'll change to rtpproxy to see if it actually is the problem (but rtpproxy has other problems which rtpengine solves).
-
Daniel Tryba -
Daniel-Constantin Mierla -
Richard Fuchs