Re: [OpenSIPS-Users] How to get the name-addr within a From header?

2020-03-31 Thread Gordon Yeong 
>
>
Hello, Grant and Răzvan,

 Good morning. It worked like a charm.
 Thank you :)
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Errors

2020-03-31 Thread Saint Michael 
The server has 64 cores and plenty of RAM but it is a Vmware ESXi virtual
machine.
I think we need to change something at compile time to make sure opensips
runs well in a virtual environment because nobody is using anything else.



On Tue, Mar 31, 2020 at 4:36 PM Callum Guy  wrote:

> You're not the only one my friend, I've seen plenty of discussions on the
> topic in the mailing list so browse the archives for details.
>
> i.e.
> https://opensips.org/pipermail/users/2018-September/039895.html
>
> Here's a quote from Bogdan later in that thread:
>
> "If there is no load (worker processes are idle, no busy with anything
> else), the reported delay may be generated only by the interprocess
> communication (passing the job from the triggering process to the
> executing process via internal pipes).
>
> What are the values you typically observe ? maybe the warning is jst
> about a slow context switching on your server (btw, how many cores ?)."
>
> For what it's worth I've been seeing these in production for a long time
> and they seem harmless. It was on my list to speak to people about at the
> Summit but looks like I'll have to wait until September! We're running quad
> core VM's.
>
>
>
> On Tue, 31 Mar 2020 at 18:44, Saint Michael  wrote:
>
>> Does anybody have any idea what causes this error?
>> I am pulling my hair.
>>
>> ps[1883]: Mar 31 17:10:49 [1903] WARNING:core:utimer_ticker: utimer task
>>  already scheduled for 190 ms (now 890 ms), it may overlap..
>> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1903]
>> WARNING:core:utimer_ticker: utimer task  already scheduled for
>> 190 ms (now 990 ms), it may overlap..
>> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1903]
>> WARNING:core:utimer_ticker: utimer task  already scheduled for
>> 190 ms (now 1090 ms), it may overlap..
>> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1961]
>> WARNING:core:handle_timer_job: utimer job  has a 97 us delay
>> in execution
>> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1955]
>> WARNING:core:handle_timer_job: utimer job  has a 97 us delay
>> in execution
>> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1961]
>> WARNING:core:handle_timer_job: timer job  has a 17 us delay
>> in execution
>> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1930]
>> WARNING:core:handle_timer_job: utimer job  has a 97 us delay
>> in execution
>> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1980]
>> WARNING:core:handle_timer_job: timer job  has a 17 us delay
>> in execution
>> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1971]
>> WARNING:core:handle_timer_job: timer job  has a 17 us delay
>> in execution
>> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1951]
>> WARNING:core:handle_timer_job: utimer job  has a 97 us delay
>> in execution
>> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1928]
>> WARNING:core:handle_timer_job: timer job  has a 17 us delay
>> in execution
>> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1914]
>> WARNING:core:handle_timer_job: timer job  has a 17 us delay
>> in execution
>> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1961]
>> WARNING:core:handle_timer_job: timer job  has a 17 us
>> delay in execution
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
> 
>
> *0333 332   |  x-on.co.uk   |   **
>    
>    **  |  Coronavirus
> *
>
> THE ITSPA AWARDS 2020  AND Best
> ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks
> of the Internet Telephony Services Providers' Association, used under
> licence.
>
> X-on is a trading name of Storacall Technology Ltd a limited company
> registered in England and Wales.
> Registered Office : Avaland House, 110 London Road, Apsley, Hemel
> Hempstead, Herts, HP3 9SD. Company Registration No. 2578478.
> The information in this e-mail is confidential and for use by the
> addressee(s) only. If you are not the intended recipient, please notify
> X-on immediately on +44(0)333 332  and delete the
> message from your computer. If you are not a named addressee you must not
> use, disclose, disseminate, distribute, copy, print or reply to this email. 
> Views
> or opinions expressed by an individual
> within this email may not necessarily reflect the views of X-on or its
> associated companies. Although X-on routinely screens for viruses,
> addressees should scan this email and any attachments
> for viruses. X-on makes no representation or warranty as to the absence of
> viruses in this email or any attachments.
>
> ___

Re: [OpenSIPS-Users] Errors

2020-03-31 Thread Callum Guy 
You're not the only one my friend, I've seen plenty of discussions on the
topic in the mailing list so browse the archives for details.

i.e.
https://opensips.org/pipermail/users/2018-September/039895.html

Here's a quote from Bogdan later in that thread:

"If there is no load (worker processes are idle, no busy with anything
else), the reported delay may be generated only by the interprocess
communication (passing the job from the triggering process to the
executing process via internal pipes).

What are the values you typically observe ? maybe the warning is jst
about a slow context switching on your server (btw, how many cores ?)."

For what it's worth I've been seeing these in production for a long time
and they seem harmless. It was on my list to speak to people about at the
Summit but looks like I'll have to wait until September! We're running quad
core VM's.



On Tue, 31 Mar 2020 at 18:44, Saint Michael  wrote:

> Does anybody have any idea what causes this error?
> I am pulling my hair.
>
> ps[1883]: Mar 31 17:10:49 [1903] WARNING:core:utimer_ticker: utimer task
>  already scheduled for 190 ms (now 890 ms), it may overlap..
> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1903]
> WARNING:core:utimer_ticker: utimer task  already scheduled for
> 190 ms (now 990 ms), it may overlap..
> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1903]
> WARNING:core:utimer_ticker: utimer task  already scheduled for
> 190 ms (now 1090 ms), it may overlap..
> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1961]
> WARNING:core:handle_timer_job: utimer job  has a 97 us delay
> in execution
> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1955]
> WARNING:core:handle_timer_job: utimer job  has a 97 us delay
> in execution
> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1961]
> WARNING:core:handle_timer_job: timer job  has a 17 us delay
> in execution
> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1930]
> WARNING:core:handle_timer_job: utimer job  has a 97 us delay
> in execution
> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1980]
> WARNING:core:handle_timer_job: timer job  has a 17 us delay
> in execution
> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1971]
> WARNING:core:handle_timer_job: timer job  has a 17 us delay
> in execution
> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1951]
> WARNING:core:handle_timer_job: utimer job  has a 97 us delay
> in execution
> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1928]
> WARNING:core:handle_timer_job: timer job  has a 17 us delay
> in execution
> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1914]
> WARNING:core:handle_timer_job: timer job  has a 17 us delay
> in execution
> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1961]
> WARNING:core:handle_timer_job: timer job  has a 17 us
> delay in execution
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

-- 


 


*0333 
332   |  x-on.co.uk   |   ** 
    
   **  |  Coronavirus 
*


THE 
ITSPA AWARDS 2020  AND Best ITSP - 
Mid Market, Best Software and Best Vertical Solution are trade marks of the 
Internet Telephony Services Providers' Association, used under licence.


X-on
is a trading name of Storacall Technology Ltd a limited company 
registered in
England and Wales.

Registered Office : Avaland House, 110 
London Road, Apsley, Hemel Hempstead,
Herts, HP3 9SD. Company Registration 
No. 2578478.

The information in this e-mail is confidential and for use by 
the addressee(s)
only. If you are not the intended recipient, please notify 
X-on immediately on +44(0)333 332  and delete the
message from your 
computer. If you are not a named addressee you must not use,
disclose, 
disseminate, distribute, copy, print or reply to this email. Views
or 
opinions expressed by an individual
within this email may not necessarily

reflect the views of X-on or its associated companies. Although X-on 
routinely
screens for viruses, addressees should scan this email and any 
attachments
for
viruses. X-on makes no representation or warranty as to the 
absence of viruses
in this email or any attachments.










___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Errors

2020-03-31 Thread Saint Michael 
Does anybody have any idea what causes this error?
I am pulling my hair.

ps[1883]: Mar 31 17:10:49 [1903] WARNING:core:utimer_ticker: utimer task
 already scheduled for 190 ms (now 890 ms), it may overlap..
Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1903]
WARNING:core:utimer_ticker: utimer task  already scheduled for
190 ms (now 990 ms), it may overlap..
Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1903]
WARNING:core:utimer_ticker: utimer task  already scheduled for
190 ms (now 1090 ms), it may overlap..
Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1961]
WARNING:core:handle_timer_job: utimer job  has a 97 us delay
in execution
Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1955]
WARNING:core:handle_timer_job: utimer job  has a 97 us delay
in execution
Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1961]
WARNING:core:handle_timer_job: timer job  has a 17 us delay
in execution
Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1930]
WARNING:core:handle_timer_job: utimer job  has a 97 us delay
in execution
Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1980]
WARNING:core:handle_timer_job: timer job  has a 17 us delay
in execution
Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1971]
WARNING:core:handle_timer_job: timer job  has a 17 us delay
in execution
Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1951]
WARNING:core:handle_timer_job: utimer job  has a 97 us delay
in execution
Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1928]
WARNING:core:handle_timer_job: timer job  has a 17 us delay
in execution
Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1914]
WARNING:core:handle_timer_job: timer job  has a 17 us delay
in execution
Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1961]
WARNING:core:handle_timer_job: timer job  has a 17 us
delay in execution
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] trouble migrating from 3.0 to 3.1 with drouting.

2020-03-31 Thread johan 

Hi guys when I call do_routing in opensips 3.1. I have :

Mar 31 16:52:25 hendrix /data/opensips/sbin/opensips[20886]: 
callid=hxj~vmgW54: route[drouting]: let's find the group for drouting 
based on fU 33757936420
Mar 31 16:52:25 hendrix /data/opensips/sbin/opensips[20886]: 
DBG:core:pv_printf: final buffer length 102
Mar 31 16:52:25 hendrix /data/opensips/sbin/opensips[20886]: 
callid=hxj~vmgW54: route[drouting]: fU 33757936420 does not start with 
32460, we put var(group) 1 to 1


Mar 31 16:52:25 hendrix /data/opensips/sbin/opensips[20886]: 
DBG:drouting:do_routing: empty routing table
Mar 31 16:52:25 hendrix /data/opensips/sbin/opensips[20886]: 
DBG:core:pv_printf: final buffer length 51
Mar 31 16:52:25 hendrix /data/opensips/sbin/opensips[20886]: 
callid=hxj~vmgW54: route[drouting]: drouting failed



script part :

    xlog("callid=$ci: route[drouting]: let's find the group for 
drouting based on fU $fU");

    $var(group)="";
    if($fU=~"32460.*")
    {
    $var(group)=2;
    xlog("callid=$ci: route[drouting]: fU $fU starts with 32460, we 
put var(group) $var(group) to 2");

    }
    else
    {
    $var(group)=1;
    xlog("callid=$ci: route[drouting]: fU $fU does not start with 
32460, we put var(group) $var(group) to 1");

    }
    if(!do_routing($(var(group){s.int}),,,$var(rule),$var(gw)))
    {
    xlog("callid=$ci: route[drouting]: drouting failed");
    sl_send_reply(500,"no routes!!!");
    exit;
    }



olddb :

select * from dr_rules;
++-++-+--+-+++-+
| ruleid | groupid | prefix | timerec | priority | routeid | gwlist | 
attrs  | description |

++-++-+--+-+++-+
|  4 | 1   |    | |    0 | | 32 | 
BICS   | |
|  7 | 2   |    | |    0 | | 32460  | 
Belgian mobile | |

++-++-+--+-+++-+

select * from dr_rules;
++-++-+--+-+++-+
| ruleid | groupid | prefix | timerec | priority | routeid | gwlist | 
attrs  | description |

++-++-+--+-+++-+
|  4 | 1   |    | |    0 | | 32 | A 
   | |
|  7 | 2   |    | |    0 | | 32460  | B  
| |

++-++-+--+-+++-+
2 rows in set (0.01 sec)
lect * from dr_gateways
    -> ;
++---+--+--+---++---++---++--+
| id | gwid  | type | address  | strip | pri_prefix | attrs 
| probe_mode | state | socket | description  |

++---+--+--+---++---++---++--+
|  1 | 32    |    2 | 192.168.174.251:5060 | 0 | |   |  
0 | 0 |    | A |
|  5 | -1    |    1 | 192.168.174.254:5060 | 1 | |   |  
0 | 0 |    | Inbound from B   |
|  7 | 32460 |    1 | 192.168.174.253:5060 | 0 | |   |  
0 | 0 |    | C|

++---+--+--+---++---++---++--+
3 rows in set (0.00 sec)

select * from dr_groups;
++--++-+--+
| id | username | domain | groupid | 
description  |

++--++-+--+
|  3 | 1    | abcc|   1 | Default group for |
|  5 | 1    | yourdomain.net |   2 | BICS 
mobile  |

++--++-+--+
2 rows in set (0.00 sec)

new db :

dr_rules;
++-++-+--+-++--+--++-+
| ruleid | groupid | prefix | timerec | priority | routeid | gwlist | 
sort_alg | sort_profile | attrs  | description |

++-++-+--+-++--+--++-+
|  4 | 1   |    | |    0 | | 32 | 
N    |    0 | A   | |
|  7 | 2   |    | |    0 | | 32460  | 
N    |    0 | B  | |

++-++-+--+-++--+--++-+

Re: [OpenSIPS-Users] telephone-event rtpmap value

2020-03-31 Thread solarmon 
Hi,

Yes, the client is broken. It advertises RFC2833 in the SDP but does not
send and RTP Events for the DTMF tones and just sends it inband, and the
other end does not like it (it doesn't for some reason fall back to inband
DTMF).

The workaround I have used is to remove the RFC2833 bits in the SDP packet
by using the replace_body() function.

Thank you.

On Tue, 31 Mar 2020 at 13:23, Răzvan Crainea  wrote:

> This sounds a bit broken: if the client advertises the payload type of
> 96, thats what it will have in the generated RTP packets, so I don't
> really see a valid reason for doing that. Unless the client is really
> broken and advertises a ptype of 96, but sends the packets using 101.
>
> Anyhow, in order to do that, you can use the subst_body() function in
> the textops module:
> https://opensips.org/docs/modules/2.4.x/textops.html#func_subst_body
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
>
> On 3/27/20 4:43 PM, solarmon wrote:
> > Hi,
> >
> > I have an opensips 2.4 cluster using rtpproxy nodes.
> >
> > I'm troubleshooting some DTMF issue and have a requirement to change the
> > inbound INVITE SDP payload from:
> >
> > a=rtpmap:96 telephone-event/8000
> >
> > to
> >
> > a=rtpmap:101 telephone-event/8000
> >
> > in the outbound INVITE SDP.
> >
> > How could this mapping/conversion be achieved with my opensips/rtpproxy
> > setup?
> >
> > Thank you!
> >
> > ___
> > 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

Re: [OpenSIPS-Users] feature request

2020-03-31 Thread volga629 via Users 

  
  
Hello Răzvan,
Thank you. I added to the list.
volga629


On 3/31/20 9:23 AM, Răzvan Crainea
  wrote:

Hi,
  Volga!
  
  
  This looks like a valid feature request.
  
  Please open this feature request on our tracker[1], so we can keep
  track of them easier.
  
  
  [1] https://github.com/OpenSIPS/opensips/issues
  
  
  Best regards,
  
  
  Răzvan Crainea
  
  OpenSIPS Core Developer
  
  http://www.opensips-solutions.com
  
  
  On 3/30/20 1:31 PM, volga629 via Users wrote:
  
  Hello Everyone,


I would like request add rfc3994 to presence modules that allow
use of application/im-iscomposing+xml.



https://www.ietf.org/rfc/rfc3994.txt



Any opinion welcome.


volga629



___

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

Re: [OpenSIPS-Users] How to get the name-addr within a From header?

2020-03-31 Thread Răzvan Crainea 

Hi, Gordon!

name-addr is basically the entire header, and you can access it using 
$hdr(From).
However, it looks like you are looking to get the From header username, 
that, as Grant pointed out, is returned by the $fU variable. Does this 
solve your problem?


Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 3/31/20 1:36 PM, Gordon Yeong wrote:

Hello Grant, thank you
  I was thinking of writing a perl module for this if i still cant do it.
I will try tomorrow :)

Regards,
Gordon Yeong


On Tue, 31 Mar 2020 at 21:20, Grant Bagdasarian 
mailto:grantbagdasar...@gmail.com>> wrote:


Hi Gordon,

I believe you’re looking for the username in the From header.
It’s the $fU variable.

https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc47

That should give you 12345688.

On Tue, 31 Mar 2020 at 08:56 Gordon Yeong mailto:anexi...@gmail.com>> wrote:

Hi guys,


I looked up RFC 3261 . and
the from-spec (page 229) says:

from-spec   =  ( name-addr / addr-spec )
*( SEMI from-param )


I have the following FROM tag in a SIP header.
"Mr Invite-R-Us http://sip:12345688@192.168.136.134:5060>>;tag=784"

In my opensips.cfg, I got the following results using the
compact forms, m and f

$var(CALLING2)=$hdr(m); --> printed
out 
$var(CALLING3)=$hdr(f);  --> printed out Mr Invite-R-Us
http://sip:12345688@192.168.136.134:5060>>;tag=784


I have looked through the RFC document again but could not find 
how one could get the "name-addr" (ie. " 12345688"). I have also

looked through the Opensips Core variable documentation.


Can anyone please tell me how to get the name-addr within a From
header? What is the attribute name or compact form?


Thank you

Gordon
___
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



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] feature request

2020-03-31 Thread Răzvan Crainea 

Hi, Volga!

This looks like a valid feature request.
Please open this feature request on our tracker[1], so we can keep track 
of them easier.


[1] https://github.com/OpenSIPS/opensips/issues

Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 3/30/20 1:31 PM, volga629 via Users wrote:

Hello Everyone,

I would like request add rfc3994 to presence modules that allow use of 
application/im-iscomposing+xml.



https://www.ietf.org/rfc/rfc3994.txt


Any opinion welcome.

volga629


___
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

Re: [OpenSIPS-Users] telephone-event rtpmap value

2020-03-31 Thread Răzvan Crainea 
This sounds a bit broken: if the client advertises the payload type of 
96, thats what it will have in the generated RTP packets, so I don't 
really see a valid reason for doing that. Unless the client is really 
broken and advertises a ptype of 96, but sends the packets using 101.


Anyhow, in order to do that, you can use the subst_body() function in 
the textops module:

https://opensips.org/docs/modules/2.4.x/textops.html#func_subst_body

Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 3/27/20 4:43 PM, solarmon wrote:

Hi,

I have an opensips 2.4 cluster using rtpproxy nodes.

I'm troubleshooting some DTMF issue and have a requirement to change the 
inbound INVITE SDP payload from:


a=rtpmap:96 telephone-event/8000

to

a=rtpmap:101 telephone-event/8000

in the outbound INVITE SDP.

How could this mapping/conversion be achieved with my opensips/rtpproxy 
setup?


Thank you!

___
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

Re: [OpenSIPS-Users] How to get the name-addr within a From header?

2020-03-31 Thread Gordon Yeong 
Hello Grant, thank you
 I was thinking of writing a perl module for this if i still cant do it.
I will try tomorrow :)

Regards,
Gordon Yeong


On Tue, 31 Mar 2020 at 21:20, Grant Bagdasarian 
wrote:

> Hi Gordon,
>
> I believe you’re looking for the username in the From header.
> It’s the $fU variable.
>
> https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc47
>
> That should give you 12345688.
>
> On Tue, 31 Mar 2020 at 08:56 Gordon Yeong  wrote:
>
>> Hi guys,
>>
>>
>> I looked up RFC 3261 . and the from-spec
>> (page 229) says:
>>
>> from-spec   =  ( name-addr / addr-spec )
>>*( SEMI from-param )
>>
>>
>> I have the following FROM tag in a SIP header.
>> "Mr Invite-R-Us ;tag=784"
>>
>> In my opensips.cfg, I got the following results using the compact forms,
>> m and f
>>
>> $var(CALLING2)=$hdr(m); --> printed out > ;transport=UDP>
>> $var(CALLING3)=$hdr(f);  --> printed out Mr Invite-R-Us <
>> sip:12345688@192.168.136.134:5060>;tag=784
>>
>>
>> I have looked through the RFC document again but could not find  how one
>> could get the "name-addr" (ie. " 12345688"). I have also looked through the
>> Opensips Core variable documentation.
>>
>>
>> Can anyone please tell me how to get the name-addr within a From header?
>> What is the attribute name or compact form?
>>
>>
>> Thank you
>>
>> Gordon
>> ___
>> 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

Re: [OpenSIPS-Users] How to get the name-addr within a From header?

2020-03-31 Thread Grant Bagdasarian 
Hi Gordon,

I believe you’re looking for the username in the From header.
It’s the $fU variable.

https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc47

That should give you 12345688.

On Tue, 31 Mar 2020 at 08:56 Gordon Yeong  wrote:

> Hi guys,
>
>
> I looked up RFC 3261 . and the from-spec
> (page 229) says:
>
> from-spec   =  ( name-addr / addr-spec )
>*( SEMI from-param )
>
>
> I have the following FROM tag in a SIP header.
> "Mr Invite-R-Us ;tag=784"
>
> In my opensips.cfg, I got the following results using the compact forms,
> m and f
>
> $var(CALLING2)=$hdr(m); --> printed out  ;transport=UDP>
> $var(CALLING3)=$hdr(f);  --> printed out Mr Invite-R-Us <
> sip:12345688@192.168.136.134:5060>;tag=784
>
>
> I have looked through the RFC document again but could not find  how one
> could get the "name-addr" (ie. " 12345688"). I have also looked through the
> Opensips Core variable documentation.
>
>
> Can anyone please tell me how to get the name-addr within a From header?
> What is the attribute name or compact form?
>
>
> Thank you
>
> Gordon
> ___
> 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

Re: [OpenSIPS-Users] help on failover routing

2020-03-31 Thread Giovanni Maruzzelli 
Liviu,

while you are at it (feature deleting record if TLS connection is down), do
it for wss too :))




On Fri, Mar 20, 2020 at 2:06 PM johan  wrote:

> as for point 3, I will check.
>
>
> On 20/03/2020 11:43, Liviu Chircu wrote:
> > On 20.03.2020 12:37, johan wrote:
> >>
> >> Hence,
> >>
> >> - when the softphone is registered, a call comes on that DID in udp
> >> (we do lookup_location) and we send it to the user in tls (this works)
> >>
> >> - when the softphone is off for a long time, there is no record in
> >> location so then I route the call via the provider to his real mobile
> >> number (this works also)
> >>
> >> - the problem is when the mobile looses his dataconnection, then I do
> >> have a record in location, I try to send the call, which will fail.
> >> Upon failure, I drop the record in subscriber. And here the problem
> >> begins.
> >>
> >> The invite is adapted at this point already for tls => provider
> >> doesn't want it as he is udp.
> >>
> >>
> >> So how can I have the original request back for routing to the real
> >> mobile number ? Or how can I check if the user is still connected
> >> (aka how can I send options to see if he's alive) before calling
> >> t_relay.
> >
> > Hi, Johan!
> >
> > 1.  this solution of calling remove() after a routing failure is
> > nice.  Alexey Vasilyev put together a feature request [1] related to
> > this problem, where he asks for an automated mechanism of deleting a
> > contact whenever its TLS connection is found to be dead.
> >
> > 2.  Did you try to force the sending socket of the INVITE ($fs
> > variable) to your "udp:1.2.3.4:5060" listener?  I think this should
> > work inside a failure_route and should properly route to your provider
> > via UDP.  Also, I believe Bogdan fixed this recently [2] (but master
> > branch only?!), such that "$fs" is not set to the TLS listener inside
> > failure_route - might wanna check.
> >
> > 3.  As a long-term solution to this problem, we are working on adding
> > RFC 8599 Push Notification support via SIP in OpenSIPS 3.1.  The spec
> > is still rather new, but I'm curious if your app's SIP stack supports
> > it :)  Basically, this will allow you to wake up the phone so it
> > re-registers whenever you need to deliver an INVITE to it, in a
> > standards-approved way.
> >
> > Best regards,
> >
> > [1]: https://github.com/OpenSIPS/opensips/issues/1769
> >
> > [2]: https://github.com/OpenSIPS/opensips/commit/f73abff9
> >
> > [3]: https://tools.ietf.org/html/rfc8599
> >
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Sincerely,

Giovanni Maruzzelli
OpenTelecom.IT
cell: +39 347 266 56 18
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] msteams outgoing calls fail

2020-03-31 Thread Pasan Meemaduma via Users 
Hi Alexey,
Legend !, Thanks for pointing that out. It did fixed the issue.
Thank you again :)
Regards,Pasan

   Distinguishing What && How ! 

On Tuesday, 31 March 2020, 1:06:00 pm GMT+5:30, Alexey Vasilyev 
 wrote:  
 
 Please forward requests to Asterisk with simple record_route().

Only to MS Teams you should use preset with domain name.



-
---
Alexey Vasilyev
--
Sent from: 
http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html

___
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

Re: [OpenSIPS-Users] msteams outgoing calls fail

2020-03-31 Thread Alexey Vasilyev 
Please forward requests to Asterisk with simple record_route().

Only to MS Teams you should use preset with domain name.



-
---
Alexey Vasilyev
--
Sent from: 
http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users