[OpenSIPS-Users] Odd URI formatting issue when using Exec to return a variable

Bogdan-Andrei Iancu bogdan at opensips.org
Thu Nov 16 15:05:11 UTC 2023


I agree here, it looks like the exec output has some trailing chars, 
like an \n .....

Ben, try doing

     $branch = $(var(out){s.trim});

See https://opensips.org/Documentation/Script-Tran-3-4#s.trim

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 11/16/23 3:26 AM, Gregory Massel via Users wrote:
>
> Just wondering if, perhaps, the script return a line terminated with 
> \r\n instead of just \n ? Or perhaps even just a \n is being pulled 
> into the variable?
>
> Perhaps try a {s.trim} transformation?
>
> On 2023-11-15 13:27, Bogdan-Andrei Iancu wrote:
>> Out of curiosity, if you replace the:
>>     $branch = $var(out);
>> with
>>     $ru = $var(out)
>> is the reply properly formed ?
>>
>> Regards,
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>    https://www.opensips-solutions.com
>>    https://www.siphub.com
>> On 11/15/23 12:19 PM, Ben Bliss wrote:
>>>
>>> HI Bogdan,
>>>
>>> Thanks for the reply.
>>>
>>> I was using 3.2.13, so I have now patched this to 3.2.15, which is 
>>> the latest version on the 3.2 branch. I repeated the test and got 
>>> the same behaviour. Please see the below information as requested…
>>>
>>> Script…
>>>
>>>         if ( $si == '10.10.14.71' && is_method("INVITE") ) {
>>>
>>> exec("/usr/local/bin/sbc-route", $tU, $var(out));
>>>
>>>                         xlog("Value returned from Re-direct Script 
>>> is $var(out)");
>>>
>>>                         $branch = $var(out);
>>>
>>>                         xlog("Target is set as $branch");
>>>
>>>                         send_reply(302, "Server Redirect");
>>>
>>>                         exit;
>>>
>>>         }
>>>
>>> Xlog information logged when the call request comes in…
>>>
>>> 2023-11-15T09:52:55.375039+00:00 uk-rdh-testast2 
>>> /usr/sbin/opensips[283656]: Value returned from Re-direct Script is 
>>> sip:33557719673 at 10.10.4.77
>>>
>>> 2023-11-15T09:52:55.375456+00:00 uk-rdh-testast2 
>>> /usr/sbin/opensips[283656]: Target is set as sip:33557719673 at 10.10.4.77
>>>
>>> The 302 response is below, exported from Wireshark…
>>>
>>> No.     Time Source                Destination           Protocol 
>>> Length Info
>>>
>>> 15 09:53:20.012882 10.10.12.70           10.10.14.71           SIP 
>>> 666    Status: 302 Server Redirect |
>>>
>>> Frame 15: 666 bytes on wire (5328 bits), 666 bytes captured (5328 bits)
>>>
>>> Ethernet II, Src: bb:bb:bb:bb:bb:bb (bb:bb:bb:bb:bb:bb), Dst: 
>>> aa:aa:aa:aa:aa:aa (aa:aa:aa:aa:aa:aa)
>>>
>>> Internet Protocol Version 4, Src: 10.10.12.70, Dst: 10.10.14.71
>>>
>>> User Datagram Protocol, Src Port: 5070, Dst Port: 5060
>>>
>>> Session Initiation Protocol (302)
>>>
>>>     Status-Line: SIP/2.0 302 Server Redirect
>>>
>>>     Message Header
>>>
>>>         From: 
>>> sip:+4478341xxxxx at 151.x.xxx.x;user=phone;tag=BN1699364674-1-1700041999-377836318
>>>
>>>         To: 
>>> sip:+4415279xxxxx at 149.x.xxx.xx;user=phone;tag=5d8f.6023fbda08f41f7e9ebdc611f91805ef
>>>
>>>         Call-ID: 55197572_103382176 at 151.x.xxx.x
>>>
>>>         [Generated Call-ID: 55197572_103382176 at 151.x.xxx.x]
>>>
>>>         CSeq: 61414 INVITE
>>>
>>>         Via: SIP/2.0/UDP 
>>> 10.10.14.71:5060;branch=z9hG4bK-6a03d713-a7b27-28f11294-7f0923fc1278
>>>
>>>         Via: SIP/2.0/UDP 
>>> 149.x.xxx.xx:5060;received=151.x.xxx.x;rport=5060;branch=z9hG4bK1699364674
>>>
>>>         Via: SIP/2.0/UDP 
>>> 151.x.xxx.x:5060;branch=z9hG4bK0aB2fefabe20ff62d0e
>>>
>>>         Contact: <sip:33557719673 at 10.10.4.77
>>>
>>>         [Expert Info (Warning/Malformed): Header has no colon after 
>>> the name]
>>>
>>>             [Header has no colon after the name]
>>>
>>>             [Severity level: Warning]
>>>
>>>             [Group: Malformed]
>>>
>>>         Server: OpenSIPS (3.2.15 (x86_64/linux))
>>>
>>>         Content-Length: 0
>>>
>>> If it is any help, I did try another method of inputting the Contact 
>>> header, which was using the ‘append_to_reply’ command, rather than 
>>> using the $branch method, so I just formatted in the URI as such…
>>>
>>> append_to_reply('Contact: <$var(out)>');
>>>
>>> This pushed the closing > from the ‘Contact’ URI to the “Server” 
>>> line, as you can see on the outputted 302 below…
>>>
>>> No.     Time Source                Destination           Protocol 
>>> Length Info
>>>
>>>      17 12:12:01.339034 10.10.12.70           10.10.14.71           
>>> SIP 667    Status: 302 Server Redirect |
>>>
>>> Frame 17: 667 bytes on wire (5336 bits), 667 bytes captured (5336 bits)
>>>
>>> Ethernet II, Src: bb:bb:bb:bb:bb:bb (bb:bb:bb:bb:bb:bb), Dst: 
>>> aa:aa:aa:aa:aa:aa (aa:aa:aa:aa:aa:aa)
>>>
>>> Internet Protocol Version 4, Src: 10.10.12.70, Dst: 10.10.14.71
>>>
>>> User Datagram Protocol, Src Port: 5070, Dst Port: 5060
>>>
>>> Session Initiation Protocol (302)
>>>
>>>     Status-Line: SIP/2.0 302 Server Redirect
>>>
>>>     Message Header
>>>
>>>         From: 
>>> sip:+4478341xxxxx at 151.x.xxx.x;user=phone;tag=BN1699364667-1-1699963921-901707368
>>>
>>>         To: 
>>> sip:080001xxxxx at 149.x.xxx.xx;user=phone;tag=5d8f.a1daebfe0f15d4035f73e92edd390da9
>>>
>>>         Call-ID: 55182316_87520217 at 151.x.xxx.x
>>>
>>>         [Generated Call-ID: 55182316_87520217 at 151.x.xxx.x]
>>>
>>>         CSeq: 706035 INVITE
>>>
>>>         Via: SIP/2.0/UDP 
>>> 10.10.14.71:5060;branch=z9hG4bK-34260abf-94a28-2449afc3-7f0920d0abc8
>>>
>>>         Via: SIP/2.0/UDP 
>>> 149.x.xxx.xx:5060;received=151.x.xxx.x;rport=5060;branch=z9hG4bK1699364667
>>>
>>>         Via: SIP/2.0/UDP 
>>> 151.x.xxx.x:5060;branch=z9hG4bK0aB220722fa7bfe603d
>>>
>>>         Contact: <sip:33557719673 at 10.10.4.77:5060
>>>
>>>         >Server: OpenSIPS (3.2.13 (x86_64/linux))
>>>
>>>             [Expert Info (Note/Undecoded): Unrecognised SIP header 
>>> (>server)]
>>>
>>>                 [Unrecognised SIP header (>server)]
>>>
>>>                 [Severity level: Note]
>>>
>>>                 [Group: Undecoded]
>>>
>>>         Content-Length: 0
>>>
>>> Whether this is related or not, I cannot say, but thought I would 
>>> include it in any case.
>>>
>>> Many Thanks,
>>>
>>> Ben
>>>
>>> *From:*Bogdan-Andrei Iancu <bogdan at opensips.org>
>>> *Sent:* Wednesday, November 15, 2023 7:30 AM
>>> *To:* OpenSIPS users mailling list <users at lists.opensips.org>; Ben 
>>> Bliss <ben.bliss at telxl.com>
>>> *Subject:* Re: [OpenSIPS-Users] Odd URI formatting issue when using 
>>> Exec to return a variable
>>>
>>> CAUTION: This email originated from outside your organization. 
>>> Exercise caution when opening attachments or clicking links, 
>>> especially from unknown senders.
>>>
>>> Hi Ben,
>>>
>>> Could you post the xlog output and the resulting 302 ? Also be sure 
>>> you are using the latest 3.2 version - please post the `opensips -V` 
>>> here.
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developer
>>>    https://www.opensips-solutions.com  <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.opensips-solutions.com&c=E,1,n_ThlRNU3i-MoIo_dhzoLTuWEvWUOlYVNSDoisTDDrwzbpcftjAa4w_2PyxMOisnPvCBiGpAygCZjMhqUzFW_eo3M1DZs60QBAwbpZYM6fdEYEdZt7_0&typo=1>
>>>    https://www.siphub.com  <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.siphub.com&c=E,1,FaWC5zmYssK-iGLeBMdcpIfqOyqXzRepdKxkoIroZfSn0rDpGcOHq3E-rAA6pLhypuKjMgc8st1DlBDvpaiolXtmHYeW9PIxKMk9l27g6Jmoso3H5n9a6tC2bOqe&typo=1>
>>>
>>> On 11/14/23 4:00 PM, Ben Bliss wrote:
>>>
>>>     I am using Opensips v.3.2 and I am attempting to replicate the
>>>     302 redirect outlined on the blog
>>>     (https://blog.opensips.org/2018/07/05/handling-sip-redirect-requests-in-realtime/),
>>>     but am running into an odd issue.
>>>
>>>     I am using exec to execute an external program, which returns a
>>>     URI as a variable, which is then used to populate the $branch
>>>     field, which is then returned as the contact URI in the 302
>>>     response.
>>>
>>>     For reasons I cannot explain, even though the URI is correctly
>>>     formatted in the xlogs which I print off during the call
>>>     request, when the 302 message is received, the Contact URI is
>>>     missing the end ‘>‘character. This means the server the 302 is
>>>     being sent to doesn’t ACK the message, as the contact URI is
>>>     invalid.
>>>
>>>     If I specify the URI directly within OpenSIPs, then the contact
>>>     header is then formatted correctly.
>>>
>>>     Initially I thought the issue was related to the script
>>>     returning the variable (bash script), so I swapped to a Golang
>>>     program, essentially returning the same URI, but the same
>>>     behaviour occurs with this as well.
>>>
>>>     The script is setup as follows…
>>>
>>>             if ( $si == '10.10.14.71' && is_method("INVITE") ) {
>>>
>>>     exec("/usr/local/bin/sbc-route", $tU, $var(out));
>>>
>>>                             xlog("Value returned from Re-direct
>>>     Script is $var(out)");
>>>
>>>                             $branch = $var(out);
>>>
>>>                             xlog("Target is set as $branch");
>>>
>>>     send_reply(302, "Server Redirect");
>>>
>>>                             exit;
>>>
>>>             }
>>>
>>>     Can anyone offer any ideas as to why this may be occurring?
>>>
>>>
>>>
>>>     _______________________________________________
>>>
>>>     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
>>
>>
>> _______________________________________________
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20231116/1e1f32a2/attachment-0001.html>


More information about the Users mailing list