date:20160419

[OpenSIPS-Users] Failure cause code in case of transaction timeout

2016-04-19 Thread John Nash

I am using fr_inv_timer and fr_timer and logging failed transactions, but
in both cases I get request timeout. Can I control this somehow so that I
log "Time out" only in case fr_timer expires and record something else in
case fr_inv_timer?
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Call-id issue in Cancel message generated by tm / $T_fr_inv_timeout

2016-04-19 Thread John Nash

Ok got it thanks. I also noticed that transactions cancelled because of
fr_inv_timeout , CDR records as "Request timeout". It is quite confusion,
shouldnt it be "Request Terminated"? or I am doing something wrong

On Tue, Apr 19, 2016 at 6:46 PM, Julian Santer 
wrote:

> Hi John,
>
> the commit was:
>
> commit 8133656de9503a122a72c0f80d11eff975bc43f1
> Author: Bogdan-Andrei Iancu 
> Date:   Thu Feb 11 14:58:41 2016 +0200
>
> Fix proper callig in local cancels with TH.
>
> Extend the coverage of the preocessing context and TM context over the
> cancel_branch() function (in the timeout handler) so the TH callbacks can
> reach back the dialog and do the TH related changes.
> Reported by Julian Santer on mailing list.
>
> Kind regards,
> Julian Santer
> Raiffeisen OnLine
>
> Am 18.04.2016 um 22:35 schrieb John Nash:
>
>> which revision this was fixed?...I am also using OpenSips 2.1.2 and want
>> to update only this change for the time being (2.2 has many changes)
>>
>> On Thu, Feb 11, 2016 at 7:19 PM, Julian Santer > > wrote:
>>
>> Bogdan,
>>
>> we tried now the latest GIT release and it works like a charm ;-)
>> Thank you for quick fix.
>>
>> Kind regards,
>> Julian Santer
>> Raiffeisen OnLine
>>
>> Am 11.02.2016 um 14:02 schrieb Bogdan-Andrei Iancu:
>>
>> Julian,
>>
>> Please update from GIT repo and give it a new try. It should work
>> now (at least it does for me).
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>> On 11.02.2016 12:07, Julian Santer wrote:
>>
>> Hi Bogdan,
>>
>> thank you for your time. If you need further informations
>> (config files etc.) let me know.
>>
>> Kind regards,
>> Julian Santer
>> Raiffeisen OnLine
>>
>> Am 11.02.2016 um 10:26 schrieb Bogdan-Andrei Iancu:
>>
>> Hi Julian,
>>
>> I will have to test this and come back to you.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>> On 10.02.2016 17:45, Julian Santer wrote:
>>
>> Hi guys,
>>
>> we seem to got the same issue like John Nash on
>> 2015/08/12.
>> We use OpenSips 2.1.2 with the latest revision from
>> git repo.
>>
>> Like John we are not sure if it is a bug or our
>> mistake ;-)
>>
>> We are using topology hiding and the Call ID in the
>> CANCEL, generated by the TM module, is not the same, as the call ID in the
>> initial INVITE.
>>
>> The call flow looks like:
>> PSTN carrier -> gw-carrier (topo hiding) -> core
>> (topo hiding) -> gw-consumer (topo-hiding) -> UAC consumer
>>
>> The CANCEL generated by the TM module of the core,
>> sended to the gw-consumer is rejected by the gw-consumer.
>>
>> The CANCEL starts on the core. So let me show you
>> 1) the initial INVITE, which the core receives from
>> the gw-carrier (Call-ID: GW-CARRIER)
>> 2) the initial INVITE, which the core and sends to
>> the gw-consumer (Call-ID: Core)
>> 3) the CANCEL generated by the core after
>> $T_fr_inv_timeout (Call-ID: GW-CARRIER)
>>
>> 1)
>> INVITE sip:12345@IP_CORE SIP/2.0
>> Via: SIP/2.0/UDP
>> IP_GW-CARRIER:5060;branch=z9hG4bK6aa2.7710f555.0
>> From: ;tag=E3AE5C5C-1A42
>> To: 
>> Call-ID:
>> GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE
>> CSeq: 101 INVITE
>> Max-Forwards:  8
>> Remote-Party-ID: > >;party=calling;screen=yes;privacy=off
>> Contact: > ;rdlg=3db.94186637>
>> Expires: 180
>> Content-Type: application/sdp
>> Content-Length: 474
>> sdp ...
>>
>> 2)
>> INVITE sip:12345@IP_UAC:PORT_UAC SIP/2.0
>> Via: SIP/2.0/UDP
>> IP_CORE:5060;branch=z9hG4bK45da.82f6fd55.0
>> Route: 
>> From: ;tag=E3AE5C5C-1A42
>> To: 
>> Call-ID:
>> Core_ExwGCwAcKhgvdAgnFg58LwQGAXUOXSAzC3A1JFB/FCcWCWFzGAQkXHInPFQGDzYYI3oPCCAMahZeEy11JywlCVEG
>> CSeq: 101 INVITE
>>

Re: [OpenSIPS-Users] Call-id issue in Cancel message generated by tm / $T_fr_inv_timeout

2016-04-19 Thread Julian Santer


Hi John,

the commit was:

commit 8133656de9503a122a72c0f80d11eff975bc43f1
Author: Bogdan-Andrei Iancu 
Date:   Thu Feb 11 14:58:41 2016 +0200

Fix proper callig in local cancels with TH.

Extend the coverage of the preocessing context and TM context over the cancel_branch() function (in the timeout handler) so the TH callbacks can 
reach back the dialog and do the TH related changes.

Reported by Julian Santer on mailing list.

Kind regards,
Julian Santer
Raiffeisen OnLine

Am 18.04.2016 um 22:35 schrieb John Nash:

which revision this was fixed?...I am also using OpenSips 2.1.2 and want to 
update only this change for the time being (2.2 has many changes)

On Thu, Feb 11, 2016 at 7:19 PM, Julian Santer > wrote:

Bogdan,

we tried now the latest GIT release and it works like a charm ;-)
Thank you for quick fix.

Kind regards,
Julian Santer
Raiffeisen OnLine

Am 11.02.2016 um 14:02 schrieb Bogdan-Andrei Iancu:

Julian,

Please update from GIT repo and give it a new try. It should work now 
(at least it does for me).

Regards,

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

On 11.02.2016 12:07, Julian Santer wrote:

Hi Bogdan,

thank you for your time. If you need further informations (config 
files etc.) let me know.

Kind regards,
Julian Santer
Raiffeisen OnLine

Am 11.02.2016 um 10:26 schrieb Bogdan-Andrei Iancu:

Hi Julian,

I will have to test this and come back to you.

Regards,

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

On 10.02.2016 17:45, Julian Santer wrote:

Hi guys,

we seem to got the same issue like John Nash on 2015/08/12.
We use OpenSips 2.1.2 with the latest revision from git 
repo.

Like John we are not sure if it is a bug or our mistake ;-)

We are using topology hiding and the Call ID in the CANCEL, 
generated by the TM module, is not the same, as the call ID in the
initial INVITE.

The call flow looks like:
PSTN carrier -> gw-carrier (topo hiding) -> core (topo hiding) 
-> gw-consumer (topo-hiding) -> UAC consumer

The CANCEL generated by the TM module of the core, sended 
to the gw-consumer is rejected by the gw-consumer.

The CANCEL starts on the core. So let me show you
1) the initial INVITE, which the core receives from the 
gw-carrier (Call-ID: GW-CARRIER)
2) the initial INVITE, which the core and sends to the 
gw-consumer (Call-ID: Core)
3) the CANCEL generated by the core after $T_fr_inv_timeout 
(Call-ID: GW-CARRIER)

1)
INVITE sip:12345@IP_CORE SIP/2.0
Via: SIP/2.0/UDP 
IP_GW-CARRIER:5060;branch=z9hG4bK6aa2.7710f555.0
From: ;tag=E3AE5C5C-1A42
To: 
Call-ID: 
GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE
CSeq: 101 INVITE
Max-Forwards:  8
Remote-Party-ID: 
;party=calling;screen=yes;privacy=off
Contact: 
Expires: 180
Content-Type: application/sdp
Content-Length: 474
sdp ...

2)
INVITE sip:12345@IP_UAC:PORT_UAC SIP/2.0
Via: SIP/2.0/UDP IP_CORE:5060;branch=z9hG4bK45da.82f6fd55.0
Route: 
From: ;tag=E3AE5C5C-1A42
To: 
Call-ID: 
Core_ExwGCwAcKhgvdAgnFg58LwQGAXUOXSAzC3A1JFB/FCcWCWFzGAQkXHInPFQGDzYYI3oPCCAMahZeEy11JywlCVEG
CSeq: 101 INVITE
Max-Forwards:  7
Remote-Party-ID: 
;party=calling;screen=yes;privacy=off
Contact: 
Expires: 180
Content-Type: application/sdp
Content-Length: 426
sdp ...

3)
CANCEL sip:12345@IP_UAC:PORT_UAC SIP/2.0
Via: SIP/2.0/UDP IP_CORE:5060;branch=z9hG4bK45da.82f6fd55.0
From: ;tag=E3AE5C5C-1A42
Call-ID:

Re: [OpenSIPS-Users] How to avoid increasingly memory comsuption with AVPs?

2016-04-19 Thread Rodrigo Pimenta Carvalho

Hi Liviu.


Thank you for the replay.

I gave up of using "(db_mode = 0)". I was thinking about db_mode = 0 just to 
see if OpenSIPS could work without reporting lots of warnings in the log, as I 
see every day after letting some clients sending SIP REGISTER to this sip proxy 
during 3 or 4 hours (one by minute).

But, after a night of tests with db_mode = 0, I have concluded that even in 
this case OpenSIPS reports such warnings. Warnings about, for example: 
"core:utimer_ticker: utimer task  already schedualed for 22814570 ms 
(now 22815250 ms), it may overlap.." I was thinking that this issue related to 
the Sqlite. But it doesn't.


Now, I still have to create a very simple opensips.cfg script (one just handle 
SIP REGISTER messages) and see if I can discover why this sip proxy causes this 
issue. Maybe I have made some mistake in my script. After lots of warnings like 
this, my hardware stops working.


Best regards.


RODRIGO PIMENTA CARVALHO
Inatel Competence Center
Software
Ph: +55 35 3471 9200 RAMAL 979



De: users-boun...@lists.opensips.org  em nome 
de Liviu Chircu 
Enviado: terça-feira, 19 de abril de 2016 09:15
Para: users@lists.opensips.org
Assunto: Re: [OpenSIPS-Users] How to avoid increasingly memory comsuption with 
AVPs?

Did you know that when doing a "lookup()" from script (registrar module), the 
"attr" AVP is also populated? Maybe you can use this information and rewrite 
that "avp_db_query" portion of your script in order to achieve the fast 
cache-querying logic (db_mode = 0) you are talking about.

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

[http://www.opensips-solutions.com/imgs/slideshow/slide3.jpg]

Home — OpenSIPS Solutions
www.opensips-solutions.com
OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is 
more than a SIP proxy/router as it includes application-level functionalities.

On 19.04.2016 00:07, Rodrigo Pimenta Carvalho wrote:

Hi Liviu.



When I use "modparam("usrloc", "db_mode", 1)" the following query works fine 
and gives me the right result:


avp_db_query("select attr from location where contact like 
'$(ct.fields(uri){s.select,0,;})%' and username = '$fU'", "$avp(caller)");


When I use "modparam("usrloc", "db_mode", 0)" the above query doesn't give me 
the right value.


It is true because the query seems to acts only over the database, not over 
data from cached memory. And in this case the data from database obviously is 
not equal to that from cached memory. As you told me: ""db_mode" of the usrloc 
module has nothing to do with "avp_db_query""


So, in this case, how to execute queries over data from cached memory?


Any hint will be very helpful!


Best regards.



RODRIGO PIMENTA CARVALHO
Inatel Competence Center
Software
Ph: +55 35 3471 9200 RAMAL 979



De: users-boun...@lists.opensips.org 
 em 
nome de Liviu Chircu 
Enviado: segunda-feira, 18 de abril de 2016 10:50
Para: users@lists.opensips.org
Assunto: Re: [OpenSIPS-Users] How to avoid increasingly memory comsuption with 
AVPs?

Yes you can, "db_mode" of the usrloc module has nothing to do with 
"avp_db_query" from the avpops module! :)

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

[http://www.opensips-solutions.com/imgs/slideshow/slide3.jpg]

Home — OpenSIPS Solutions
www.opensips-solutions.com
OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is 
more than a SIP proxy/router as it includes application-level functionalities.

On 18.04.2016 15:10, Rodrigo Pimenta Carvalho wrote:

Hi Liviu.


Thank you very much!

So, I'm comfortable with OpenSIPS.


In my OpenSIPS config file I have:


loadmodule "usrloc.so"
modparam("usrloc", "db_mode",   2)


Can I change db_mode to zero and still have every avp_db_query working well?

That is,  with db_mode=0 I will avoid using Sqlite and every SQL operation over 
user location will apply just over data in memory cache. Am I correct?


Any hint will be very helpful!




___
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 avoid increasingly memory comsuption with AVPs?

2016-04-19 Thread Liviu Chircu

Did you know that when doing a "lookup()" from script (registrar 
module), the "attr" AVP is also populated? Maybe you can use this 
information and rewrite that "avp_db_query" portion of your script in 
order to achieve the fast cache-querying logic (db_mode = 0) you are 
talking about.


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

On 19.04.2016 00:07, Rodrigo Pimenta Carvalho wrote:


Hi Liviu.



When I use "modparam("usrloc", "db_mode", 1)" the following query 
works fine and gives me the right result:



avp_db_query("select attr from location where contact like 
'$(ct.fields(uri){s.select,0,;})%' and username = '$fU'", "$avp(caller)");



When I use "modparam("usrloc", "db_mode", 0)" the above query doesn't 
give me the right value.



It is true because the query seems to acts only over the database, not 
over data from cached memory. And in this case the data from database 
obviously is not equal to that from cached memory. As you told me: 
""db_mode" of the usrloc module has nothing to do with "avp_db_query""



So, in this case, how to execute queries over data from cached memory?


Any hint will be very helpful!


Best regards.



RODRIGO PIMENTA CARVALHO
Inatel Competence Center
Software
Ph: +55 35 3471 9200 RAMAL 979



*De:* users-boun...@lists.opensips.org 
 em nome de Liviu Chircu 


*Enviado:* segunda-feira, 18 de abril de 2016 10:50
*Para:* users@lists.opensips.org
*Assunto:* Re: [OpenSIPS-Users] How to avoid increasingly memory 
comsuption with AVPs?
Yes you can, "db_mode" of the usrloc module has nothing to do with 
"avp_db_query" from the avpops module! :)

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


Home — OpenSIPS Solutions 
www.opensips-solutions.com
OpenSIPS is a mature Open Source implementation of a SIP server. 
OpenSIPS is more than a SIP proxy/router as it includes 
application-level functionalities.


On 18.04.2016 15:10, Rodrigo Pimenta Carvalho wrote:


Hi Liviu.


Thank you very much!

So, I'm comfortable with OpenSIPS.


In my OpenSIPS config file I have:


loadmodule "usrloc.so"
modparam("usrloc", "db_mode",   2)


Can I change db_mode to zero and still have every avp_db_query 
working well?


That is,  with db_mode=0 I will avoid using Sqlite and every SQL 
operation over user location will apply just over data in memory 
cache. Am I correct?



Any hint will be very helpful!





___
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] Fix_nated_SDP works very well. How to do more changes in the SDP?

2016-04-19 Thread Rodrigo Pimenta Carvalho

Hi Daniel.


Thank you very much!

I will read about it right now.


Best regards.


RODRIGO PIMENTA CARVALHO
Inatel Competence Center
Software
Ph: +55 35 3471 9200 RAMAL 979



De: users-boun...@lists.opensips.org  em nome 
de Daniel Zanutti 
Enviado: segunda-feira, 18 de abril de 2016 18:56
Para: OpenSIPS users mailling list
Assunto: Re: [OpenSIPS-Users] Fix_nated_SDP works very well. How to do more 
changes in the SDP?

Hi Rodrigo

In theory you can modify any SIP/SDP using text ops:

http://www.opensips.org/html/docs/modules/1.6.x/textops.html#id293600

I don't know any other way...

Regards


On Mon, Apr 18, 2016 at 6:17 PM, Rodrigo Pimenta Carvalho 
> wrote:


Hi.


Fix_nated_sdp() function works very well. I can fix IPs in my SDP, for 
attributes "o" and "c'.


However, due to a particular desire of my customer, I have to change more 
others IPs in my SDP. How to do it? Is it possible?


For example, how to change the pointed IP seen bellow:



v=0
o=- 366344 366344 IN IP4 xxx.yyy.240.71
s=pjmedia
b=AS:25
t=0 0
a=X-nat:1
m=audio 48053 RTP/AVP 8 110 96
c=IN IP4 xxx.yyy.240.71
b=TIAS:8000
a=rtcp:51193 IN IP4 192.168.100.1
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:110 speex/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ice-ufrag:30381869
a=ice-pwd:6268c522
a=candidate:Sc0a864f1 1 UDP 1862270975 192.168.100.1 48053 typ srflx raddr 
192.168.100.241 rport 48053  // RAMAL 979

___
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 SIP trunk call handling

2016-04-19 Thread Francjos

Hello, 
I sent you invitation on skype,nduwayezu Joselyne on skype,  i'm waiting for
your reply.I still have problems with the incoming call throught Opensips.
I rely on your help please!!



--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/Opensips-SIP-trunk-call-handling-tp7602552p7602643.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

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

Re: [OpenSIPS-Users] OpenSips as an inbound loadbalancer and outbound proxy - issue with routing BYES

2016-04-19 Thread Francjos

Hello Younas,
I sent you the invitation on skype,i'm waiting for your reply. I still have
problems with the incoming call throught opensips.
Thank you for your attention.



--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSips-as-an-inbound-loadbalancer-and-outbound-proxy-issue-with-routing-BYES-tp6984017p7602642.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

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

[OpenSIPS-Users] Failure cause code in case of transaction timeout

Re: [OpenSIPS-Users] Call-id issue in Cancel message generated by tm / $T_fr_inv_timeout

Re: [OpenSIPS-Users] Call-id issue in Cancel message generated by tm / $T_fr_inv_timeout

Re: [OpenSIPS-Users] How to avoid increasingly memory comsuption with AVPs?

Re: [OpenSIPS-Users] How to avoid increasingly memory comsuption with AVPs?

Re: [OpenSIPS-Users] Fix_nated_SDP works very well. How to do more changes in the SDP?

Re: [OpenSIPS-Users] Opensips SIP trunk call handling

Re: [OpenSIPS-Users] OpenSips as an inbound loadbalancer and outbound proxy - issue with routing BYES

8 matches

Site Navigation

Mail list logo

Footer information