it was not clear to me based on rtpengine module readme if rtpengine_offer/answer are same kind of sdp manipulation functions as, for example, sdpops module functions, i.e., will rtpengine functions pass to rtpengine the sdp as it is after possible earlier sdpops function calls and will possible sdpops functions calls after rtpengine function call keep on manipulating the sdp returned from rtpengine function call.
-- juha
Hello,
iirc, based on what was discussed on the mailing list, at least in some cases, the full sdp is sent to rtpengine and then full sdp would be returned.
It doesn't do any use of sdpops module. You should use msg_apply_changes() in between them in order to have previous changes visible for further processing.
Cheers, Daniel
On 10/08/15 07:45, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
That is clear, but which "full" sdp: the original one or the one changed by previous sdpops calls?
It doesn't do any use of sdpops module.
That is clear too.
Do you mean that msg_apply_changes() needs to be called between each sdpops call? I thought that the changes made by sdpops calls are cumulative.
-- Juha
Le Mon, 10 Aug 2015 10:49:10 +0300, Juha Heinanen jh@tutpro.com a écrit :
Hi,
There is a `write_sdp_pv` parameter in the rtpengine module that makes rtpengine return the new SDP in a variable rather than in the message body. Personally I find it's more convenient to transform a variable several times than working directly on the message buffer and applying msg_apply_changes() several times.
Le Mon, 10 Aug 2015 12:38:57 +0300, Juha Heinanen jh@tutpro.com a écrit :
if the pvar is set, will rtpengine use its value also as input when rtpengine_offer/answer is called?
the current behaviour is to use this pvar for "output" only (the current message buffer will still be used as an input), but we could extend it to be used for input also if this is useful.
Camille Oudot writes:
i think it would be useful especially if sdpops functions could also be made operate on the pv. then there would no need to call msg_apply_changes(). the pv could be initialized from $rb and when all calls that manipulate the body have been made, the pv would be assigned to $rb.
-- juha
Le Mon, 10 Aug 2015 16:25:36 +0300, Juha Heinanen jh@tutpro.com a écrit :
Hi,
i've created a merge request on the master branch to add the rtpengine "input" SDP pv. I'm not sure if modifying sdpops to work also on variables would be straightforward, but anyway, most operations can be done using transformations.
On Monday 10 August 2015 12:24:10 Camille Oudot wrote:
How does that work? Setting the parameter like in the module doc results in: 0(21343) ERROR: <core> [modparam.c:139]: set_mod_param_regex(): parameter <write_sdp_avp> of type <1> not found in module <rtpengine> 0(21343) : <core> [cfg.y:3435]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 315, column 60: Can't set module parameter
315 being modparam("rtpengine", "write_sdp_avp", "$avp(sdp)") version: kamailio 4.3.1 (x86_64/linux)
Le Mon, 10 Aug 2015 13:00:19 +0200, Daniel Tryba d.tryba@pocos.nl a écrit :
315 being modparam("rtpengine", "write_sdp_avp", "$avp(sdp)") version: kamailio 4.3.1 (x86_64/linux)
you have to use the name "write_sdp_pv", not "..._avp"
Le Mon, 10 Aug 2015 16:47:55 +0200, Camille Oudot camille.oudot@orange.com a écrit :
Oh... I see the issue, there was a typo in the doc. It's fixed now.
On Monday 10 August 2015 17:35:50 Camille Oudot wrote:
you have to use the name "write_sdp_pv", not "..._avp"
Oh... I see the issue, there was a typo in the doc. It's fixed now.
That explains.
But I'm still not getting how it works. The avp is always null (request/reply and onsend routes) after using rtpengine_manage. Does it really only work with rtpengine_(offer|answer)? I'm to lazy to replace _manage :)
Le Mon, 10 Aug 2015 17:12:22 +0200, Daniel Tryba d.tryba@pocos.nl a écrit :
Should be working with rtpengine_manage() too. Can you see any meaningful log, while initializing the rtpengine module, or during the rtpengine_manage() call? If no pvar is set, then is the body of the SIP message modified with the new SDP?
On Monday 10 August 2015 19:23:26 Camille Oudot wrote:
Well, I'm an idiot. Forgot to remove the # in front of the modparam.
pv is populated with the SDP body now. Only strange thing is that $var(sdp) is set to 0 on on the second passing of below during branch routing after handling a 302 redirect:
rtpengine_manage("RTP trust-address replace-origin replace-session-connection ICE=remove");
xlog("rtpengine avp: $var(sdp)");
if($(var(sdp){s.len})>1 && has_body()) { $var(sdp)=$var(sdp)+"a=X-foo:bar\r\n"; replace_body_atonce("^.+$", $var(sdp)); $var(sdp[*])=$null; }
Le Mon, 10 Aug 2015 18:33:47 +0200, Daniel Tryba d.tryba@pocos.nl a écrit :
Only strange thing is that $var(sdp) is set to 0 on on the second passing of below during branch routing after handling a 302 redirect
I don't know the full context here, but since $var()s are process-local, is the process reading the "0" value the same one that has set it?
On 10/08/15 09:49, Juha Heinanen wrote:
I expect to be the originial one.
Some of the sdpops functions were added by others, but I expect they still use the lump mechanism as those I did, so the changes are not immediately visible.
You don't need to do msg_apply_changes() after each sdpops change, unless you want that preview change to be visible for next operations.
For example, you can call the function to remove a codec twice, once for g711 and once for g729 without msg_apply_change() and all should be fine.
However, if you want to remove video media stream and then call rtpengine/rtpproxy, then the msg_apply_changes() would be required in order for rtp relay application not to see the video stream.
Cheers, Daniel
-
Camille Oudot -
Daniel Tryba -
Daniel-Constantin Mierla -
Juha Heinanen