[OpenSIPS-Users] b2b top-hiding and SDP origin line

Jeff Pyle jpyle at fidelityvoice.com
Tue Feb 8 21:59:35 CET 2011


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" <osas at 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 <jpyle at 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 at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>_______________________________________________
>Users mailing list
>Users at lists.opensips.org
>http://lists.opensips.org/cgi-bin/mailman/listinfo/users




More information about the Users mailing list