[OpenSIPS-Users] user location in mongodb

[Jayesh Nambiar]

Hello,
I am running opensips 2.3.2 stable. I wanted to know if mongodb can be used
for storing the user location information with opensips cachedb_mongodb
module?
Quick googling didnt give me any clarity if it is possible or not. Before
doing anything, I wanted to know if this is possible with opensips.

Thanks,

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

Re: [OpenSIPS-Users] tcp_async timeouts confusion

[Steve Brisson]

Sorry for the late response.

Unfortunately I no longer have call access to the vcs server that experienced 
this error and the issue seemed timing dependent on that particular call path. 
I will update the bug with DBG logs if I am able to recreate the problem by 
some other means.

Thanks for the help.

From: Users [mailto:users-boun...@lists.opensips.org] On Behalf Of Liviu Chircu
Sent: Friday, January 19, 2018 7:16 AM
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] tcp_async timeouts confusion


Hi Steve,

I've opened a GitHub issue for this report so we can better keep track of it 
[1], and will likely be next on my priority list. I will try to find some time 
to attempt to reproduce it asap. In the meanwhile, would you be as kind as to 
supply some debug logs while the async TCP reads are piling up? You may ship 
them to li...@opensips.org.

Best regards,

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

Liviu Chircu

OpenSIPS Developer

http://www.opensips-solutions.com
On 18.01.2018 18:35, Steve Brisson wrote:
Hi, just wondering if this issue is still being considered.

Thanks,
steve

From: Users [mailto:users-boun...@lists.opensips.org] On Behalf Of Steve Brisson
Sent: Thursday, January 11, 2018 11:56 AM
To: OpenSIPS users mailling list 

Subject: Re: [OpenSIPS-Users] tcp_async timeouts confusion

TCP scenario:
Yes that is exactly correct. If I have tcp_connect_timeout=3000 and tcp_async=1 
configured then calls to the vcs fail. If I then make the single change to 
disable tcp_async, calls to my vcs endpoints will work.

TLS scenario:
Thanks for the clarification, makes sense. Unfortunately the online 
documentation doesn't describe the parameters and lists an incorrect scaling 
factor (it's defined in milliseconds, not seconds).

steve

From: Users [mailto:users-boun...@lists.opensips.org] On Behalf Of Liviu Chircu
Sent: Thursday, January 11, 2018 3:39 AM
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] tcp_async timeouts confusion


Answers below,


On 09.01.2018 22:25, Steve Brisson wrote:

*** Using TCP ***

After the invite is sent to the vcs, tcpdump at the opensips server showed 100, 
180, and 200 OK responses from the vcs arriving and ACK'd correctly at the 
opensips server. The 100 response arrived 185ms after the invite is sent. But, 
I don't see these responses in the branch's onreply_route, the global 
onreply_route, or in the log at DBG level. netstat -t shows the connection with 
the data in the recv-q that never reaches 0. This implies to me that opensips 
is not polling that connection correctly for recv data.

If I disable tcp_async then the call is completed successfully. So in the case 
that works, I have tcp_connect_timeout=3000 and tcp_async=0.
Just to confirm the scenario: So the signaling is broken with 
"tcp_connect_timeout=3000 and tcp_async=1" (reply routes do not get triggered / 
recv-q keeps on growing), however once you switch to "tcp_async=0", everything 
is back to working?

*** Using TLS ***

Running tcpdump, I see the opensips server send a Client Hello then a FIN 
packet 100ms later. The vcs responds with a Server Hello 200ms after the Client 
Hello and this gets RST.

To workaround this case, I set tls_handshake_timeout=3000 and 
tls_send_timeout=1000. Maybe this is the correct behavior, I'm still not 100% 
sure how the tls parameters function.
This time, it's behaving as expected. Maybe there should be a diagram somewhere 
with how these parameters work together. For example, each TLS connection will 
roughly follow the below steps along with their corresponding parameterized 
timeouts:

1. TCP connect (tcp_connect_timeout)
2. TLS connect/accept handshake (tls_handshake_timeout)
3. TLS write (tls_send_timeout)
4. TLS write (tls_send_timeout)



Liviu Chircu

OpenSIPS Developer

http://www.opensips-solutions.com




___

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

[OpenSIPS-Users] Potential memory leak in siptrace module

[Steve Brisson]

I've found that when I call the sip_trace method, in the main request routing 
block, the shmem used_size and fragments continually increases until the 
process crashes from an out of memory condition.

By enabling memory alloc debugging, I confirmed that the leaked allocation is 
the shm_malloc of a trace_info_t structure in the sip_trace_w method 
[siptrace.c:1539]. This piece of memory is supposed to be freed in the dialog 
terminated callback but because of the logic in the sip_trace_w method, 
trace_flags gets modified to TRACE_TRANSACTION and the dialog callbacks are 
never registered.

I haven't worked out the details of a proper fix yet. My workaround has been to 
remove the siptrace module from my config.


OpenSIPS config details:

opensips 2.3.2 (x86_64/linux)

#siptrace module config
modparam("siptrace", "trace_on", 0)
modparam("siptrace", "trace_id", 
"[tid]uri=mysql://db-user:db-pass@db-host/db-name;table=sip_trace;")

#siptrace method call in main request branch
sip_trace("tid", "d", "sip");
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Handling 488 on a leg B

[Bogdan-Andrei Iancu]

Hello Dmitry,

What you want to do is called (in SIP) serial forking. Use 
failure_route{} to catch the 488 and to add a create a new branch (with 
modified body) .


See: http://www.opensips.org/Documentation/Script-Routes-2-3#toc3

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Summit 2018
  http://www.opensips.org/events/Summit-2018Amsterdam

On 01/30/2018 02:56 PM, Dmitry wrote:


Hello all,

Could you say how can I re-send INVITE with changed SDP to B-leg after 
receive 488 from it?


Call flow:

-> A-leg INVITE

<- A-leg 100

-> B-leg INVITE

<- B-leg 100

<- B-leg 488 – I catch it, and want to send INVITE again with properly SDP

-> B-leg ACK

<-A-leg 488

-> B-leg ACK

Thanks for any advice.

Cheers!



___
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] I have some doubts on contact fix in opensips-1.11 .

[Bogdan-Andrei Iancu]

Hi Sasmita,

Of course it fixes only the first contact - afterall the function is 
called fix_contact() and not fix_contactS()


But please ignore me, this was a silly joke :D..

Yes, it seems that fix_contact() is limited at handling the first only. 
But you can use the fix_nated_contact() function from nathelper module, 
which handles all contacts.


Regards

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Summit 2018
  http://www.opensips.org/events/Summit-2018Amsterdam

On 01/31/2018 02:23 PM, Sasmita Panda wrote:

Hi All ,

   I am using opensips-1.11 and trying to fix contact in the proxy 
before saving in DB .  This is the bellow code for contact fix .


if (client_nat_test("1")) {
fix_contact();
};

  As for my observation , when I am sending multiple contact in a 
single REGISTER message , Its only updating the first contact and wont 
update the rest .


  Just wanted to know why this is happening . Every contact of 
mine in the REGISTER message have private IP but one get updated and 
rest remain same .


Please do help me . Thanks in advance .


*/Thanks & Regards/*
/Sasmita Panda/
/Network Testing and Software Engineer/
/3CLogic , ph:07827611765/


___
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] Problem with event based routing

[Bogdan-Andrei Iancu]

Hi Olle,

Are you sure all these inserts (of the same branch) are done on top of 
the same dialog ? maybe there are multiple calls(InVITE in progress) 
waiting for this registration event ?


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Summit 2018
  http://www.opensips.org/events/Summit-2018Amsterdam

On 01/31/2018 12:03 PM, Olle Frimanson wrote:


Hi , thanks Bogdan this sorted it out and call forking works as a charm J.

The only problem issue I have seen is that sometimes a single 
registration triggers multiple events below is a log snippet for such 
an case ( a bit anonymized)


2018-01-31T09:51:56.296843+00:00 info sip-qa-1 
cF6apbQMV66SfiQ2phordLXqQQvJIRxj|Route0|REGISTER|Save 
location|true|us...@domain.com]


2018-01-31T09:51:56.297101+00:00 info sip-qa-1 INSERT_CALL: user 
us...@domain.com registered the a new contact 
sip:userA@212.116.71.162:50734;transport=TLS;ob, injecting it in 
transaction


2018-01-31T09:51:56.297470+00:00 info sip-qa-1 INSERT_CALL: user 
us...@domain.com registered the a new contact 
sip:userA@212.116.71.162:50734;transport=TLS;ob, injecting it in 
transaction


2018-01-31T09:51:56.297803+00:00 info sip-qa-1 INSERT_CALL: user 
us...@domain.com registered the a new contact 
sip:userA@212.116.71.162:50734;transport=TLS;ob, injecting it in 
transaction


One could of course check if this contact IP/port have already been 
injected into the call, but I just wondered if this is anything you 
have seen before.


BR/Olle

*Från:*Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
*Skickat:* den 26 januari 2018 15:53
*Till:* Olle Frimanson ; 'OpenSIPS users mailling 
list' 

*Ämne:* Re: SV: [OpenSIPS-Users] Problem with event based routing

Hi,

It is illegal to do signalling (like t_relay()) in branch route. 
Simply remove the whole branch route stuff from your script as you do 
not need it.


Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Summit 2018
http://www.opensips.org/events/Summit-2018Amsterdam

On 01/25/2018 12:31 PM, Olle Frimanson wrote:

Hi I call a relay route from the branch route, so it’s basically

Route {

….

t_wait_for_new_branches();

$avp(filter)= "aor="+ $avp(to_user_uri);

notify_on_event("E_UL_CONTACT_INSERT","$avp(filter)",
"INSERT_CALL", "40");

t_on_branch(“1”)

If ( lookup(“location”)

route(relay)

}

route[RELAY] {

if (is_method("INVITE")) {

t_on_reply("1");

t_on_failure("3");

if (!t_relay()) {

….

}

}

}

route[INSERT_CALL] {

t_inject_branches("event","cancel");

}

branch_route[1] {

route(RELAY);

exit;

}

BR / Olle

PS I send another mail on the same subject since I missed your
reply pls ignore that.

*Från:*Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
*Skickat:* den 24 januari 2018 17:42
*Till:* OpenSIPS users mailling list 
; Olle Frimanson 

*Ämne:* Re: [OpenSIPS-Users] Problem with event based routing

Hi Olle,

Do you call t_relay() from a BRANCH_ROUTE ?? IF so, this is not
legal as the branch route is only an inspection and modification
route, not a signaling route.

Regards,


Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com

OpenSIPS Summit 2018

http://www.opensips.org/events/Summit-2018Amsterdam

On 01/24/2018 11:33 AM, Olle Frimanson wrote:

Hi,

We are looking into changing our logic for push notification
to the new event based routing that is available in opensips 2.3.

In live scenarios everything is working fine but when I relay
the call after injecting it into the branch I get the
following error:

CRITICAL:tm:w_t_relay: unsupported route type: 8

It would be great if you could share the configuration file
that is used in the example mention in the blog post.

BR/Olle





___

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

[OpenSIPS-Users] I have some doubts on contact fix in opensips-1.11 .

[Sasmita Panda]

Hi All ,

   I am using opensips-1.11 and trying to fix contact in the proxy
before saving in DB .  This is the bellow code for contact fix .

if (client_nat_test("1")) {
fix_contact();
};

  As for my observation , when I am sending multiple contact in a
single REGISTER message , Its only updating the first contact and wont
update the rest .

  Just wanted to know why this is happening . Every contact of mine in
the REGISTER message have private IP but one get updated and rest remain
same .

Please do help me . Thanks in advance .


*Thanks & Regards*
*Sasmita Panda*
*Network Testing and Software Engineer*
*3CLogic , ph:07827611765*
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Dispatcher not probing

[Bogdan-Andrei Iancu]

Pete,

There may be a bit of a confusion here. I was talking about the 
ds_probing_list parameter (which is default UNSET). The ds_probing_mode 
is indeed 0 as default, meaning to ping only destinations in state PROBING.


Again, do you have this pinging issue for all the destinations in your set ?

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Summit 2018
  http://www.opensips.org/events/Summit-2018Amsterdam

On 01/30/2018 03:41 PM, Pete Kelly wrote:

Bogdan

The docs say the default is "0" so actually the default is UNSET?

Which I think means I need to set it to 0 in order to make the Probing 
gw's be probed?





On 26 January 2018 at 15:55, Bogdan-Andrei Iancu > wrote:


Pete, yes, you are right - if not set at all (which is different
than setting it to "0") it means probing for all. And default is
"unset"/

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com 
OpenSIPS Summit 2018
   http://www.opensips.org/events/Summit-2018Amsterdam


On 01/26/2018 05:37 PM, Pete Kelly wrote:

Hi Bogdan

ds_probing_mode is set to the default (0).

The docs say this "If set to 0, only the gateways with state
PROBING are tested"

So I would assume this means that anything in PROBING should be
pinged?

On 26 January 2018 at 14:15, Bogdan-Andrei Iancu
mailto:bog...@opensips.org>> wrote:

Hi Pete,

The primary storage (during runtime) is memory (the in-mem
status is only flushed to DB, not read).

Now, do you use "ds_probing_list" parameter ? Also, are you
sure "ds_probing_mode" parameter is set to 1 ?

More questions - this issue happens only for a particular
destination ? or none of the "probing" destinations is pinged ?

Regards,

Bogdan-Andrei Iancu

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

OpenSIPS Summit 2018
   http://www.opensips.org/events/Summit-2018Amsterdam


On 01/26/2018 11:58 AM, Pete Kelly wrote:

The gw should be being probed (this is the desired behaviour!).

Is OpenSIPS using the DB column instead of the in-memory state?

On 22 January 2018 at 16:33, Bogdan-Andrei Iancu
mailto:bog...@opensips.org>> wrote:

Hi Pete,

The DB schema is documented here:
http://www.opensips.org/Documentation/Install-DBSchema-2-3#AEN4379


State "1" means disabled and this explains the
no-probing behavior. Still, you claim that the in-memory
state is Probing, according to the MI ds_list
commandSo, which is the right state of the GW ?? :)

Regards,

Bogdan-Andrei Iancu

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

OpenSIPS Summit 2018
   http://www.opensips.org/events/Summit-2018Amsterdam


On 01/18/2018 12:53 PM, Pete Kelly wrote:

Hi

I am using OpenSIPS 2.3.2 and have the dispatcher
module configured thusly:


# - dispatcher params -
modparam("dispatcher", "db_url",
"mysql://DB_USER:DB_PASSWD@DB_HOST/DB_NAME")
modparam("dispatcher", "ds_probing_threshhold", 10)
modparam("dispatcher", "table_name", "dispatcher_2_3")
modparam("dispatcher", "persistent_state", 0)
#modparam("dispatcher", "ds_probing_mode", 0)  #Not
setting this explicitly as the default is 0

My understanding of this is that any gateway that is in
the state of "Probing" will now be probed with OPTIONS
until it becomes active by means of a 200OK response
(or a configured +ve response)

However I have a gateway which has been set into
probing using ds_set_state("p"). This is verified using
the MI command ds_list:

host:~/tees# /usr/local/opensips_2_3/sbin/opensipsctl
fifo ds_list | grep "Probing"
URI:: sip:192.168.0.15 state=Probing first_hit_counter=0


Yet OpenSIPS is not probing the gateway at all and I
can't logically fathom why this is. The state column in
the dispatcher table is set to 1, but the documentation
is not clear on what this means.

I am sure I am overlooking something silly, would

Re: [OpenSIPS-Users] Dispatcher module documentation

[Bogdan-Andrei Iancu]

Thanks Pete !

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Summit 2018
  http://www.opensips.org/events/Summit-2018Amsterdam

On 01/30/2018 03:46 PM, Pete Kelly wrote:

Done

https://github.com/OpenSIPS/opensips/issues/1267

Pete

On 26 January 2018 at 15:57, Bogdan-Andrei Iancu > wrote:


Yes, point taken. Also the modules using SQL should link to theier
dbschema (from README). Still, the status of the destination
should be unified (in terms of values) at script and DB level.

Could you please open github ticket on that I do not forget about it ?

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com 
OpenSIPS Summit 2018
   http://www.opensips.org/events/Summit-2018Amsterdam


On 01/26/2018 05:39 PM, Pete Kelly wrote:

Hi Bogdan

Thanks for that.

I guess my point is that it would be useful to have that list of
states in the module documentation too, as it differs from the
normal "a"/"i"/"p" values.

Pete

On 26 January 2018 at 14:19, Bogdan-Andrei Iancu
mailto:bog...@opensips.org>> wrote:

Hi Pete,

The meaning of the "status" column is documented in the DB
schema document:

http://www.opensips.org/Documentation/Install-DBSchema-2-3#AEN4379



The "persistent_state" options is related to writing (at
shutdown) back to DB the in-memory state of the destination.
It is not necessary related to pinging, but to preserve the
destination state during OpenSIPS restarts.

Regards,

Bogdan-Andrei Iancu

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

OpenSIPS Summit 2018
   http://www.opensips.org/events/Summit-2018Amsterdam


On 01/26/2018 11:57 AM, Pete Kelly wrote:

Hi Bogdan

The state column appears to be the column which holds the
current state of a GW. I assume this would be i/a/p? But it
is not clear what this value should be set to to correspond
to whether a gateway should be set as
Active/Inactive/Probing on startup:

http://www.opensips.org/html/docs/modules/2.3.x/dispatcher#idp5606416


The documentation implies that this column can be used on
startup too

http://www.opensips.org/html/docs/modules/2.3.x/dispatcher#idp5580768



So I guess my questions are:

1) If I want the state column to be referenced on startup,
what are the possible values I can use?
2) If I set the paramater persistent_state=0, will OpenSIPS
assume to ping all gw's on startup?







On 22 January 2018 at 16:25, Bogdan-Andrei Iancu
mailto:bog...@opensips.org>> wrote:

Hi Pete,

The link you posted does not work for me (maybe the docs
were updated in the mean while). But there is no module
param or DB column "probe mode" or so
So, can you point again to the problematic configuration
option ?

Best regards,

Bogdan-Andrei Iancu

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

OpenSIPS Summit 2018
   http://www.opensips.org/events/Summit-2018Amsterdam


On 01/18/2018 12:23 PM, Pete Kelly wrote:

Hi all!!

I frequently have to configure the dispatcher module,
and one of the items that always crops us is which
"probe mode" to set the gateways to within the
dispatcher table.

It always proves a bit troublesome because it's not
clear from the documentation which integer corresponds
to "inactive"/"probing"/"probe when disabled" etc.

Is there any chance the documentation here could be
updated in the next iteration so that the state values
are enumerated?


http://www.opensips.org/html/docs/modules/2.3.x/dispatcher#idp5608512



Pete


___
Users mailing list
Users@lists.opensips.org 
http://lists.opensi

Re: [OpenSIPS-Users] Problem with event based routing

[Olle Frimanson]

Hi , thanks Bogdan this sorted it out and call forking works as a charm :).

 

The only problem issue I have seen is that sometimes a single registration
triggers multiple events below is a log snippet for such an case ( a bit
anonymized)

 

2018-01-31T09:51:56.296843+00:00 info sip-qa-1
cF6apbQMV66SfiQ2phordLXqQQvJIRxj|Route0|REGISTER|Save
location|true|us...@domain.com]

2018-01-31T09:51:56.297101+00:00 info sip-qa-1 INSERT_CALL: user
us...@domain.com registered the a new contact
sip:userA@212.116.71.162:50734;transport=TLS;ob, injecting it in transaction

2018-01-31T09:51:56.297470+00:00 info sip-qa-1 INSERT_CALL: user
us...@domain.com registered the a new contact
sip:userA@212.116.71.162:50734;transport=TLS;ob, injecting it in transaction

2018-01-31T09:51:56.297803+00:00 info sip-qa-1 INSERT_CALL: user
us...@domain.com registered the a new contact
sip:userA@212.116.71.162:50734;transport=TLS;ob, injecting it in transaction

 

One could of course check if this contact IP/port have already been injected
into the call, but I just wondered if this is anything you have seen before.

 

BR/Olle

 

Från: Bogdan-Andrei Iancu [mailto:bog...@opensips.org] 
Skickat: den 26 januari 2018 15:53
Till: Olle Frimanson ; 'OpenSIPS users mailling list'

Ämne: Re: SV: [OpenSIPS-Users] Problem with event based routing

 

Hi,

It is illegal to do signalling (like t_relay()) in branch route. Simply
remove the whole branch route stuff from your script as you do not need it.

Regards,



Bogdan-Andrei Iancu
 
OpenSIPS Founder and Developer
    http://www.opensips-solutions.com
OpenSIPS Summit 2018
   
http://www.opensips.org/events/Summit-2018Amsterdam

On 01/25/2018 12:31 PM, Olle Frimanson wrote:

Hi I call a relay route from the branch route, so it’s basically

 

Route {  

….

t_wait_for_new_branches();

$avp(filter)= "aor="+ $avp(to_user_uri);

notify_on_event("E_UL_CONTACT_INSERT","$avp(filter)", "INSERT_CALL",
"40");

t_on_branch(“1”)

 

If ( lookup(“location”)

route(relay)

}

 

route[RELAY] {

if (is_method("INVITE")) {

t_on_reply("1");

t_on_failure("3");

if (!t_relay()) {

….

}

}

}

 

route[INSERT_CALL] {

t_inject_branches("event","cancel");

}

 

branch_route[1] {

route(RELAY);

exit;

}

 

BR / Olle

 

PS I send another mail on the same subject since I missed your reply pls
ignore that.

 

 

Från: Bogdan-Andrei Iancu [ 
mailto:bog...@opensips.org] 
Skickat: den 24 januari 2018 17:42
Till: OpenSIPS users mailling list  
; Olle Frimanson  

Ämne: Re: [OpenSIPS-Users] Problem with event based routing

 

Hi Olle,

Do you call t_relay() from a BRANCH_ROUTE ?? IF so, this is not legal as the
branch route is only an inspection and modification route, not a signaling
route.

Regards,




Bogdan-Andrei Iancu
 
OpenSIPS Founder and Developer
    http://www.opensips-solutions.com
OpenSIPS Summit 2018
   
http://www.opensips.org/events/Summit-2018Amsterdam

On 01/24/2018 11:33 AM, Olle Frimanson wrote:

Hi,

 

We are looking into changing our logic for push notification to the new
event based routing that is available in opensips 2.3.

 

In live scenarios everything is working fine but when I relay the call after
injecting it into the branch I get the following error:

 

CRITICAL:tm:w_t_relay: unsupported route type: 8

 

It would be great if you could share the configuration file that is used in
the example mention in the blog post.

 

BR/Olle

 

 







___
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