[OpenSIPS-Users] sl question.

johan johan at democon.be
Tue Sep 13 08:54:23 UTC 2022 

I have put my opensips.cfg to abolute bare metal and do the needed
manips in sipp.

route{
    # ASYNC PROCESSING => opensips handles it
    if (is_method("OPTIONS|NOTIFY|SUBSCRIBE")) {
        send_reply(200,"OK");
        drop();
    }
    
    if ($sp==IADPORT)   
    {
        xlog("from iad sp==$sp==IADPORT, we rewrite to sipp listening
port SIPPPORT and we forward to SIPPIP");
        forward("SIPPIP:SIPPPORT");
       
    }
    else if ($sp==SIPPPORT)
    {
        xlog("from sipp sp==$sp==SIPPPORT, we rewrite to iad listening
port IADPORT and we forward to IADIP");
        forward("IADIP:IADPORT");
    }
    else
    {
        xlog("sp==$sp!=[IADPORT,SIPPPORT], we drop the packet");
        drop();
    }
}

This works, so you can forget about this. 

On 12/09/2022 17:03, johan wrote:
>
> so the question is how can I do a forward message to an ip port
> without opensips rewriting the uri of ACK in stateless mode ? 
>
> On 12/09/2022 16:55, johan wrote:
>>
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:parse_msg: SIP Request:
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:parse_msg:  method:  <ACK>
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:parse_msg:  uri:    
>> <sip:+32478720104 at x.y.z.t:*11000*;transport=udp;alias=x.y.z.t~11000~1>
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:parse_msg:  version: <SIP/2.0>
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:parse_headers: flags=ffffffffffffffff
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:parse_via_param: found param type 232, <branch> =
>> <z9hG4bK-2487-1-5>; state=16
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:parse_via: end of header reached, state=5
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:parse_headers: via found, flags=ffffffffffffffff
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:parse_headers: this is the first via
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:parse_to_param: tag=4SpHB6a416Ucg
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:parse_to_param: end of header reached, state=13
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:_parse_to: end of header reached, state=29
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:_parse_to: display={sut},
>> ruri={sip:+32478720104 at 192.168.68.120:5060}
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:get_hdr_field: <To> [62];
>> uri=[sip:+32478720104 at 192.168.68.120:5060]
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:get_hdr_field: to body [sut
>> <sip:+32478720104 at 192.168.68.120:5060>]
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:get_hdr_field: cseq <CSeq>: <1> <ACK>
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:get_hdr_field: content_length=0
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:get_hdr_field: found end of header
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:receive_msg: After parse_msg...
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:receive_msg: preparing to run routing scripts...
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:sl:sl_filter_ACK: too late to be a local ACK!
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:comp_scriptvar: int 20: 5062 / 5060
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:comp_scriptvar: int 20: 5062 / 5062
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: from sipp
>> sp==5062==5062, we rewrite to iad listening port 5060 and we forward
>> to 185.58.97.161
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:parse_to_param: tag=1
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:parse_to_param: end of header reached, state=11
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:_parse_to: end of header reached, state=29
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:_parse_to: display={sipp}, ruri={sip:sipp at 192.168.68.120:5062}
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:uac:w_replace_from: dsp=0x7ffe38fec2d8 (len=0) ,
>> uri=0x7ffe38fec2f0 (len=41)
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> ERROR:uac:replace_uri: decline FROM/TO replacing in sequential
>> request in auto mode (has TO tag)
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> ERROR:uac:replace_uri: decline FROM/TO replacing in sequential
>> request in auto mode (has TO tag)
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:MD5StringArray: MD5 calculated: 100352e3496e8c8bc067bbd48b3fff67
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:parse_headers: flags=60
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:parse_headers: flags=ffffffffffffffff
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:forward_request: sending:#012ACK
>> sip:+32478720104 at x.y.z.t:*5060*;transport=udp;alias=x.y.z.t~11000~1 SIP>
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:forward_request: orig. len=419, new_len=510, proto=1
>> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]:
>> DBG:core:destroy_avp_list: destroying list 0x7f9d4b464ae8
>>
>>
>> On 12/09/2022 16:24, johan wrote:
>>> Hi,
>>>
>>> setup : opensips acts as a client of a remote server (i.e. opensips
>>> registers itself towards a provider) and handles the OPTIONS being
>>> sent.   On the same pc I have a sipp instance that generates traffic.
>>>
>>> hence
>>>
>>>
>>> provider <- udp 5060 -> opensips <-udp 5062-> sipp
>>>
>>>
>>> The issue is now that the provider changes the contact in 200 ok.
>>>
>>> Hence in sipp I take the contact from the received 200 and then I put in
>>> the request uri of the ACK.
>>>
>>> the problem si opensips rewrites the contact.
>>>
>>> How can I avoid that ?
>>>
>>>
>>> route{
>>>     # ASYNC PROCESSING => opensips handles it
>>>     if (is_method("OPTIONS|NOTIFY|SUBSCRIBE")) {
>>>         send_reply(200,"OK");
>>>         drop();
>>>     }
>>>     
>>>     if ($sp==IADPORT)   
>>>     {
>>>         xlog("from iad sp==$sp==IADPORT, we rewrite to sipp listening
>>> port SIPPPORT and we forward to SIPPIP");
>>>         forward("SIPPIP:SIPPPORT");
>>>        
>>>     }
>>>     else if ($sp==SIPPPORT)
>>>     {
>>>         xlog("from sipp sp==$sp==SIPPPORT, we rewrite to iad listening
>>> port IADPORT and we forward to IADIP");
>>>         forward("IADIP:IADPORT");
>>>     }
>>>     else
>>>     {
>>>         xlog("sp==$sp!=[IADPORT,SIPPPORT], we drop the packet");
>>>         drop();
>>>     }
>>> }
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20220913/0194abcd/attachment.html>

More information about the Users mailing list