[OpenSIPS-Users] sippy rtp_cluster usage

2016-10-25 Thread Owais Ahmad
​

Hello,

I am currently using rtpproxy with opensips and need to add more rtpproxies
(hosted on different servers)

I thought to use rtp_cluster as the frontend for multiple rtpproxies.

Although the rtp_cluster socket does respond fine via the rtpproxy command
protocol. And, I get:

INFO:rtpproxy:rtpp_test: rtp proxy  found,
support for it enabled

Here's the error I get on opensips when I switch rtpproxy_sock to the UDP
or UNIX socket of rtp_cluster:

ERR:rtpp_command_pre_parse:GLOBAL: lookup command syntax error: invalid
number of arguments (8)

My config is attached. Has someone used rtp_cluster with opensips? Please
share your experience.

Regards,

Owais


  
Supercluster#1
UNIX
/var/run/rtpcluster.sock




  RTPPROXY1
  UDP
  10.20.30.40:2
  50
  2500
  ACTIVE
  1.2.3.4



  RTPPROXY2
  UNIX
  /var/run/rtpproxy2.sock
  50
  2500
  ACTIVE

  


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


Re: [OpenSIPS-Users] opensips 2.1 call_center queue position

2016-10-25 Thread Jonathan Hunter
Hi Bogdan,


Sorry cant recall If I replied to this.


Is cc_pos available now to extract from the module?


Thats the only thing I need then I can implement call center which I think will 
be much more scale-able than the other approach I am using with FreeSWITCH, I 
would use that just for announcements.


Any response/help appreciated.


Jon



From: Bogdan-Andrei Iancu 
Sent: 13 October 2016 10:59
To: Jonathan Hunter; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position

Hi Jonathan,

No, currently this is not possible. I was trying to envision a solution for 
your need.

But, checking the code, it is really difficult to add the headers to the 
INVITEs originated by OpenSIPS (via the B2BUA), as we need some flexibility 
(different headers to different INVITEs belonging to the same B2B scenario , 
and even more, we need to traverse couple of internal APIs - to propagate the 
hdrs from Call center module all the way to TM).

So, a simpler approach may be to add such extra info as URI params to the RURI. 
Like if you have the RURI 
"sip:queue@192.168.1.10:5060" for the 
queue/waiting playback, the RURI in the INVITE to the media server will look 
like :  
sip:queue@192.168.1.10:5060;cc_eta=40;cc_pos=10
  - cc_eta being the estimated time to wait in seconds and cc_pos the position 
in the queue.

What do you think of this ?

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 12.10.2016 17:21, Jonathan Hunter wrote:
Hi Bogdan,

Yes being able to grab the queue position would be perfect.

Is that possible?

Thanks

Jon


Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position
To: hunter...@hotmail.com; 
users@lists.opensips.org
From: bog...@opensips.org
Date: Wed, 12 Oct 2016 15:42:43 +0300

Hi Jonathan,

When a call is mapped to a flow / queue (before playing the welcome message), 
we know the ETA (estimated time to wait) and when is placed in the queue 
(before playing the queuing) we internally know the position in the queue.

Would it help to have the position in the queue placed into a custome SIP 
header, when sending the INVITE to the message_queue URL ? or to the welcome 
message ?

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 12.10.2016 12:06, Jonathan Hunter wrote:
Hello Bogdan,

Thanks for the response.

In terms of my question, with a number of queuing platforms, they have the 
capability to tell the caller, what position they are in , and when they are 
likely to be answered.

I just wondered if this logic was already within the module, or if I would need 
to use an external code/script to facilitate this function?

As I presume call_center tracks the number of calls currently in a queue ? I 
would then want to be able to extract that information, and if a caller was for 
example in 3rd place in a queue, I could inject the relevant audio from 
freeswitch to tell them their current position?

Does that make sense? :)   Just wanted to know if its something this module can 
do?

Thanks

Jon


Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position
To: users@lists.opensips.org; 
hunter...@hotmail.com
From: bog...@opensips.org
Date: Wed, 12 Oct 2016 11:23:45 +0300

Hello Jon,

The message_queue is a SIP URI pointing to an audio announcement to play to 
roll of the waiting/in-queue playback. This needs to be an announcements that 
never ends (from the perspective of the media server); only the the OpenSIPS 
Queue may terminate the playback, when it decides to take out the call from 
waiting and to deliver it to an agent.

As for your question, I'm not sure I understand what you mean by "inject a 
message with queue position for the caller in question" - could you detail 
please ?

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 11.10.2016 13:36, Jonathan Hunter wrote:
Hi guys,

I have implemented an opensips/freeswitch environment, and I wish to add call 
queues to it, and I like the look of call_center, so just checking this out in 
comparison to mod_callcenter in FS world.

My main question is if using the call_center module if you can inject a message 
with queue position for the caller in question, as I cant see that in 
documentation, I only see message_queue which I assume could be used to report 
the callers position, but just wondered if anyone has done this and if they 
could give me some tips as to if possible?

Many thanks

Jon



___
Users mailing list
Users@li

[OpenSIPS-Users] Opensips 2.1.2 crash using db_virtual

2016-10-25 Thread Jeremiah Penery
Opensips 2.1.2 occasionally crashes when connection to database fails when 
using db_virtual module.  In this case, there is only one backend.
It's a rare problem - usually when the query fails, it doesn't cause a crash.  
But the crash has happened multiple times, on different machines connected to 
different databases.

This query is generated by a timer route that runs every minute.  I'm waiting 
for it to happen again so I can get a core dump file.

The configuration for db_virtual is as follows:

modparam("db_virtual", "db_urls", "define set1 FAILOVER")
modparam("db_virtual", "db_urls", "postgres://xxx:xxx@172.20.20.39:5433/xxx")
modparam("db_virtual", "db_max_consec_retrys", 5)
modparam("db_virtual", "db_probe_time", 10)

And the log:

Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10815]: 
DBG:db_postgres:db_postgres_submit_query: 0x7f054ab9a770 PQsendQuery failed: 
could not rec
eive data from server: Connection timed out#012 Query: select 
ip,grp,mask,port,proto,pattern,context_info,id from opensips_permissions
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10815]: 
DBG:db_postgres:free_query: PQclear(0xce33f0) result set
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10815]: 
ERROR:db_postgres:db_postgres_submit_query: 0x7f054ab9a770 PQsendQuery Error: 
could not re
ceive data from server: Connection timed out#012 Query: select 
ip,grp,mask,port,proto,pattern,context_info,id from opensips_permissions
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10815]: ERROR:core:db_do_query: 
error while submitting query - [select 
ip,grp,mask,port,proto,pattern,context_info,id from opensips_permissions ]
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10815]: 
DBG:db_virtual:db_virtual_query: failover call failed
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10815]: DBG:core:pool_remove: 
removing connection from the pool
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10815]: 
DBG:db_postgres:db_postgres_free_connection: PQfinish(0xcdaf50)
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10815]: 
DBG:db_postgres:db_postgres_free_connection: pkg_free(0x7f054ab9a898)
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10815]: 
DBG:db_virtual:db_virtual_query: curent_con = 0
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10815]: 
DBG:db_virtual:db_virtual_query: flags2 = 2
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10815]: 
DBG:db_virtual:db_virtual_query: curent_con = 0
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10817]: 
NOTICE:core:io_wait_loop_epoll: EPOLLIN(read) event: epollwait() set event 
EPOLLHUP - connection closed by the remote peer!
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10817]: 
DBG:core:handle_tcp_worker: dead tcp worker 6 (pid 10815, no 0) (shutting down?)
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10817]: DBG:core:io_watch_del: 
[TCP_main] io_watch_del op on index 25 32 (0x84b1e0, 32, 25, 0x0,0x1) fd_no=27 
called
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10817]: 
NOTICE:core:io_wait_loop_epoll: EPOLLIN(read) event: epollwait() set event 
EPOLLHUP - connection closed by the remote peer!
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10817]: CRITICAL:core:receive_fd: 
EOF on 35
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10817]: DBG:core:handle_worker: 
dead child 17, pid 10815 (shutting down?)
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10817]: DBG:core:io_watch_del: 
[TCP_main] io_watch_del op on index 17 35 (0x84b1e0, 35, 17, 0x0,0x1) fd_no=26 
called
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10798]: DBG:core:handle_sigs: 
status = 139
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10798]: INFO:core:handle_sigs: 
child process 10815 exited by a signal 11
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10798]: INFO:core:handle_sigs: 
core was generated
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10798]: INFO:core:handle_sigs: 
terminating due to SIGCHLD
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10817]: INFO:core:sig_usr: signal 
15 received
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10816]: INFO:core:sig_usr: signal 
15 received
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10814]: INFO:core:sig_usr: signal 
15 received
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10813]: INFO:core:sig_usr: signal 
15 received
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10812]: INFO:core:sig_usr: signal 
15 received
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10811]: INFO:core:sig_usr: signal 
15 received
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10810]: INFO:core:sig_usr: signal 
15 received
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10809]: INFO:core:sig_usr: signal 
15 received
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10808]: INFO:core:sig_usr: signal 
15 received
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10807]: INFO:core:sig_usr: signal 
15 received
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10806]: INFO:core:sig_usr: signal 
15 received
Oct 24 18:32:10 rst-lab-gw /usr/sbin/opensips[10802]: INFO:core:sig_usr: signal 
15 received
Oct 24 18:32:10 rst-lab-gw /usr/sbin/op

Re: [OpenSIPS-Users] Routing in opensips

2016-10-25 Thread Eric Freeman
The opensips server is 10.88.23.13 the video conference server is 10.89.71.12. 
The IP I am trying to connect to 199.48.152.152, I believe is a valid host. I 
found it on a test SIP site on the Internet


10:02:59.346842 IP 10.89.71.12.sip > 10.88.23.13.sip: SIP: INVITE 
sip:111@199.48.152.152 SIP/2.0

10:02:59.351769 IP 10.88.23.13.sip > 10.89.71.12.sip: SIP: SIP/2.0 100 Giving a 
try

10:02:59.352232 IP 10.88.23.13.sip > sj1-con-01-04.bluejeansnet.com.sip: SIP: 
INVITE sip:111@199.48.152.152 SIP/2.0

10:02:59.352238 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp

10:02:59.871480 IP 10.88.23.13.sip > sj1-con-01-04.bluejeansnet.com.sip: SIP: 
INVITE sip:111@199.48.152.152 SIP/2.0

10:02:59.871489 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp

10:03:00.874461 IP 10.88.23.13.sip > sj1-con-01-04.bluejeansnet.com.sip: SIP: 
INVITE sip:111@199.48.152.152 SIP/2.0

10:03:00.874483 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp

10:03:02.877430 IP 10.88.23.13.sip > sj1-con-01-04.bluejeansnet.com.sip: SIP: 
INVITE sip:111@199.48.152.152 SIP/2.0

10:03:02.877440 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp

10:03:03.930697 IP 10.88.23.13.sip > 10.89.71.12.sip: SIP: SIP/2.0 408 Request 
Timeout

10:03:03.958682 IP 10.89.71.12.sip > 10.88.23.13.sip: SIP: ACK 
sip:111@199.48.152.152 SIP/2.0


Eric Freeman

Technical Director/NA for TBWA\Chiat\Day

TBWA\Chiat\Day New York
488 Madison Ave.
New York NY 10022
United States of America
Tel: +12128041324


From: Bogdan-Andrei Iancu 
Sent: Tuesday, October 25, 2016 7:04:15 AM
To: Eric Freeman; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Routing in opensips

Hi Eric,

By traffic (coming back), you understand RTP or SIP traffic ?

Could you post the INVITE message getting out of your server ? I suspect the 
INVITE has in SDP a private IP that is not reachable for the end device (where 
the call is sent).

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 21.10.2016 18:46, Eric Freeman wrote:

Yes, I see Request INVITE going to the device I am calling. I do not see any 
traffic coming back. I am following up with my Firewall team.

My Firewall team suggested I might need to change the RTP ports to use UDP 
2326-2485. Where do I change/check these settings on the OpenSIPs server to see 
if I have the traffic going out those ports.


Thanks,


Eric Freeman

Technical Director/NA for TBWA\Chiat\Day

TBWA\Chiat\Day New York
488 Madison Ave.
New York NY 10022
United States of America
Tel: +12128041324

From: Bogdan-Andrei Iancu 
Sent: Monday, October 3, 2016 4:44:26 AM
To: Eric Freeman; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Routing in opensips

Hi Eric,

Not the OpenSIPs logs I'm looking for, but the actual SIP packet at network 
level (use ngrep or tcpdump) for the INVITE leaving your OpenSIPS.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 30.09.2016 16:52, Eric Freeman wrote:

Hopefully this is the relevant information you need from the log. I am trying 
to call 111@199.48.152.152. The IP of the opensips 
server si 10.88.23.10 and has a public IP of 204.17.231.3.  The IP address of 
the video conference server is 10.89.71.12.


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_msg: SIP Request:

Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_msg:  method:  

Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_msg:  uri: 


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_msg:  version: 

Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_headers: flags=2

Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_to: end of header reached, state=10

Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_to: display={}, 
ruri={sip:111@199.48.152.152}

Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:get_hdr_field:  [26]; 
uri=[sip:111@199.48.152.152]

Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:get_hdr_field: to body 
[#015#012]

Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:get_hdr_field: cseq : <1> 

Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_via_param: found param type 235,  = ; state=6

Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_via_param: found param type 232,  = 
; state=16

Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_via: end of header re

Re: [OpenSIPS-Users] Routing in opensips

2016-10-25 Thread Bogdan-Andrei Iancu

Hi Eric,

By traffic (coming back), you understand RTP or SIP traffic ?

Could you post the INVITE message getting out of your server ? I suspect 
the INVITE has in SDP a private IP that is not reachable for the end 
device (where the call is sent).


Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 21.10.2016 18:46, Eric Freeman wrote:


Yes, I see Request INVITE going to the device I am calling. I do not 
see any traffic coming back. I am following up with my Firewall team.


My Firewall team suggested I might need to change the RTP ports to use 
UDP 2326-2485. Where do I change/check these settings on the OpenSIPs 
server to see if I have the traffic going out those ports.



Thanks,


Eric Freeman

Technical Director/NA for TBWA\Chiat\Day

TBWA\Chiat\Day New York
488 Madison Ave.
New York NY 10022
United States of America
Tel: +12128041324 

*From:* Bogdan-Andrei Iancu 
*Sent:* Monday, October 3, 2016 4:44:26 AM
*To:* Eric Freeman; OpenSIPS users mailling list
*Subject:* Re: [OpenSIPS-Users] Routing in opensips
Hi Eric,

Not the OpenSIPs logs I'm looking for, but the actual SIP packet at 
network level (use ngrep or tcpdump) for the INVITE leaving your OpenSIPS.


Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 30.09.2016 16:52, Eric Freeman wrote:


Hopefully this is the relevant information you need from the log. I 
am trying to call 111@199.48.152.152. The IP of the opensips server 
si 10.88.23.10 and has a public IP of 204.17.231.3.  The IP address 
of the video conference server is 10.89.71.12.



Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_msg: SIP Request:


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_msg:  method:  


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_msg:  uri: 


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_msg:  version: 


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_headers: flags=2


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_to: end of header reached, state=10


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_to: display={}, ruri={sip:111@199.48.152.152}


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:get_hdr_field:  [26]; uri=[sip:111@199.48.152.152]


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:get_hdr_field: to body [#015#012]


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:get_hdr_field: cseq : <1> 


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_via_param: found param type 235,  = ; state=6


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_via_param: found param type 232,  = 
; state=16


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_via: end of header reached, state=5


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_headers: via found, flags=2


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_headers: this is the first via


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:receive_msg: After parse_msg...


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:receive_msg: preparing to run routing scripts...


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_headers: flags=100


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:maxfwd:is_maxfwd_present: value = 70


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:uri:has_totag: no totag


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_headers: flags=78


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:tm:t_lookup_request: start searching: hash=25578, isACK=0


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:tm:matching_3261: RFC3261 transaction matching failed


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:tm:t_lookup_request: no transaction found


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_to_param: 
tag=2c770a98-c47590a-13c4-45026-57ed3cdd-1bac9941-57ed3cdd


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_to: end of header reached, state=29


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core:parse_to: display={"Conference Room"}, 
ruri={sip:LifeSize@10.88.23.13;transport=UDP}


Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: 
DBG:core

Re: [OpenSIPS-Users] Delivery Status Notification (Failure)

2016-10-25 Thread Bogdan-Andrei Iancu

Johan,

The scenario should work with the received value too . Whatever is 
between the <> is considered as SIP URI and it will copied into the RURI 
of the new call.


Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 24.10.2016 14:55, johan de clercq wrote:

The refer-to header looks like this:

""

And I think that in order for the scenario to work, it should have the
following layout :



So that's the manipulation that I want to do :

Extract part before ; and add >

BR,



-Original Message-
From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Monday, October 24, 2016 12:24 PM
To: johan de clercq ; 'OpenSIPS users mailling list'

Subject: Re: [OpenSIPS-Users] Delivery Status Notification (Failure)

Johan,

The REFER request will never get into your script as it will be absorbed and
handled by the b2b module - actually will not see any sequential requests
for a call that was pushed into b2b.

What kind of manipulation you want to do over the REFER-TO hdr ?

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 24.10.2016 13:06, johan de clercq wrote:

Thanks Bogdan,

The problem is that I have my refer-to header with replaces: in it.
Hence I adapted the scenario so that I could do header manipulations
on this header.

I do however manipulations on headers and I think I need to reroute
then through route(0)

if(is_method("REFER"))
{
  #x contains the value of the Refer-To header==$rt
  $var(x)=$rt;
  #remove the Refer-To header
  remove_hf("Refer-To");
  #manipulate x : extract part before ; and add >
  $var(x)=$(var(x){s.select,0,;});
  $var(x)=$var(x) + ">";
  append_hf("Refer-To:$var(x)");
  #re route through route[0]
  route(0);
}

Hence I have 2 states in the scenario, so that on the first pass the
scenario only puts state to 2 and then on the second pass, it should
effectively bridge.

There is of course a however :-): opensips does not start ...

Oct 24 11:28:55 [29804] ERROR:core:fix_actions: called route 4 is not
defined Oct 24 11:28:55 [29804] ERROR:core:fix_actions: fixing failed
(code=-6) at cfg line 125 Oct 24 11:28:55 [29804] ERROR:core:main:
failed to fix configuration with err code -6

The problem is that I have nowhere a route 4 defined ..

Can it be that route(0) is the problem ?   If yes, how can I implement the
above described logic ?

BR, Johan.





-Original Message-
From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Monday, October 24, 2016 11:59 AM
To: OpenSIPS users mailling list ; johan de
clercq 
Subject: Re: [OpenSIPS-Users] Delivery Status Notification (Failure)

Hi Johan,

The cfg is more than simple and straight - whatever initial request
you receive -> start the b2b with this scenario.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 22.10.2016 17:45, johan de clercq wrote:

Does somebody has an example .cfg file that shows how to use the
refer scenario described in
http://www.opensips.org/Documentation/Tutorials-B2BUA#toc15 ?

I am struggling with call transfers with REFER and opensips that

loadbalances to multiple gateways.





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

Tel +3256980990 - GSM +32478720104






___
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] OpenSIPS eBootcamp Training

2016-10-25 Thread Bogdan-Andrei Iancu

Heads up, there is only one week left before the training starts!

Seats are filling in fast by people looking to discover and assimilate 
knowledge on OpenSIPS 2.2, via the new attractive format of lectures, 
hand-on labs and interactive sessions with the trainers.


Do not mis it, register now on http://elearning.opensips.org/ebootcamp/ 
as the number of seats are limited.


See you there,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 19.09.2016 12:22, Bogdan-Andrei Iancu wrote:

Dear all,

The next OpenSIPS eBootcamp session is scheduled for *31st of October 
2016*. The training has a new format, /combining video lectures, 
hands-on labs and interactive sessions with the trainers/. We are 
innovating again offering a datacenter for the labs where students and 
instructors can interact to build a real solution.  At the end of the 
training you will have a telephony solution built in the cloud.


The training requires you to allocate 6 hours per week (for 5 weeks) 
to watch the videos, live conferences and execute the labs.


More information and registration is available on 
http://elearning.opensips.org/ebootcamp .


Best regards,
--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


___
News mailing list
n...@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/news


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