problem in dialplan

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

problem in dialplan

Johan De Clercq

Hi,

Using latest opensips 3.0,  there seems to be a problem in dialplan

 

  1 09:23:25 hendrix /data/opensips/sbin/opensips[4197]: ERROR:core:get_cmd_fixups: Variable in param [1] is not an integer

Jul  1 09:23:25 hendrix /data/opensips/sbin/opensips[4197]: ERROR:core:do_action: Failed to get fixups for command <dp_translate>

 

This the code :

    if (dp_translate(1,"$ruri.user/$var(rU)"))

    {

        xlog("callid=$ci: Route[normalizeforinbound]: we dropped 0,00,+ from $rU, result is var(rU) $var(rU)");

    }

 

cid:F3100D46-F00D-4610-87ED-3E91DA790A82

Johan De Clercq, Managing Director
Democon bvba - Ooigemstraat 41 - 8780 Oostrozebeke

Tel +3256980990 – GSM +32478720104

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: problem in dialplan

Johan De Clercq

In addition, when I use $var(i) I have more output

 

Jul  1 09:32:39 hendrix /data/opensips/sbin/opensips[4593]: DBG:dialplan:dp_translate_f: dpid is 1 partition is default

Jul  1 09:32:39 hendrix /data/opensips/sbin/opensips[4593]: DBG:dialplan:dp_translate_f: input is +32478720101/

Jul  1 09:32:39 hendrix /data/opensips/sbin/opensips[4593]: DBG:dialplan:dp_translate_f: no information available for dpid 1

Jul  1 09:32:39 hendrix /data/opensips/sbin/opensips[4593]: callid=bmWolfo6-vYkkNdSG0sYBA..: Route[normalizeforinbound]: dp_translate failed!, we drop the call

 

When I look into the db :

 

MySQL [test]> select * from dialplan;

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

| id | dpid | pr | match_op | match_exp    | match_flags | subst_exp      | repl_exp | timerec | disabled | attrs |

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

|  4 |    1 |  1 |        1 | ^(00|\+|0).* |           0 | ^(00|\+|0)(.*) | \2       | NULL    |        0 |       |

|  5 |   33 |  1 |        1 | ^(0).*       |           1 | ^(0)(.*)       | 33\2     | NULL    |        0 |       |

|  6 |   33 |  1 |        1 | ^(00|\+).*   |           1 | ^(00|\+)(.*)   |  \2      | NULL    |        0 |       |

| 11 |   32 |  1 |        1 | ^(00|\+).*   |           1 | ^(00|\+)(.*)   | \2       | NULL    |        0 |       |

| 13 |   32 |  1 |        1 | ^(0).* 1     |           1 | ^(0)(.*)       | 32\2     | NULL    |        0 |       |

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

 

So there are 2 problems :

  • Dp_translate when the first parameter is an integer the function does not terminate normally.
  • Please explain the error above.

BR,

 

 

From: johan de clercq <[hidden email]>
Sent: Monday, July 1, 2019 11:28 AM
To: 'OpenSIPS users mailling list' <[hidden email]>
Subject: problem in dialplan

 

Hi,

Using latest opensips 3.0,  there seems to be a problem in dialplan

 

  1 09:23:25 hendrix /data/opensips/sbin/opensips[4197]: ERROR:core:get_cmd_fixups: Variable in param [1] is not an integer

Jul  1 09:23:25 hendrix /data/opensips/sbin/opensips[4197]: ERROR:core:do_action: Failed to get fixups for command <dp_translate>

 

This the code :

    if (dp_translate(1,"$ruri.user/$var(rU)"))

    {

        xlog("callid=$ci: Route[normalizeforinbound]: we dropped 0,00,+ from $rU, result is var(rU) $var(rU)");

    }

 

cid:F3100D46-F00D-4610-87ED-3E91DA790A82

Johan De Clercq, Managing Director
Democon bvba - Ooigemstraat 41 - 8780 Oostrozebeke

Tel +3256980990 – GSM +32478720104

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: problem in dialplan

Richard Revels
In reply to this post by Johan De Clercq
Try enclosing the 1 in quotes

dp_translate("1","$ruri.user/$var(rU)")

 

BandwidthMaroon.png

 

Richard Revels    System Architect II

900 Main Campus Drive, Suite 100, Raleigh, NC 27606

 

m: 919-578-3421    o: 919-727-4614

e: [hidden email]



On Mon, Jul 1, 2019 at 5:28 AM johan de clercq <[hidden email]> wrote:

Hi,

Using latest opensips 3.0,  there seems to be a problem in dialplan

 

  1 09:23:25 hendrix /data/opensips/sbin/opensips[4197]: ERROR:core:get_cmd_fixups: Variable in param [1] is not an integer

Jul  1 09:23:25 hendrix /data/opensips/sbin/opensips[4197]: ERROR:core:do_action: Failed to get fixups for command <dp_translate>

 

This the code :

    if (dp_translate(1,"$ruri.user/$var(rU)"))

    {

        xlog("callid=$ci: Route[normalizeforinbound]: we dropped 0,00,+ from $rU, result is var(rU) $var(rU)");

    }

 

cid:F3100D46-F00D-4610-87ED-3E91DA790A82

Johan De Clercq, Managing Director
Democon bvba - Ooigemstraat 41 - 8780 Oostrozebeke

Tel +3256980990 – GSM +32478720104

 

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: problem in dialplan

Johan De Clercq
In reply to this post by Johan De Clercq

Hello,

Is there any update on this blocking issue for my 3.0 rollout ?

 

BR,

 

From: johan de clercq <[hidden email]>
Sent: Monday, July 1, 2019 11:37 AM
To: 'OpenSIPS users mailling list' <[hidden email]>
Subject: RE: problem in dialplan

 

In addition, when I use $var(i) I have more output

 

Jul  1 09:32:39 hendrix /data/opensips/sbin/opensips[4593]: DBG:dialplan:dp_translate_f: dpid is 1 partition is default

Jul  1 09:32:39 hendrix /data/opensips/sbin/opensips[4593]: DBG:dialplan:dp_translate_f: input is +32478720101/

Jul  1 09:32:39 hendrix /data/opensips/sbin/opensips[4593]: DBG:dialplan:dp_translate_f: no information available for dpid 1

Jul  1 09:32:39 hendrix /data/opensips/sbin/opensips[4593]: callid=bmWolfo6-vYkkNdSG0sYBA..: Route[normalizeforinbound]: dp_translate failed!, we drop the call

 

When I look into the db :

 

MySQL [test]> select * from dialplan;

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

| id | dpid | pr | match_op | match_exp    | match_flags | subst_exp      | repl_exp | timerec | disabled | attrs |

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

|  4 |    1 |  1 |        1 | ^(00|\+|0).* |           0 | ^(00|\+|0)(.*) | \2       | NULL    |        0 |       |

|  5 |   33 |  1 |        1 | ^(0).*       |           1 | ^(0)(.*)       | 33\2     | NULL    |        0 |       |

|  6 |   33 |  1 |        1 | ^(00|\+).*   |           1 | ^(00|\+)(.*)   |  \2      | NULL    |        0 |       |

| 11 |   32 |  1 |        1 | ^(00|\+).*   |           1 | ^(00|\+)(.*)   | \2       | NULL    |        0 |       |

| 13 |   32 |  1 |        1 | ^(0).* 1     |           1 | ^(0)(.*)       | 32\2     | NULL    |        0 |       |

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

 

So there are 2 problems :

  • Dp_translate when the first parameter is an integer the function does not terminate normally.
  • Please explain the error above.

BR,

 

 

From: johan de clercq <[hidden email]>
Sent: Monday, July 1, 2019 11:28 AM
To: 'OpenSIPS users mailling list' <[hidden email]>
Subject: problem in dialplan

 

Hi,

Using latest opensips 3.0,  there seems to be a problem in dialplan

 

  1 09:23:25 hendrix /data/opensips/sbin/opensips[4197]: ERROR:core:get_cmd_fixups: Variable in param [1] is not an integer

Jul  1 09:23:25 hendrix /data/opensips/sbin/opensips[4197]: ERROR:core:do_action: Failed to get fixups for command <dp_translate>

 

This the code :

    if (dp_translate(1,"$ruri.user/$var(rU)"))

    {

        xlog("callid=$ci: Route[normalizeforinbound]: we dropped 0,00,+ from $rU, result is var(rU) $var(rU)");

    }

 

cid:F3100D46-F00D-4610-87ED-3E91DA790A82

Johan De Clercq, Managing Director
Democon bvba - Ooigemstraat 41 - 8780 Oostrozebeke

Tel +3256980990 – GSM +32478720104

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: problem in dialplan

Liviu Chircu

Hi Johan,

I was not able to reproduce your startup issue on latest 3.0, regardless if using partitions or not.

Can you provide a minimal opensips.cfg file that exhibits the issue?

Best regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 02.07.2019 15:09, johan de clercq wrote:

Hello,

Is there any update on this blocking issue for my 3.0 rollout ?

 

BR,

 

From: johan de clercq [hidden email]
Sent: Monday, July 1, 2019 11:37 AM
To: 'OpenSIPS users mailling list' [hidden email]
Subject: RE: problem in dialplan

 

In addition, when I use $var(i) I have more output

 

Jul  1 09:32:39 hendrix /data/opensips/sbin/opensips[4593]: DBG:dialplan:dp_translate_f: dpid is 1 partition is default

Jul  1 09:32:39 hendrix /data/opensips/sbin/opensips[4593]: DBG:dialplan:dp_translate_f: input is +32478720101/

Jul  1 09:32:39 hendrix /data/opensips/sbin/opensips[4593]: DBG:dialplan:dp_translate_f: no information available for dpid 1

Jul  1 09:32:39 hendrix /data/opensips/sbin/opensips[4593]: callid=bmWolfo6-vYkkNdSG0sYBA..: Route[normalizeforinbound]: dp_translate failed!, we drop the call

 

When I look into the db :

 

MySQL [test]> select * from dialplan;

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

| id | dpid | pr | match_op | match_exp    | match_flags | subst_exp      | repl_exp | timerec | disabled | attrs |

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

|  4 |    1 |  1 |        1 | ^(00|\+|0).* |           0 | ^(00|\+|0)(.*) | \2       | NULL    |        0 |       |

|  5 |   33 |  1 |        1 | ^(0).*       |           1 | ^(0)(.*)       | 33\2     | NULL    |        0 |       |

|  6 |   33 |  1 |        1 | ^(00|\+).*   |           1 | ^(00|\+)(.*)   |  \2      | NULL    |        0 |       |

| 11 |   32 |  1 |        1 | ^(00|\+).*   |           1 | ^(00|\+)(.*)   | \2       | NULL    |        0 |       |

| 13 |   32 |  1 |        1 | ^(0).* 1     |           1 | ^(0)(.*)       | 32\2     | NULL    |        0 |       |

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

 

So there are 2 problems :

  • Dp_translate when the first parameter is an integer the function does not terminate normally.
  • Please explain the error above.

BR,

 

 

From: johan de clercq <[hidden email]>
Sent: Monday, July 1, 2019 11:28 AM
To: 'OpenSIPS users mailling list' <[hidden email]>
Subject: problem in dialplan

 

Hi,

Using latest opensips 3.0,  there seems to be a problem in dialplan

 

  1 09:23:25 hendrix /data/opensips/sbin/opensips[4197]: ERROR:core:get_cmd_fixups: Variable in param [1] is not an integer

Jul  1 09:23:25 hendrix /data/opensips/sbin/opensips[4197]: ERROR:core:do_action: Failed to get fixups for command <dp_translate>

 

This the code :

    if (dp_translate(1,"$ruri.user/$var(rU)"))

    {

        xlog("callid=$ci: Route[normalizeforinbound]: we dropped 0,00,+ from $rU, result is var(rU) $var(rU)");

    }

 

cid:F3100D46-F00D-4610-87ED-3E91DA790A82

Johan De Clercq, Managing Director
Democon bvba - Ooigemstraat 41 - 8780 Oostrozebeke

Tel +3256980990 – GSM +32478720104

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: problem in dialplan

Johan De Clercq

I fixed it by adding sleep 10 in the init script as attached on line 104.

 

#! /bin/sh

#

### BEGIN INIT INFO

# Provides:          opensips

# Required-Start:    $syslog $network $local_fs $time $remote_fs

# Required-Stop:     $syslog $network $local_fs $remote_fs

# Default-Start:     2 3 4 5

# Default-Stop:      0 1 6

# Short-Description: Start the OpenSIPS SIP server

# Description:       Start the OpenSIPS SIP server

### END INIT INFO

#

# TODO:

# The following fields should be added (and completed):

# Should-Start:      postgresql mysql radius

# Should-Stop:       postgresql mysql radius

 

set -e

 

PATH=/sbin:/bin:/usr/sbin:/usr/bin

DAEMON=/data/opensips/sbin/opensips

NAME=opensips

DESC=opensips

CFGFILE=/data/opensips/etc/opensips/opensips.cfg

M4CFGFILE=/etc/opensips/opensips.m4

M4ARCHIVEDIR=/etc/opensips/archive

HOMEDIR=/var/run/opensips

PIDFILE=$HOMEDIR/$NAME.pid

DEFAULTS=/etc/default/opensips

RUN_OPENSIPS=yes

 

[ -e "/lib/lsb/init-functions" ] && . /lib/lsb/init-functions

test -f $DAEMON || exit 0

 

# Load startup options if available

if [ -f $DEFAULTS ]; then

   . $DEFAULTS || true

fi

 

 

check_opensips_config ()

{

        # Check if opensips configuration is valid before starting the server

        set +e

        out=$($DAEMON -c -f $CFGFILE 2>&1 > /dev/null)

        retcode=$?

        set -e

        if [ "$retcode" != '0' ]; then

            echo "Not starting $DESC: invalid configuration file!"

            echo -e "\n$out\n"

            exit 1

        fi

}

 

create_radius_seqfile ()

{

    # Create a radius sequence file to be used by the radius client if

    # radius accounting is enabled. This is needed to avoid any issue

    # with the file not being writable if opensips first starts as user

    # root because DUMP_CORE is enabled and creates this file as user

    # root and then later it switches back to user opensips and cannot

    # write to the file. If the file exists before opensips starts, it

    # won't change it's ownership and will be writable for both root

    # and opensips, no matter what options are chosen at install time

    RADIUS_SEQ_FILE=/var/run/opensips/opensips_radius.seq

    if [ -d /var/run/opensips ]; then

        chown ${USER}:${GROUP} /var/run/opensips

 

        if [ ! -f $RADIUS_SEQ_FILE ]; then

            touch $RADIUS_SEQ_FILE

        fi

 

        chown ${USER}:${GROUP} $RADIUS_SEQ_FILE

        chmod 660 $RADIUS_SEQ_FILE

    fi

}

 

 

S_MEMORY=$((`echo $S_MEMORY | sed -e 's/[^0-9]//g'`))

P_MEMORY=$((`echo $P_MEMORY | sed -e 's/[^0-9]//g'`))

[ -z "$USER" ]  && USER=opensips

[ -z "$GROUP" ] && GROUP=opensips

[ $S_MEMORY -le 0 ] && S_MEMORY=32

[ $P_MEMORY -le 0 ] && P_MEMORY=32

 

if test "$DUMP_CORE" = "yes" ; then

    # set proper ulimit

    ulimit -c unlimited

   

    # directory for the core dump files

    # COREDIR=/home/corefiles

    # [ -d $COREDIR ] || mkdir $COREDIR

    # chmod 777 $COREDIR

    # echo "$COREDIR/core.%e.sig%s.%p" > /proc/sys/kernel/core_pattern

fi

 

OPTIONS="-P $PIDFILE -m $S_MEMORY -M $P_MEMORY -u $USER -g $GROUP -f $CFGFILE"

 

case "$1" in

  start)

        check_opensips_config

        create_radius_seqfile

 

        sleep 10

 

        # dirs under /var/run will go away on reboot.

        mkdir -p "$HOMEDIR"

        chmod 775 "$HOMEDIR"

        chown "$USER:$GROUP" "$HOMEDIR" >/dev/null 2>&1 || true

 

        # Generate config from M4

        if [ -f $M4CFGFILE ]; then

                m4 -Q $M4CFGFILE >$CFGFILE.tmp

                if [ $? != 0 ]; then

                        echo "Cannot process m4 macro"

                        rm "$CFGFILE.tmp"

                        exit 1

                fi

 

                [ -e $CFGFILE ] || touch $CFGFILE

 

                # compare configs

                if [ `md5sum $CFGFILE|awk '{print $1}'` != `md5sum $CFGFILE.tmp|awk '{print $1}'` ]; then

                        mkdir -p "$M4ARCHIVEDIR"

                        mv "$CFGFILE" "$M4ARCHIVEDIR/$NAME.cfg-`date +%Y%m%d_%H%M%S`"

                fi

 

 

                mv "$CFGFILE.tmp" "$CFGFILE"

                chown $USER:$GROUP $CFGFILE

                chmod 640 $CFGFILE

        fi

 

        log_daemon_msg "Starting $DESC" "$NAME"

        start-stop-daemon --start --quiet --pidfile $PIDFILE \

                --exec $DAEMON -- $OPTIONS || echo -n " already running"

        log_end_msg $?

        ;;

  stop)

        log_daemon_msg "Stopping $DESC" "$NAME"

        start-stop-daemon --oknodo --stop --quiet --pidfile $PIDFILE \

                --exec $DAEMON

        log_end_msg $?

        ;;

  restart|force-reload)

        check_opensips_config

        create_radius_seqfile

 

        log_daemon_msg "Restarting $DESC" "$NAME"

        start-stop-daemon --oknodo --stop --quiet --pidfile \

                $PIDFILE --exec $DAEMON

        sleep 1

        start-stop-daemon --start --quiet --pidfile \

                $PIDFILE --exec $DAEMON  -- $OPTIONS

        log_end_msg $?

        ;;

  status)

        status_of_proc -p $PIDFILE "$DAEMON" "$NAME"

        ;;

  *)

        N=/etc/init.d/$NAME

        echo "Usage: $N {start|stop|restart|force-reload|status}" >&2

        exit 1

        ;;

esac

 

exit 0

 

From: Users <[hidden email]> On Behalf Of Liviu Chircu
Sent: Tuesday, July 2, 2019 3:11 PM
To: [hidden email]
Subject: Re: [OpenSIPS-Users] problem in dialplan

 

Hi Johan,

I was not able to reproduce your startup issue on latest 3.0, regardless if using partitions or not.

Can you provide a minimal opensips.cfg file that exhibits the issue?

Best regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 02.07.2019 15:09, johan de clercq wrote:

Hello,

Is there any update on this blocking issue for my 3.0 rollout ?

 

BR,

 

From: johan de clercq [hidden email]
Sent: Monday, July 1, 2019 11:37 AM
To: 'OpenSIPS users mailling list' [hidden email]
Subject: RE: problem in dialplan

 

In addition, when I use $var(i) I have more output

 

Jul  1 09:32:39 hendrix /data/opensips/sbin/opensips[4593]: DBG:dialplan:dp_translate_f: dpid is 1 partition is default

Jul  1 09:32:39 hendrix /data/opensips/sbin/opensips[4593]: DBG:dialplan:dp_translate_f: input is +32478720101/

Jul  1 09:32:39 hendrix /data/opensips/sbin/opensips[4593]: DBG:dialplan:dp_translate_f: no information available for dpid 1

Jul  1 09:32:39 hendrix /data/opensips/sbin/opensips[4593]: callid=bmWolfo6-vYkkNdSG0sYBA..: Route[normalizeforinbound]: dp_translate failed!, we drop the call

 

When I look into the db :

 

MySQL [test]> select * from dialplan;

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

| id | dpid | pr | match_op | match_exp    | match_flags | subst_exp      | repl_exp | timerec | disabled | attrs |

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

|  4 |    1 |  1 |        1 | ^(00|\+|0).* |           0 | ^(00|\+|0)(.*) | \2       | NULL    |        0 |       |

|  5 |   33 |  1 |        1 | ^(0).*       |           1 | ^(0)(.*)       | 33\2     | NULL    |        0 |       |

|  6 |   33 |  1 |        1 | ^(00|\+).*   |           1 | ^(00|\+)(.*)   |  \2      | NULL    |        0 |       |

| 11 |   32 |  1 |        1 | ^(00|\+).*   |           1 | ^(00|\+)(.*)   | \2       | NULL    |        0 |       |

| 13 |   32 |  1 |        1 | ^(0).* 1     |           1 | ^(0)(.*)       | 32\2     | NULL    |        0 |       |

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

 

So there are 2 problems :

-          Dp_translate when the first parameter is an integer the function does not terminate normally.

-          Please explain the error above.

BR,

 

 

From: johan de clercq <[hidden email]>
Sent: Monday, July 1, 2019 11:28 AM
To: 'OpenSIPS users mailling list' <[hidden email]>
Subject: problem in dialplan

 

Hi,

Using latest opensips 3.0,  there seems to be a problem in dialplan

 

  1 09:23:25 hendrix /data/opensips/sbin/opensips[4197]: ERROR:core:get_cmd_fixups: Variable in param [1] is not an integer

Jul  1 09:23:25 hendrix /data/opensips/sbin/opensips[4197]: ERROR:core:do_action: Failed to get fixups for command <dp_translate>

 

This the code :

    if (dp_translate(1,"$ruri.user/$var(rU)"))

    {

        xlog("callid=$ci: Route[normalizeforinbound]: we dropped 0,00,+ from $rU, result is var(rU) $var(rU)");

    }

 

cid:F3100D46-F00D-4610-87ED-3E91DA790A82

Johan De Clercq, Managing Director
Democon bvba - Ooigemstraat 41 - 8780 Oostrozebeke

Tel +3256980990 – GSM +32478720104

 



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: problem in dialplan

Liviu Chircu
In reply to this post by Johan De Clercq

Are you sure this is the intended effect?  Notice how that composite parameter of dp_translate()
has been split in two parameters in 3.0 [1].  To me, it looks like you should call:

... dp_translate(1, $ruri.user, $var(rU)) ...

To prevent other such errors with the rest of your script, please go through the 3.0 migration
document [2] and make sure to apply each change that's relevant to your script code.

Best regards,

[1]: https://opensips.org/html/docs/modules/3.0.x/dialplan.html#func_dp_translate
[2]:
https://opensips.org/Documentation/Migration-2-4-0-to-3-0-0

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 02.07.2019 15:09, johan de clercq wrote:

This the code :

    if (dp_translate(1,"$ruri.user/$var(rU)"))

    {

        xlog("callid=$ci: Route[normalizeforinbound]: we dropped 0,00,+ from $rU, result is var(rU) $var(rU)");

    }


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: problem in dialplan

Johan De Clercq

Hang on, that I have changed already:

 

    $var(i)=1;

    if (dp_translate($var(i),"$ruri.user",$var(rU)))

 

The result is identical (sorry 😊).

 

As for the routing:

I do like this

 

Route

{

               ….

    ##initial INVITE

    if (is_method("INVITE") && !has_totag())

    {

        if (is_registered("location"))

        {

            xlog("callid=$ci: Route[0]: the from user is registered, we go to callhandling");

            route(callhandling);

}

 

Route[callhandling]

{

               …

               Route(normalizeforinbound);

               ….

}

 

Route[normalizeforinbound]

{

               …

    $var(i)=1;

    if (dp_translate($var(i),"$ruri.user",$var(rU)))

    {

        xlog("callid=$ci: Route[normalizeforinbound]: we dropped 0,00,+ from $rU, result is var(rU) $var(rU)");

    }

    else

    {

        xlog("callid=$ci: Route[normalizeforinbound]: dp_translate failed!, we drop the call");

        send_reply(404,"Unallocated Number");

        exit;

    }

}

 

BR,

 

 

From: Users <[hidden email]> On Behalf Of Liviu Chircu
Sent: Tuesday, July 2, 2019 6:44 PM
To: OpenSIPS users mailling list <[hidden email]>
Subject: Re: [OpenSIPS-Users] problem in dialplan

 

Are you sure this is the intended effect?  Notice how that composite parameter of dp_translate()
has been split in two parameters in 3.0 [1].  To me, it looks like you should call:

... dp_translate(1, $ruri.user, $var(rU)) ...

To prevent other such errors with the rest of your script, please go through the 3.0 migration
document [2] and make sure to apply each change that's relevant to your script code.

Best regards,

[1]: https://opensips.org/html/docs/modules/3.0.x/dialplan.html#func_dp_translate
[2]: https://opensips.org/Documentation/Migration-2-4-0-to-3-0-0

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 02.07.2019 15:09, johan de clercq wrote:

This the code :

    if (dp_translate(1,"$ruri.user/$var(rU)"))

    {

        xlog("callid=$ci: Route[normalizeforinbound]: we dropped 0,00,+ from $rU, result is var(rU) $var(rU)");

    }


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: problem in dialplan

Liviu Chircu
The issue was cleared off-list.  After a successful startup, it would
take a while
before the dialplan rules would become available, since child
process #1,
responsible for loading the dialplan rules was stuck in
a DNS lookup
while loading the drouting rules.

This behavior was introduced in OpenSIPS 2.4.

As I see it, an added problem is that script writers must now additionally
write opensips.cfg code that
handles the "rules are not yet available"
case while processing SIP traffic.  And I do not recall any support for
distinguishing between "rules not available" and "rule not matched" in any
of the data matching modules.

The question is: is this "post-startup data unavailability" glitch
something worth paying attention to, or is it harmless?  Example affected
modules:
  drouting, dialplan

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 02.07.2019 19:51, johan de clercq wrote:

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: problem in dialplan

Johan De Clercq

Speaking just for myself.

 

As opensips gains traction in production systems, the error when the rules are not loaded should be more clear, now it is : “No information available for dpid “. 

Secondly, this problem/issue is not trivial to find, therefore this should be seen in the logs on very low loglevels (0 or 1).

 

BR,    

 

From: Users <[hidden email]> On Behalf Of Liviu Chircu
Sent: Thursday, July 4, 2019 10:07 AM
To: [hidden email]
Subject: Re: [OpenSIPS-Users] problem in dialplan

 

The issue was cleared off-list.  After a successful startup, it would
take a while before the dialplan rules would become available, since child
process #1, responsible for loading the dialplan rules was stuck in
a DNS lookup while loading the drouting rules.

This behavior was introduced in OpenSIPS 2.4.

As I see it, an added problem is that script writers must now additionally
write opensips.cfg code that handles the "rules are not yet available"
case while processing SIP traffic.  And I do not recall any support for
distinguishing between "rules not available" and "rule not matched" in any
of the data matching modules.

The question is: is this "post-startup data unavailability" glitch
something worth paying attention to, or is it harmless?  Example affected
modules:
  drouting, dialplan

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 02.07.2019 19:51, johan de clercq wrote:



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: problem in dialplan

Richard Revels
We are using dialplan to create some site specific defaults in the startup route.  If this is only encountered on startup I guess changing to an event route would work if an event is generated when the rules become available.  Thank you for surfacing this problem.  It may explain an issue I've been looking at for the last few hours.

 

BandwidthMaroon.png

 

Richard Revels    System Architect II

900 Main Campus Drive, Suite 100, Raleigh, NC 27606

 

m: 919-578-3421    o: 919-727-4614

e: [hidden email]



On Thu, Jul 4, 2019 at 4:21 AM johan de clercq <[hidden email]> wrote:

Speaking just for myself.

 

As opensips gains traction in production systems, the error when the rules are not loaded should be more clear, now it is : “No information available for dpid “. 

Secondly, this problem/issue is not trivial to find, therefore this should be seen in the logs on very low loglevels (0 or 1).

 

BR,    

 

From: Users <[hidden email]> On Behalf Of Liviu Chircu
Sent: Thursday, July 4, 2019 10:07 AM
To: [hidden email]
Subject: Re: [OpenSIPS-Users] problem in dialplan

 

The issue was cleared off-list.  After a successful startup, it would
take a while before the dialplan rules would become available, since child
process #1, responsible for loading the dialplan rules was stuck in
a DNS lookup while loading the drouting rules.

This behavior was introduced in OpenSIPS 2.4.

As I see it, an added problem is that script writers must now additionally
write opensips.cfg code that handles the "rules are not yet available"
case while processing SIP traffic.  And I do not recall any support for
distinguishing between "rules not available" and "rule not matched" in any
of the data matching modules.

The question is: is this "post-startup data unavailability" glitch
something worth paying attention to, or is it harmless?  Example affected
modules:
  drouting, dialplan

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 02.07.2019 19:51, johan de clercq wrote:



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: problem in dialplan

Johan De Clercq

No problem Richard.  It’s not trivial to spot. 

And indeed, using an event route is probably the solution of your problem.

 

From: Users <[hidden email]> On Behalf Of Richard Revels
Sent: Thursday, July 11, 2019 2:58 PM
To: OpenSIPS users mailling list <[hidden email]>
Subject: Re: [OpenSIPS-Users] problem in dialplan

 

We are using dialplan to create some site specific defaults in the startup route.  If this is only encountered on startup I guess changing to an event route would work if an event is generated when the rules become available.  Thank you for surfacing this problem.  It may explain an issue I've been looking at for the last few hours.

 

 

BandwidthMaroon.png

 

Richard Revels    System Architect II

900 Main Campus Drive, Suite 100, Raleigh, NC 27606

 

m: 919-578-3421    o: 919-727-4614

e: [hidden email]

 

 

On Thu, Jul 4, 2019 at 4:21 AM johan de clercq <[hidden email]> wrote:

Speaking just for myself.

 

As opensips gains traction in production systems, the error when the rules are not loaded should be more clear, now it is : “No information available for dpid “. 

Secondly, this problem/issue is not trivial to find, therefore this should be seen in the logs on very low loglevels (0 or 1).

 

BR,    

 

From: Users <[hidden email]> On Behalf Of Liviu Chircu
Sent: Thursday, July 4, 2019 10:07 AM
To: [hidden email]
Subject: Re: [OpenSIPS-Users] problem in dialplan

 

The issue was cleared off-list.  After a successful startup, it would
take a while before the dialplan rules would become available, since child
process #1, responsible for loading the dialplan rules was stuck in
a DNS lookup while loading the drouting rules.

This behavior was introduced in OpenSIPS 2.4.

As I see it, an added problem is that script writers must now additionally
write opensips.cfg code that handles the "rules are not yet available"
case while processing SIP traffic.  And I do not recall any support for
distinguishing between "rules not available" and "rule not matched" in any
of the data matching modules.

The question is: is this "post-startup data unavailability" glitch
something worth paying attention to, or is it harmless?  Example affected
modules:
  drouting, dialplan

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 02.07.2019 19:51, johan de clercq wrote:

 

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users