Re: [OpenSIPS-Users] Opensips 2.2.1 dr_rules is empty

[Denis]

Hello!

Any ideas about the problem?

 mailto:denis7...@mail.ru



Hello, Bogdan

I am sorry that i did not describe the problem more clearly.
404 opensips sends because in opensips.cfg i wrote a logic that if in dr_rules 
opensips finds no rules for routing it must send 404.
And the problem i think is there. Opensips began rejects all calls with 404, 
i.e. it could not find any rules in dr_rules table.
Everthing began fine after fifo dr_reload command execution, i.e. after 
dr_rules updating.   

-- 
mailto:denis7...@mail.ru


Hi,

OpenSIPS by itself does not send any 404. If it does, it does it because you 
put that into the script. So, you have to look into your script and see the 
logical path that makes OpenSIPS to get to sending a 404 reply.

You may use the script_trace :
  http://www.opensips.org/Documentation/Script-CoreFunctions-2-2#toc43

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 30.08.2016 22:26, Denis wrote:

Re: Opensips 2.2.1 dr_rules is empty Hello!

Some time ago i wrote about a problem when Opensips began reject all calls with 
404 code.
Unfortunately i did not received any answer.
Since that time i have made upgrade from 2.1.2 to 2.2.1 and today i have got 
the same problem. Opensips began rejects all calls with 404 code. 

Based on the information from log, i make suggest that problem began when 
dr_reload command has been received. 
And the problem has been solved, again, when the dr_reload command has been 
received (the period about two commands is about a couple of minutes).

I please help to solve the problem. 

Thank you.

mailto:denis7...@mail.ru


Hello!

Recently i begun to get such problem.
Opensips rejects all calls with 404 code. I can solve the problem by making 
dr_reload.
I tried to analyze a log and what i could found you can see in attachment.
As i could understand last problem began after dr_reload.

Thank you for any help.


mailto:denis7...@mail.ru




___
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] ERROR:core:evi_raise_script_event: too many attribute names

[Artur Mega]

Good day, I try to pass some params to my event handler (by this manual -
https://www.opensips.org/Documentation/Tutorials-EventInterface), but when
i pass more than 4 attributes it throws an error

ERROR:core:evi_raise_script_event: too many attribute names

How can I pass more params, or maybe just serialize all vars to json and
pass it to event handler?

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

Re: [OpenSIPS-Users] What does mean "a=inactive"?

[Rodrigo Pimenta Carvalho]

Hi.


Thank you very much!


Your explanation was sufficient and now I understood what is happening.

There is no changes caused by OpenSIPS. Is the UAC that decides to put that 
"inactive" there.


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 Benjamin Cropley 
Enviado: quarta-feira, 7 de setembro de 2016 09:01
Para: OpenSIPS users mailling list
Assunto: Re: [OpenSIPS-Users] What does mean "a=inactive"?

I would start by looking at a trace. Is it A changing the SDP attribute? or is 
OpenSIPS doing it?

Inactive obviously means "Keep the session live, but dont send me any audio, 
and I won't send you any audio".

I've seen that happen once, when both end points couldnt establish a codec.. 
due to processing error or something like that, but instead of sending an 
appropriate error, it just connects the call and send that.

Hope that helps,
Ben Cropley

On Thu, Sep 1, 2016 at 1:12 PM, Rodrigo Pimenta Carvalho 
mailto:pime...@inatel.br>> wrote:


Dear OpenSIPS users;

I'm not sure if the following question is about OpenSIPS, or SIP, or SDP, but...

I have 2 softphones (Microsip) with SIP UAC: in phone A and in phone B. There 
is a SIP Proxy (OpenSIPS) between they too.


When A calls B, I can see the SIP messages (via wireshark) and in some moment A 
sends a SIP UPDATE do B.

The SIP UPDATE has SDP with lines like this:


v=0
o=- 3681643549 3681643550 IN IP4 XXX.YYY.240.204
s=pjmedia
b=AS:84
t=0 0
a=X-nat:1
m=audio 64568 RTP/AVP 110 8 101
c=IN IP4 XXX.YYY.240.204
b=TIAS:64000
a=rtpmap:110 speex/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ice-ufrag:139d7049
a=ice-pwd:692c4a80
a=rtcp:64571 IN IP4 XXX.YYY.240.204
a=candidate:Sc0a81485 1 UDP 1862270975 XXX.YYY.240.204 64568 typ srflx raddr 
192.168.20.133 rport 64568
a=candidate:Sc0a81485 2 UDP 1862270974 XXX.YYY.240.204 64571 typ srflx raddr 
192.168.20.133 rport 64571
a=remote-candidates:1 XXX.YYY.240.71 64993 2 XXX.YYY.240.71 64996
a=sendrecv

However, if I replace the SIP Proxy with another one containing the same 
software (Same OpenSIPS, database, network, etc. Just hardware is different) 
and run the same call (A calls B), that "a=sendrecv" in SIP UPDATE changes to 
"a=inactive". If the peers are still the same, how could a media attribute 
changes?


I have no idea what could cause this difference related to media attribute! 
Could OpenSIPS take care of this case?

Could someone here give me some examples of what could cause an "a=inactive", 
so that I will have a point to start my analyze of the problem?

I will also take a look in the SIP RFC to get some hint.

Any hint will be very very helpful!

Best regards.



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

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




--
All the best,
Ben Cropley
07539 366 905
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] FW: Asynchronous operation for REST queries

[Liviu Chircu]

Hi, Agalya!

Regarding the 10s delayproblem, a fix was pushed to the development 
branch [1]. If you are running on 2.1.4 git branch, could you please 
pull the latest changes (git pull --rebase), and test it out? You can 
import it with:


git cherry-pick -x  66c337cc

[1]: 
https://github.com/OpenSIPS/opensips/commit/66c337cc89a2b5c3e1bbd78c289371efcda21886


Best regards,

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

On 07.09.2016 20:14, Ramachandran, Agalya (Contractor) wrote:


Hi team,

Any clue on this below topic would be a great. Am stuck with this 10 
sec delay and couldn’t move further.


If I could be able to find the root cause and resolve this , then only 
I can implement REST API calls as async.


Because this 10 sec delay is a huge time.  Please help me on this.

Regards,

Agalya

*From:*Ramachandran, Agalya (Contractor)
*Sent:* Tuesday, August 30, 2016 10:13 AM
*To:* 'Liviu Chircu' mailto:li...@opensips.org>>
*Subject:* RE: FW: [OpenSIPS-Users] Asynchronous operation for REST 
queries


Hi Liviu,

A clue for this 10 sec delay consumed by opensips before sending the 
HTTP request, will be grateful for me. As far as I debugged this delay 
is caused by curl library. But wondering what could be the cause for 
this constant 10.25 sec delay.?


Please help me out in this.

Regards,

Agalya

*From:*Ramachandran, Agalya (Contractor)
*Sent:* Friday, August 26, 2016 2:29 PM
*To:* 'Liviu Chircu' mailto:li...@opensips.org>>
*Cc:* OpenSIPS users mailling list >
*Subject:* RE: FW: [OpenSIPS-Users] Asynchronous operation for REST 
queries


Hi Liviu,

Here is the dump from the time when the socket is opened and when the 
request sent out.


Highlighted in RED color. Any clue for this 10 sec delay?

*17:29:56.430379 IP6 sturn-test.novalocal.44797*> 
destination.rtc.sys.comcast.net.webcache: Flags [S], seq 3356294440, 
win 28800, options [mss 1440,sackOK,TS val 3588300781 ecr 0,nop,wscale 
7], length 0


0x:  6000  0028 0640 2001 0558 fc0b 0100  `(.@...X 



0x0010:  f816 3eff fed5 0bfe 2001 0558 fc11   ..>X

0x0020:  f816 3eff fe11 d5aa aefd 1f90 c80c fd28  ..>(

0x0030:    a002 7080 90bb  0204 05a0  ..p.

0x0040:  0402 080a d5e1 1fed   0103 0307  

17:29:56.436526 IP6 destination.rtc.sys.comcast.net.webcache > 
sturn-test.novalocal.44797: Flags [S.], seq 4065018495, ack 
3356294441, win 28560, options [mss 1440,sackOK,TS val 1771678349 ecr 
3588300781,nop,wscale 9], length 0


0x:  6000  0028 063a 2001 0558 fc11   `(.:...X

0x0010:  f816 3eff fe11 d5aa 2001 0558 fc0b 0100  ..>X

0x0020:  f816 3eff fed5 0bfe 1f90 aefd f24b 427f  ..>..KB.

0x0030:  c80c fd29 a012 6f90 755f  0204 05a0  ...)..o.u_..

0x0040:  0402 080a 6999 aa8d d5e1 1fed 0103 0309  i...

17:29:56.436575 IP6 sturn-test.novalocal.44797 > 
destination.rtc.sys.comcast.net.webcache: Flags [.], ack 1, win 225, 
options [nop,nop,TS val 3588300787 ecr 1771678349], length 0


0x:  6000  0020 0640 2001 0558 fc0b 0100  `..@...X

0x0010:  f816 3eff fed5 0bfe 2001 0558 fc11   ..>X

0x0020:  f816 3eff fe11 d5aa aefd 1f90 c80c fd29  ..>)

0x0030:  f24b 4280 8010 00e1 90b3  0101 080a  .KB.

0x0040:  d5e1 1ff3 6999 aa8d  i...

*17:30:06.667279 IP6 sturn-test.novalocal.44797*> 
destination.rtc.sys.comcast.net.webcache: Flags [P.], seq 1:681, ack 
1, win 225, options [nop,nop,TS val 3588311018 ecr 1771678349], length 680


PUT./RTCGSessionManager/rest/tel/session/createroom?uid=pp&custguid=1-32...@xx.yyy.231.239..http/1.1..Host:.tr-sm-as-a-001.rtc.sys.comcast.net:8080..Accept:.*/*..Conten 
 
t-Type:.application/json..Uid:.pp..serviceId:.tel..custguid:.1-32750@96.119.231. 
239...x-tracking-id:.820..X-Trace:.trace-id=1-32750@96.119.231.239...x-server-name:.RTCGSM..x-client-name:.IMS


x-source-id:.OpenSIP..user-agent:.OpenSIPv1.11.3..device-id:.1-32...@xx.yyy.231. 
239...Content-Length:.211{"participantsInfo" 
:["211212"],"callType":"audio","instanceId": "1-32...@xx.yyy. 
231.239. 
","fromUID":"pp","fromTN":"pp","isOpenSipRequest":true," 
displayName":"Call.From.IMS","deviceType":"Android/iOS/STB/IMS"}


17:30:06.672819 IP6 destination.rtc.sys.comcast.net.webcache > 
sturn-test.novalocal.44797: Flags [.], ack 681, win 59, options 
[nop,nop,TS val 1771688585 ecr 3588311018], length 0


0x:  6000  0020 063a 2001 0558 fc11   `..:...X

0x0010:  f816 3eff fe11 d5aa 2001 0558 fc0b 0100  ..>...