There is a use case mentioned "This is useful if you have a set of RTP proxies that the caller must use, and another distinct set of RTP proxies that the callee must use. This is supported by all rtpengine commands except rtpengine_manage(). "
How do you actually implement this - is it something like this?
Say caller supposed to target Set 1and callee supposed to target Set 2: # offer/request route set_rtpengine_set(1, 2) rtpengine_offer() # cannot use rtpengine_manage() # callee sees set 2 in SDP, right?
# reply_route set_rtpengine_set(2, 1) # reverse the order? Is this correct?? # OR set_rtpengine_set(1, 2) # keep order, module does autoreversal magic # caller sees Set 1 in SDP
My question: in the reply route do you keep the same order (module is clever enough to autoreverse so caller sees Set 1) OR do you explicitly reverse the order and THAT means caller sees Set 1.
Cheer Anthony
Hello,
I didn't know about limitation, so far I needed only set_rtpengine_set() with one parameter. Now I am wondering why won't work for rtpengine_manage() because internally it calls the rtpengine_offer()/_answer().
Not being familiar with this use case, I would to do a test and watch the commands towards the rtpengine via network, if looking at c code is not making it easy to sort it out. I am also curious to learn about your finding on this one, thus it would be good to share the results back to mailing list.
Cheers, Daniel
On 10.02.20 02:29, Anthony Alba wrote:
There is a use case mentioned "This is useful if you have a set of RTP proxies that the caller must use, and another distinct set of RTP proxies that the callee must use. This is supported by all rtpengine commands except rtpengine_manage(). "
How do you actually implement this - is it something like this?
Say caller supposed to target Set 1and callee supposed to target Set 2: # offer/request route set_rtpengine_set(1, 2) rtpengine_offer() # cannot use rtpengine_manage() # callee sees set 2 in SDP, right?
# reply_route set_rtpengine_set(2, 1) # reverse the order? Is this correct?? # OR set_rtpengine_set(1, 2) # keep order, module does autoreversal magic # caller sees Set 1 in SDP
My question: in the reply route do you keep the same order (module is clever enough to autoreverse so caller sees Set 1) OR do you explicitly reverse the order and THAT means caller sees Set 1.
Cheer Anthony
Daniel-Constantin Mierla writes:
Hello,
I didn't know about limitation, so far I needed only set_rtpengine_set() with one parameter. Now I am wondering why won't work for rtpengine_manage() because internally it calls the rtpengine_offer()/_answer().
I have never used rtpengine_manage, but regarding two sets, in request route before rtpengine_offer I do:
set_rtpengine_set("$avp(mediaproxy_caller_setid)", "$avp(mediaproxy_callee_setid)");
and in reply route before rtpengine_answer I do the same, i.e., the sets are in the same order.
Of course the script also needs to take care of the situation when request has no sdp and in-dialog requests.
-- Juha