Re: [OpenSIPS-Users] Conflicting information from commands 'opensipsctl ul show' and ' opensipsctl fifo list_tcp_conns '.

2016-11-30 Thread Rodrigo Pimenta Carvalho
Hi. Razvan.


Thank you very much!


If I remember, I guess that I had removed all records from table location, of 
user A.

But I will pay more attention on it next time.


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 Răzvan Crainea 
Enviado: quarta-feira, 30 de novembro de 2016 08:47
Para: users@lists.opensips.org
Assunto: Re: [OpenSIPS-Users] Conflicting information from commands 
'opensipsctl ul show' and ' opensipsctl fifo list_tcp_conns '.

Hi, Rodrigo!

Before removing A from the user location, did you do an opensips ul show
to see what registrations OpenSIPS knows? Are there multiple
registrations? Are you deleting all of them?
Opening a TCP connection to opensips doesn't necessarily mean that the
client also sent a REGISTER message, and therefore the client is not yet
registered from SIP perspective. What you might see there (with port
48695) might be an old (bogus) registration. After a while, when the
client registers, you see the correct info.

Best regards,

Răzvan Crainea
OpenSIPS Core 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 11/29/2016 10:33 PM, Rodrigo Pimenta Carvalho wrote:
> Hi.
>
>
> I have peer A and peer B online on my OpenSIPS.
>
> After removing peer A from table location and reseting peer A, I have:
>
>
> Connection::  ID=29 Type=tcp State=0 Source=127.0.0.1:*52887*
> Destination=127.0.0.1:5060 Lifetime=1970-01-01 08:44:41
>
> It means that peer A is online on OpenSIPS via TCP socket with port
> 52887. This is the result of command '/opensipsctl fifo list_tcp_conns/'.
>
>
> However, the commad '/opensipsctl ul show/' gives me:
>
>
> AOR:: intercomA_5dtUWgwgqzR6
> Contact::
> sip:intercomA_5dtUWgwgqzR6@127.0.0.1:*48694*;transport=TCP;ob Q=
> Expires:: 479
> Callid:: 5694778c-6178-4e80-bf2e-7a4dc0deb5d1
> Cseq:: 37504
> User-agent:: n/a
> State:: CS_SYNC
> Flags:: 0
> Cflags::
> Socket:: tcp:127.0.0.1:5060
> Methods:: 8063
> Attr:: in_same_network
> SIP_instance:: 
>
> It means that peer A is online on OpenSIPS via TCP socket with port
> 48694. So, I have a kind of conflict here. How can it be possible?
>
> So, if peer A calls peer B, when B answers I can see the following log:
>
>
> Jan  1 08:36:14 [435] ERROR:core:tcpconn_async_connect: failed to
> retrieve SO_ERROR [server=127.0.0.1:*48694*] (111) Connection refused
>
>
> Why such behavior does exist in OpenSIPS? How to avoid it?
>
> And after a while a new TCP connection appered in port 52887. Like this:
>
>
> Contact::
> sip:intercomA_5dtUWgwgqzR6@127.0.0.1:52887;transport=TCP;ob Q=
> Expires:: 236
> Callid:: 96672dc5-a98c-468e-a07a-aca27748791a
> Cseq:: 25094
> User-agent:: n/a
> State:: CS_SYNC
> Flags:: 0
> Cflags::
> Socket:: tcp:127.0.0.1:5060
> Methods:: 8063
> Attr:: in_same_network
> SIP_instance:: 
>
> Could it be a problem in OpenSIPS?
>
>
>
> Any hint will be 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
Users Info Page - 
OpenSIPS
lists.opensips.org
Discussions about how to use OpenSIPS (non-business). To see the collection of 
prior postings to the list, visit the Users Archives.


>

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Users Info Page - 
OpenSIPS
lists.opensips.org
Discussions about how to use OpenSIPS (non-business). To see the collection of 
prior postings to the list, visit the Users Archives.


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


Re: [OpenSIPS-Users] Conflicting information from commands 'opensipsctl ul show' and ' opensipsctl fifo list_tcp_conns '.

2016-11-30 Thread Răzvan Crainea

Hi, Rodrigo!

Before removing A from the user location, did you do an opensips ul show 
to see what registrations OpenSIPS knows? Are there multiple 
registrations? Are you deleting all of them?
Opening a TCP connection to opensips doesn't necessarily mean that the 
client also sent a REGISTER message, and therefore the client is not yet 
registered from SIP perspective. What you might see there (with port 
48695) might be an old (bogus) registration. After a while, when the 
client registers, you see the correct info.


Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 11/29/2016 10:33 PM, Rodrigo Pimenta Carvalho wrote:

Hi.


I have peer A and peer B online on my OpenSIPS.

After removing peer A from table location and reseting peer A, I have:


Connection::  ID=29 Type=tcp State=0 Source=127.0.0.1:*52887*
Destination=127.0.0.1:5060 Lifetime=1970-01-01 08:44:41

It means that peer A is online on OpenSIPS via TCP socket with port
52887. This is the result of command '/opensipsctl fifo list_tcp_conns/'.


However, the commad '/opensipsctl ul show/' gives me:


AOR:: intercomA_5dtUWgwgqzR6
Contact::
sip:intercomA_5dtUWgwgqzR6@127.0.0.1:*48694*;transport=TCP;ob Q=
Expires:: 479
Callid:: 5694778c-6178-4e80-bf2e-7a4dc0deb5d1
Cseq:: 37504
User-agent:: n/a
State:: CS_SYNC
Flags:: 0
Cflags::
Socket:: tcp:127.0.0.1:5060
Methods:: 8063
Attr:: in_same_network
SIP_instance:: 

It means that peer A is online on OpenSIPS via TCP socket with port
48694. So, I have a kind of conflict here. How can it be possible?

So, if peer A calls peer B, when B answers I can see the following log:


Jan  1 08:36:14 [435] ERROR:core:tcpconn_async_connect: failed to
retrieve SO_ERROR [server=127.0.0.1:*48694*] (111) Connection refused


Why such behavior does exist in OpenSIPS? How to avoid it?

And after a while a new TCP connection appered in port 52887. Like this:


Contact::
sip:intercomA_5dtUWgwgqzR6@127.0.0.1:52887;transport=TCP;ob Q=
Expires:: 236
Callid:: 96672dc5-a98c-468e-a07a-aca27748791a
Cseq:: 25094
User-agent:: n/a
State:: CS_SYNC
Flags:: 0
Cflags::
Socket:: tcp:127.0.0.1:5060
Methods:: 8063
Attr:: in_same_network
SIP_instance:: 

Could it be a problem in OpenSIPS?



Any hint will be 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



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


Re: [OpenSIPS-Users] Actions that apply to all branches

2016-11-30 Thread Adrian Fretwell

Bogdan, thank you that is very helpful.

Kind regards,
Adrian Fretwell

On 29/11/16 12:14, Bogdan-Andrei Iancu wrote:

Hi,

The per-branch data is :
 * R-URI
 * DST-URI (outbound proxy)
 * PATH header
 * q value (priority)
 * send_socket
 * branch flags

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 28.11.2016 14:11, Schoolhouse Filing wrote:


Hi Razvan,

What I found was then if I appended branches then called 
force_send_socket() only the current branch went out on that 
interface, the other branches went out on a different interface.  
It's not a problem I will re-structure my script, I was simply 
appending branches to create a ring group.


Kind Regards,

Adrian.


On 28/11/16 09:35, Răzvan Crainea wrote:

Hi, Adrian!

I don't think you will find such a list.
Usually the idea is to do the changes that affect all branches in 
the main route, and if you want to do per-branch changes, do them in 
the branch_route.
Are you sure that force_send_socket() only applies to the main 
branch? If you call force_send_socket() in the main route, and then 
add a second branch, the messages leave on different interfaces?


Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com
On 11/26/2016 12:19 PM, Adrian Fretwell wrote:


Hello,

I understand from the documentation that after calling 
append_branch() any further URI manipulations only apply to the 
main branch, but I am trying to understand what actions will still 
apply over all the branches.  For example I discovered that 
rtpproxy_offer() appears to affect all branches, but 
force_send_socket() only apples to the main branch.


Is there a list or rule that will help me work out what I need to 
apply before branching and what I can leave until later, perhaps 
until just before t_relay() is called?


I hope my question makes sense.

Kind regards,

Adrian Fretwell
The Old School house
Top Green
Sibthorpe
Nottinghamshire
NG23 5PN.

T: 01636 525360
M: 07850 756603

This electronic message contains information from A-Squared 
Engineering Services which may be privileged or confidential. The 
information is intended to be for the use of the individual(s) or 
entity(s) named above. If you are not the intended recipient be 
aware that any disclosure, copying, distribution or use of the 
contents of this information is prohibited. If you have received 
this electronic message in error, please notify us by telephone or 
email to adrian.fretw...@topgreen.co.uk immediately.



___
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




___
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


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