Ovidiu, Apparently once a dialog is in b2b-land, its messages are unavailable to scripting functions? It seems Anca has said this a time or two. Or three. Still seems strange.
I'm close to what you have suggested. I'm using mediaproxy on my "main" proxy in lieu of rtpproxy, with b2bua on a dedicated one upstream. Everything is golden except the o= line since the dispatcher module handles the c= line update. I'm working through a solution that hits a subst_body on the "main" proxy in branch and onreply routes to handle the o= line: if (is_dlg_flag_set("24") && search("Content-Type: application/sdp")) { subst_body('/^o=(.*) IN IP4 .*/o=\1 IN IP4 127.0.0.1/'); } Dialog flag 24 is used to indicate whether the call went through the upstream b2bua or not, as not all calls do in this case. Not pretty, but so far it seems to do the trick. - Jeff On 2/8/11 3:22 PM, "Ovidiu Sas" <o...@voipembedded.com> wrote: >What's the point of hiding the o= line? >The c= line will still reveal the connection IP for RTP. > >If you want true topology hiding, then use two servers and chain them: > - opensips with rtpproxy; > - opensips as a b2bua with "top hidding". > >On the rtpproxy server you will be able to mask everything on the SDP >side (see the 'o' flag for rtpproxy commands). > > >Regards, >Ovidiu Sas > >On Tue, Feb 8, 2011 at 2:40 PM, Jeff Pyle <jp...@fidelityvoice.com> wrote: >> Hello, >> Since the top-hiding scenario doesn't touch the SDP, it seems some >> extracurricular textops may be required to fully hide the topology of >>the >> network. I've been trying various subst_body() functions on my b2b >>Opensips >> instance, each failing in a new and wonderful way. >> >> route[b2b_request] { >> if (search("Content-Type: application/sdp")) { >> xlog("L_INFO", "Attempting to rewrite origin line in >> b2b_request\n"); >> subst_body('/^o=.*/o=request 12345 67890 IN IP4 >>8.4.6.2/'); >> } >> } >> route[b2b_reply] { >> if (search("Content-Type: application/sdp")) { >> xlog("L_INFO", "Attempting to rewrite origin line in >> b2b_reply\n"); >> subst_body('/^o=.*/o=reply 12345 67890 IN IP4 >>8.4.6.2/'); >> } >> } >> local_route { >> if (search("Content-Type: application/sdp")) { >> xlog("L_INFO", "Attempting to rewrite origin line in >> local_route\n"); >> subst_body('/^o=.*/o=local 12345 67890 IN IP4 >>8.4.6.2/'); >> } >> } >> >> With the above config, the initial INVITE b2b'd through >> with b2b_init_request("top hiding") does have it's origin line operated >> upon. After that, I see two xlogs hit from within b2b_reply on the 183 >>and >> 200 coming back through, but the subst_body commands have no effect. >> No, I'm not really going to rewrite my origin lines to a static value >>like >> this; this is just for testing. And the test is not going well. >> How does one affect the origin line in a b2b environment for true >>topology >> hiding? Or, is that the key, that it must be done outside of a b2b >> environment? >> >> - Jeff >> >> _______________________________________________ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > >_______________________________________________ >Users mailing list >Users@lists.opensips.org >http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users