date:20161026

[OpenSIPS-Users] OpenSIPS reopen TCP connectios and sends INVITE, but not BYE. How to change it?

2016-10-26 Thread Rodrigo Pimenta Carvalho

Hi.


After some log debug I have observed the following behavior in the OpenSISP 
(2.2.1):


When OpenSIPS has to send a SIP INVITE to a peer through a TCP connection that 
was closed before by some way, OpenSIPS open a new one and then sends the SIP 
message to the peer successfully.


However, when OpenSIPS has to send a SIP BYE to a peer through a TCP connection 
that was closed before, OpenSIPS open a new one, but doesn't send the SIP BYE. 
In this case SIP BYE is discarded.


How to change the behavior of OpenSIPS to make it to send the SIP BYE is such 
case?


I'm looking for ways of fix or workaround of a TCP tear down connection that 
happens during dialogs.


Any hint will be very helpful!


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

Re: [OpenSIPS-Users] How to ensure current IPV6 listening address

2016-10-26 Thread Robert Dyck

I am reluctant to take out a github membership to simply request a feature. 
Perhaps someone with an existing membership could request the feature.

Opensips currently is unable to detect the IPV6 address of an interface when 
given the interface name in the configuration. This is a request to implement 
that capability.

On October 26, 2016 04:20:23 PM Răzvan Crainea wrote:
> Hi, Robert!
> 
> After further documenting, it seems that linux can only provide IPv4
> interfaces (for more info, see [1], check for SIOCGIFCONF). In order to
> support IPv6, we need to find a different way to get the addresses.
> Please open a feature request on our tracker[2], and we will check how
> to support this.
> 
> [1] https://linux.die.net/man/7/netdevice
> [2] https://github.com/OpenSIPS/opensips/issues
> 
> Best regards,
> 
> Răzvan Crainea
> OpenSIPS Solutions
> www.opensips-solutions.com
> 
> On 10/20/2016 02:21 PM, Bogdan-Andrei Iancu wrote:
> > Hi Robert,
> > 
> > If you use in the listener definition the name of an interface, it
> > should detect IPV6 too. Is this working ?
> > 
> > Regards,
> > 
> > Bogdan-Andrei Iancu
> > OpenSIPS Founder and Developer
> > http://www.opensips-solutions.com
> > 
> > On 20.10.2016 00:35, Robert Dyck wrote:
> >> Thanks for your input. The second scenario doesn't appear to be an
> >> issue.
> >> 
> >>   If opensips can detect the IPV4 address on an interface should it
> >> 
> >> be only a
> >> minor enhancement to detect the IPV6 address?
> >> 
> >> On October 19, 2016 11:09:50 PM Bogdan-Andrei Iancu wrote:
> >>> Hi Robert,
> >>> 
> >>> I see here two aspects:
> >>> 
> >>> 1) how to determine the IP at OpenSIPS startup - you need to perform
> >>> the
> >>> IPv6 detection in a pre-start script and feed it to OpenSIPS. That is
> >>> the way it should be
> >>> 
> >>> 2) if the IP changes during runtime, there is nothing you can do rather
> >>> then restarting - OpenSIPS cannot change listeners during runtime.
> >>> 
> >>> Regards,
> >>> 
> >>> Bogdan-Andrei Iancu
> >>> OpenSIPS Founder and Developer
> >>> http://www.opensips-solutions.com
> >>> 
> >>> On 19.10.2016 19:14, Robert Dyck wrote:
>  Using 1.10.5
>  My ISP provides an IPV6 prefix which unfortunately is not static. My
>  address does not change spontaneously but if the host is down for a
>  significant time the address will change.
>  
>  I thought it would be simply solved by specifying a listening
>  interface in
>  the configuration file. Unfortunately that only picks up the IPV4
>  address.
>  
>  I have a DDNS provider and I can specify a domain name in the
>  configuration but my concern is that the address bound to the
>  domain name
>  may be stale at the moment that opensips comes up. Does opensips
>  verify
>  an address obtained through DNS?
>  
>  ___
>  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

Re: [OpenSIPS-Users] How to ensure current IPV6 listening address

2016-10-26 Thread Robert Dyck

Thank you for investigating this.

To improve the chance of Opensips getting the current IP address from the FQDN 
I employed the NetworkManager dispatcher to send an immediate update to the 
name server. I am sure that one could parse the output of 
'ip addr" and somehow update opensips.cfg but bash scripts are a mystery to 
me.

On October 26, 2016 04:20:23 PM Răzvan Crainea wrote:
> Hi, Robert!
> 
> After further documenting, it seems that linux can only provide IPv4
> interfaces (for more info, see [1], check for SIOCGIFCONF). In order to
> support IPv6, we need to find a different way to get the addresses.
> Please open a feature request on our tracker[2], and we will check how
> to support this.
> 
> [1] https://linux.die.net/man/7/netdevice
> [2] https://github.com/OpenSIPS/opensips/issues
> 
> Best regards,
> 
> Răzvan Crainea
> OpenSIPS Solutions
> www.opensips-solutions.com
> 
> On 10/20/2016 02:21 PM, Bogdan-Andrei Iancu wrote:
> > Hi Robert,
> > 
> > If you use in the listener definition the name of an interface, it
> > should detect IPV6 too. Is this working ?
> > 
> > Regards,
> > 
> > Bogdan-Andrei Iancu
> > OpenSIPS Founder and Developer
> > http://www.opensips-solutions.com
> > 
> > On 20.10.2016 00:35, Robert Dyck wrote:
> >> Thanks for your input. The second scenario doesn't appear to be an
> >> issue.
> >> 
> >>   If opensips can detect the IPV4 address on an interface should it
> >> 
> >> be only a
> >> minor enhancement to detect the IPV6 address?
> >> 
> >> On October 19, 2016 11:09:50 PM Bogdan-Andrei Iancu wrote:
> >>> Hi Robert,
> >>> 
> >>> I see here two aspects:
> >>> 
> >>> 1) how to determine the IP at OpenSIPS startup - you need to perform
> >>> the
> >>> IPv6 detection in a pre-start script and feed it to OpenSIPS. That is
> >>> the way it should be
> >>> 
> >>> 2) if the IP changes during runtime, there is nothing you can do rather
> >>> then restarting - OpenSIPS cannot change listeners during runtime.
> >>> 
> >>> Regards,
> >>> 
> >>> Bogdan-Andrei Iancu
> >>> OpenSIPS Founder and Developer
> >>> http://www.opensips-solutions.com
> >>> 
> >>> On 19.10.2016 19:14, Robert Dyck wrote:
>  Using 1.10.5
>  My ISP provides an IPV6 prefix which unfortunately is not static. My
>  address does not change spontaneously but if the host is down for a
>  significant time the address will change.
>  
>  I thought it would be simply solved by specifying a listening
>  interface in
>  the configuration file. Unfortunately that only picks up the IPV4
>  address.
>  
>  I have a DDNS provider and I can specify a domain name in the
>  configuration but my concern is that the address bound to the
>  domain name
>  may be stale at the moment that opensips comes up. Does opensips
>  verify
>  an address obtained through DNS?
>  
>  ___
>  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

Re: [OpenSIPS-Users] Is it a kind of TCP keep alive produced by OpenSIPS?

2016-10-26 Thread Rodrigo Pimenta Carvalho

Hi Răzvan.


Thank you very much.

I'm facing a problem here related to TCP connection teared down during dialogs.

While a peer is not in dialogs, its TCP connection to OpenSIPS keeps online all 
the time.

However, when such peer enters in a conversation (be part of a dialog), after 
few minutes there is a EOF received in a socket. After this, OpenSIPS can no 
more send SIP BYEs to the respective peer. In the log I can see:


Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan  2 01:38:45 [21027] 
DBG:core:tcp_read: EOF on 0x74e3d048, FD 24
Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan  2 01:38:45 [21027] 
DBG:core:tcp_read_req: EOF received
Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan  2 01:38:45 [21027] 
DBG:core:io_watch_del: [TCP_worker] io_watch_del op on index 0 24 (0x1875e8, 
24, 0, 0x10,0x3) fd_no=3 called
Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan  2 01:38:45 [21027] 
DBG:core:tcpconn_release:  releasing con 0x74e3d048, state -1, fd=-1, id=3
Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan  2 01:38:45 [21027] 
DBG:core:tcpconn_release:  extra_data (nil)
Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan  2 01:38:45 [21029] 
DBG:core:handle_tcp_worker: reader response= 74e3d048, -1 from 2
Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan  2 01:38:45 [21029] 
DBG:core:tcpconn_destroy: destroying connection 0x74e3d048, flags 0006


...

When OpenSIPS try to send a SIP BYE via socket 0x74e3d048 , I can see the log:

Jan 02 01:40:49 colibri-imx6-jfl opensips[21018]: Jan  2 01:40:49 [21026] 
DBG:core:proto_tcp_send: no open tcp connection found, opening new one, async = 
1


I have already used the flag "Pp" in the creation of dialogs, but it didn't 
take effect. That is, even with "Pp" I'm still getting "EOF" in the TCP socket.


1 - Should the flag "Pp" avoid those EOFs during dialogs?


That flag causes the OpenSIPS to send SIP OPTIONS. The peers are replying with 
SIP 500.


2- Is a SIP 500 reply enough to OpenSIPS keep the dialog connected?


3 - Does it make sense getting absence of keep alive messages during dialogs?


Any hint will be very helpful!

P.S.: I will check the TCP trace too, looking for keep alives.


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, 26 de outubro de 2016 13:08
Para: users@lists.opensips.org
Assunto: Re: [OpenSIPS-Users] Is it a kind of TCP keep alive produced by 
OpenSIPS?

Hi, Rodrigo!

The logs you are tracing are printed when OpenSIPS receives something from the 
client, and then immediately responds back. Due to the fact that we don't see 
any other debug messages, like SIP parsing & stuff, makes me think that it is a 
CRLF pinging - the client periodically sends a CRLFCRLF TCP message to 
OpenSIPS, and OpenSIPS responds with a single CRLF. Note that this is different 
from a TCP keep-alive, where each peer send a 0-length TCP message, without any 
body. That message doesn't even get to the application layer.
However, tracing the communication between OpenSIPS and the client should 
confirm the above :).

Best regards,

Răzvan Crainea
OpenSIPS Solutions
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 10/26/2016 05:10 PM, Rodrigo Pimenta Carvalho wrote:

Dear OpenSIPS users,


In the OpenSIPS log I see:


Jan 01 19:30:38 colibri-imx6-jfl opensips[3444]: Jan  1 19:30:38 [3451] 
DBG:core:tcp_read_req: Using the global ( per process ) buff
Jan 01 19:30:38 colibri-imx6-jfl opensips[3444]: Jan  1 19:30:38 [3451] 
DBG:core:tcp_handle_req: content-length= 0
Jan 01 19:30:38 colibri-imx6-jfl opensips[3444]: Jan  1 19:30:38 [3451] 
DBG:core:async_tsend_stream: Async successful write from first try on 0x74e13548
Jan 01 19:30:38 colibri-imx6-jfl opensips[3444]: Jan  1 19:30:38 [3451] 
DBG:core:tcp_read_req: tcp_read_req end

The frequency is 1 time at each 1,5 minute. There is only one client online. I 
suspect that OpenSIPS uses the socket 0x74e13548 to send messages to such 
client. The client became online using TCP.

Just to confirm, is this log a result of a TCP keep alive function enabled?

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] Is it a kind of TCP keep alive produced by OpenSIPS?

2016-10-26 Thread Răzvan Crainea


Hi, Rodrigo!

The logs you are tracing are printed when OpenSIPS receives something 
from the client, and then immediately responds back. Due to the fact 
that we don't see any other debug messages, like SIP parsing & stuff, 
makes me think that it is a CRLF pinging - the client periodically sends 
a CRLFCRLF TCP message to OpenSIPS, and OpenSIPS responds with a single 
CRLF. Note that this is different from a TCP keep-alive, where each peer 
send a 0-length TCP message, without any body. That message doesn't even 
get to the application layer.
However, tracing the communication between OpenSIPS and the client 
should confirm the above :).


Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 10/26/2016 05:10 PM, Rodrigo Pimenta Carvalho wrote:


Dear OpenSIPS users,


In the OpenSIPS log I see:


Jan 01 19:30:38 colibri-imx6-jfl opensips[3444]: Jan  1 19:30:38 
[3451] DBG:core:tcp_read_req: Using the global ( per process ) buff
Jan 01 19:30:38 colibri-imx6-jfl opensips[3444]: Jan  1 19:30:38 
[3451] DBG:core:tcp_handle_req: content-length= 0
Jan 01 19:30:38 colibri-imx6-jfl opensips[3444]: Jan  1 19:30:38 
[3451] DBG:core:async_tsend_stream: Async successful write from first 
try on 0x74e13548
Jan 01 19:30:38 colibri-imx6-jfl opensips[3444]: Jan  1 19:30:38 
[3451] DBG:core:tcp_read_req: tcp_read_req end


The frequency is 1 time at each 1,5 minute. There is only one client 
online. I suspect that OpenSIPS uses the socket 0x74e13548 to send 
messages to such client. The client became online using TCP.


Just to confirm, is this log a result of a TCP keep alive function 
enabled?


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

[OpenSIPS-Users] Dialog replication problems

2016-10-26 Thread Dawid Mielnik

Hi All,

I have a reduntant OpenSIPS 2.2.1 setup with clusterer, binary interface
replication and a floating IP. I am encountering a few niuances and am
wondering if I am doing something wrong or if there is a bug.

1) Replicated dialog hash id is different on the standby server from the
active server

active:

dialog::  hash=637:902131071
state:: 4
user_flags:: 0
timestart:: 1477413837
datestart:: 2016-10-25 18:43:57
timeout:: 1477435437
dateout:: 2016-10-26 00:43:57
callid:: 81140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg
...

standby:

dialog::  hash=637:902131072
state:: 4
user_flags:: 0
timestart:: 1477413837
datestart:: 2016-10-25 18:43:57
timeout:: 1477435438
dateout:: 2016-10-26 00:43:58
callid:: 81140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg
...

When a switch overoccurs during a dialog, and a request is received on the
second server the dialog can not be matched by the DID param and has to
fall back to looking for other SIP elements.

DBG:dialog:lookup_dlg: no dialog id=902131071 found on entry 637
DBG:dialog:dlg_onroute: unable to find dialog for BYE with route param
'd72.f7d65c53'

2) No CDR on the standby server after switch over

When a switch over occurs during a dialog CDR is not generated at the end
of the call (I have to do it manually). I to not see any run_dlg_callbacks
info in debug logs although the replicated dialog seems to have all the acc
flags.

active:

dialog::  hash=637:902131071
...
values::
accX_table:: acc
accX_flags:: \x00\x00\x07\x00\x00\x00\x02\x00
accX_db::
\x07\x00\r\x0031.179.202.34\f\x00+48226522655\f\x00+48226522655\x01\x001\f\x00+48501657778\f\x00+48501657778\x02\x0024
accX_leg:: \x00\x00\x00\x00
accX_core::
\x06\x00INVITE\b\x0004027a21\x01\x0030\x0081140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg\x03\x00200\x02\x00OK\x10\x00\xcd\x8b\x0fX\x00\x00\x00\x00]\xb2\x07\x00\x00\x00\x00\x00
...
accX_created:: \xcb\x8b\x0fX\x00\x00\x00\x00
...
standby:

dialog::  hash=637:902131072
...
values::
accX_created:: \xcb\x8b\x0fX\x00\x00\x00\x00
...
accX_core::
\x06\x00INVITE\b\x0004027a21\x01\x0030\x0081140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg\x03\x00200\x02\x00OK\x10\x00\xcd\x8b\x0fX\x00\x00\x00\x00]\xb2\x07\x00\x00\x00\x00\x00
accX_leg:: \x00\x00\x00\x00
accX_db::
\x07\x00\r\x0031.179.202.34\f\x00+48226522655\f\x00+48226522655\x01\x001\f\x00+48501657778\f\x00+48501657778\x02\x0024
accX_flags:: \x00\x00\x07\x00\x00\x00\x02\x00
accX_table:: acc
...

My relevant config:
 DIALOG module
loadmodule "dialog.so"

modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "default_timeout", 21600)  # 6 hours timeout
modparam("dialog", "db_mode", 0)
modparam("dialog", "accept_replicated_dialogs", 1)
modparam("dialog", "replicate_dialogs_to", 1)
#modparam("dialog", "accept_replicated_profiles", 1)
#modparam("dialog", "replicate_profiles_to", 1)
modparam("dialog", "profiles_with_value", "trunkCalls")
modparam("dialog", "options_ping_interval", 60)

 CLUSTERER module
loadmodule "clusterer.so"
modparam("clusterer", "db_url", "text:///usr/local/etc/opensips")
modparam("clusterer", "server_id", 2) #2 or 1 depending on node


# for initial requests
do_accounting("db", "cdr|missed", "acc");


Has anyone experienced similar problems ? Is there something that I am
missing ?

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

[OpenSIPS-Users] Is it a kind of TCP keep alive produced by OpenSIPS?

2016-10-26 Thread Rodrigo Pimenta Carvalho

Dear OpenSIPS users,


In the OpenSIPS log I see:


Jan 01 19:30:38 colibri-imx6-jfl opensips[3444]: Jan  1 19:30:38 [3451] 
DBG:core:tcp_read_req: Using the global ( per process ) buff
Jan 01 19:30:38 colibri-imx6-jfl opensips[3444]: Jan  1 19:30:38 [3451] 
DBG:core:tcp_handle_req: content-length= 0
Jan 01 19:30:38 colibri-imx6-jfl opensips[3444]: Jan  1 19:30:38 [3451] 
DBG:core:async_tsend_stream: Async successful write from first try on 0x74e13548
Jan 01 19:30:38 colibri-imx6-jfl opensips[3444]: Jan  1 19:30:38 [3451] 
DBG:core:tcp_read_req: tcp_read_req end

The frequency is 1 time at each 1,5 minute. There is only one client online. I 
suspect that OpenSIPS uses the socket 0x74e13548 to send messages to such 
client. The client became online using TCP.

Just to confirm, is this log a result of a TCP keep alive function enabled?

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

Re: [OpenSIPS-Users] opensips + rtpproxy bridge on loopback interfaces

2016-10-26 Thread Cédric ML


Hi Razvan,

Le 26/10/2016 à 15:35, Răzvan Crainea a écrit :

Hi, Cedric!

If you double checked the PCAP and you really are missing the flow 
from RTPProxy to callee, I take your word for it. Pehaps the logging 
is misleading.


Now, if RTPProxy does not send any packet to the callee, this means 
that it doesn't get any packets from him. This means that there is 
something wrong with the flow from callee to RTPProxy 
(192.168.157.141:12704 to 192.168.157.121:17226). If you see it in the 
PCAP on the RTPProxy machine, it might be blocked at the firewall level?

There is no firewall anywhere (for testing purpose, of course).
I can see the flow from the callee (192.168.157.141) to rtpproxy 
(192.168.157.121) in the capture, and this flow is relayed correctly to 
the "external" side of rtpproxy.


Another thing that you could try: I saw that you are passing the "a" 
flag to the rtpproxy functions. Do you really need it? Can you try to 
remove it and test again?
I tried this morning : I have the same problem. I've tried with/without 
flags "o" & "c" too.
Tried with rtpproxy on a different host too (adjusting socket parameter, 
of course) : same result.


I'll sent you the last capture I've done a few minutes ago.
Thanks again for your help.
Regards,
Cédric



Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 10/26/2016 03:46 PM, Cédric ML wrote:

Hello Razvan,

Le 26/10/2016 à 13:52, Răzvan Crainea a écrit :

Hi, Cedric!

Are you sure that the flows you do not see are the ones you 
mentioned? According to the logs, you do not see the RTP coming from 
the caller:

RTP stats: 410 in from callee, 0 in from caller
Do these stats work correctly when rtpproxy works in bridge mode ? 
Seems like it only watches on "internal" side of bridge, not on 
"external" side.


Caller is 222.251.208.61 (external side, asterisk server), and callee 
is 192.168.157.141 (internal side, asterisk server too)
stream from 222.251.208.61:18592 to 111.122.100.20:17826 : OK (rtp 
stream from caller to rtpproxy)
stream from 192.168.157.121:17226 to 192.168.157.141:12704 : MISSING 
(rtp stream from rtpproxy to callee)
stream from 192.168.157.141:12704 to 192.168.157.121:17226 : OK (rtp 
stream from callee to rtpproxy)
stream from 111.122.100.20:17826 to 222.251.208.61:18592 : OK (rtp 
stream from rtpproxy to caller)


So the missing flow is RTP from the rtpproxy to the callee.


So the problem seems to be not on the private network, but on the 
public one. Or there is a reporting bug in RTPProxy :).


What's the user experience for this call? Do any of the participants 
hear each other? Also, where are you doing the trace of the RTP?

I'm capturing on the opensips / rtpproxy host.
I can't tell you anything about the user experience, I'm using 
asterisk to generate a call ('originate') and stream a sound file, 
and the callee is an asterisk too, which just answers and plays a 
sound file.


I can send you an example pcap file if you need it.
Thank you for your help !!!
Best regards,
Cédric



Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 10/26/2016 12:35 PM, Cédric ML wrote:
I've made a new test, replacing mediaproxy "external" address by 
111.122.100.18 (which is the SIG address).
It works fine (rtp stream is complete), but that's not what I'm 
trying to do. I need to have a different address for the SIG and 
for the MEDIA.

Hope it helps...
Regards,
Cédric

Le 26/10/2016 à 10:39, Cédric ML a écrit :

Hello,
I'm trying to set up opensips (v2.2.2) and rtpproxy 
(2.0.beta.20150106) one the same server, using loopback interfaces.

--
network config :
lo:2 : inet 111.122.100.18/32 (SIG address)
lo:4 : inet 111.122.100.20/32 (MEDIA address)
eth1 : 192.168.157.121/24
routing :
222.251.208.61 via 192.168.157.1 dev eth1  src 111.122.100.18
222.251.120.61 via 192.168.157.1 dev eth1  src 111.122.100.20

--
opensips setup :
listen=udp:0.0.0.0:5060
loadmodule "rtpproxy.so"

modparam("rtpproxy", "rtpproxy_sock", 
"unix:/var/run/rtpproxy/rtpproxy.sock")


#routing
...
if (is_method("INVITE")) {
t_on_reply("handle_nat");
$rd="192.168.157.141";
if (has_body("application/sdp"))
{
rtpproxy_offer("afeiroc");
}
}
onreply_route[handle_nat] {
if ( has_body("application/sdp") ){
rtpproxy_answer("afieroc");
}
}
...
--
rtpproxy setup :
/usr/local/bin/rtpproxy -s 
unix:/var/run/rtpproxy/rtpproxy.sock -u rtpproxy rtpproxy -p 
/var/run/rtpproxy/rtpproxy.pid -l 192.168.157.121 111.122.100.20 
-d DBUG LOG_LOCAL5 -m 1 -M 2 -w rw

--

When I'm making a call from 222.251.208.61 :
- INVITE arrives on the external side of opensips 
(111.122.100.18), SDP contains 222.251.208.61:18592
- INVITE is relayed on the internal side to

Re: [OpenSIPS-Users] opensips + rtpproxy bridge on loopback interfaces

2016-10-26 Thread Răzvan Crainea


Hi, Cedric!

If you double checked the PCAP and you really are missing the flow from 
RTPProxy to callee, I take your word for it. Pehaps the logging is 
misleading.


Now, if RTPProxy does not send any packet to the callee, this means that 
it doesn't get any packets from him. This means that there is something 
wrong with the flow from callee to RTPProxy (192.168.157.141:12704 to 
192.168.157.121:17226). If you see it in the PCAP on the RTPProxy 
machine, it might be blocked at the firewall level?


Another thing that you could try: I saw that you are passing the "a" 
flag to the rtpproxy functions. Do you really need it? Can you try to 
remove it and test again?


Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 10/26/2016 03:46 PM, Cédric ML wrote:

Hello Razvan,

Le 26/10/2016 à 13:52, Răzvan Crainea a écrit :

Hi, Cedric!

Are you sure that the flows you do not see are the ones you 
mentioned? According to the logs, you do not see the RTP coming from 
the caller:

RTP stats: 410 in from callee, 0 in from caller
Do these stats work correctly when rtpproxy works in bridge mode ? 
Seems like it only watches on "internal" side of bridge, not on 
"external" side.


Caller is 222.251.208.61 (external side, asterisk server), and callee 
is 192.168.157.141 (internal side, asterisk server too)
stream from 222.251.208.61:18592 to 111.122.100.20:17826 : OK (rtp 
stream from caller to rtpproxy)
stream from 192.168.157.121:17226 to 192.168.157.141:12704 : MISSING 
(rtp stream from rtpproxy to callee)
stream from 192.168.157.141:12704 to 192.168.157.121:17226 : OK (rtp 
stream from callee to rtpproxy)
stream from 111.122.100.20:17826 to 222.251.208.61:18592 : OK (rtp 
stream from rtpproxy to caller)


So the missing flow is RTP from the rtpproxy to the callee.


So the problem seems to be not on the private network, but on the 
public one. Or there is a reporting bug in RTPProxy :).


What's the user experience for this call? Do any of the participants 
hear each other? Also, where are you doing the trace of the RTP?

I'm capturing on the opensips / rtpproxy host.
I can't tell you anything about the user experience, I'm using 
asterisk to generate a call ('originate') and stream a sound file, and 
the callee is an asterisk too, which just answers and plays a sound file.


I can send you an example pcap file if you need it.
Thank you for your help !!!
Best regards,
Cédric



Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 10/26/2016 12:35 PM, Cédric ML wrote:
I've made a new test, replacing mediaproxy "external" address by 
111.122.100.18 (which is the SIG address).
It works fine (rtp stream is complete), but that's not what I'm 
trying to do. I need to have a different address for the SIG and for 
the MEDIA.

Hope it helps...
Regards,
Cédric

Le 26/10/2016 à 10:39, Cédric ML a écrit :

Hello,
I'm trying to set up opensips (v2.2.2) and rtpproxy 
(2.0.beta.20150106) one the same server, using loopback interfaces.

--
network config :
lo:2 : inet 111.122.100.18/32 (SIG address)
lo:4 : inet 111.122.100.20/32 (MEDIA address)
eth1 : 192.168.157.121/24
routing :
222.251.208.61 via 192.168.157.1 dev eth1  src 111.122.100.18
222.251.120.61 via 192.168.157.1 dev eth1  src 111.122.100.20

--
opensips setup :
listen=udp:0.0.0.0:5060
loadmodule "rtpproxy.so"

modparam("rtpproxy", "rtpproxy_sock", 
"unix:/var/run/rtpproxy/rtpproxy.sock")


#routing
...
if (is_method("INVITE")) {
t_on_reply("handle_nat");
$rd="192.168.157.141";
if (has_body("application/sdp"))
{
rtpproxy_offer("afeiroc");
}
}
onreply_route[handle_nat] {
if ( has_body("application/sdp") ){
rtpproxy_answer("afieroc");
}
}
...
--
rtpproxy setup :
/usr/local/bin/rtpproxy -s unix:/var/run/rtpproxy/rtpproxy.sock 
-u rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -l 
192.168.157.121 111.122.100.20 -d DBUG LOG_LOCAL5 -m 1 -M 2 
-w rw

--

When I'm making a call from 222.251.208.61 :
- INVITE arrives on the external side of opensips (111.122.100.18), 
SDP contains 222.251.208.61:18592
- INVITE is relayed on the internal side to 192.168.157.141, SDP is 
modified to 192.168.157.121:17226
- 200 OK : 192.168.157.141 replies with a 200 OK, SDP contains 
192.168.157.141:12704
- 200 OK : opensips relays 200 OK to 193.252.208.61, SDP is 
modified to 111.122.100.20:17826


So everything looks good in the SDP.
Now looking to the rtp streams :

stream from 222.251.208.61:18592 to 111.122.100.20:17826 : OK
stream from 192.168.157.121:17226 to 192.168.157.141:12704 : MISSING
stream from 192.168.157.141:12704 to 192.168.157.121:17226 : OK
stream from 111.122.100.20:17826 to 222.251.208.61:18592 : OK

It seems that rtpproxy fails to bridge

Re: [OpenSIPS-Users] opensips + rtpproxy bridge on loopback interfaces

2016-10-26 Thread Cédric ML


Hello Razvan,

Le 26/10/2016 à 13:52, Răzvan Crainea a écrit :

Hi, Cedric!

Are you sure that the flows you do not see are the ones you mentioned? 
According to the logs, you do not see the RTP coming from the caller:

RTP stats: 410 in from callee, 0 in from caller
Do these stats work correctly when rtpproxy works in bridge mode ? Seems 
like it only watches on "internal" side of bridge, not on "external" side.


Caller is 222.251.208.61 (external side, asterisk server), and callee is 
192.168.157.141 (internal side, asterisk server too)
stream from 222.251.208.61:18592 to 111.122.100.20:17826 : OK (rtp 
stream from caller to rtpproxy)
stream from 192.168.157.121:17226 to 192.168.157.141:12704 : MISSING 
(rtp stream from rtpproxy to callee)
stream from 192.168.157.141:12704 to 192.168.157.121:17226 : OK (rtp 
stream from callee to rtpproxy)
stream from 111.122.100.20:17826 to 222.251.208.61:18592 : OK (rtp 
stream from rtpproxy to caller)


So the missing flow is RTP from the rtpproxy to the callee.


So the problem seems to be not on the private network, but on the 
public one. Or there is a reporting bug in RTPProxy :).


What's the user experience for this call? Do any of the participants 
hear each other? Also, where are you doing the trace of the RTP?

I'm capturing on the opensips / rtpproxy host.
I can't tell you anything about the user experience, I'm using asterisk 
to generate a call ('originate') and stream a sound file, and the callee 
is an asterisk too, which just answers and plays a sound file.


I can send you an example pcap file if you need it.
Thank you for your help !!!
Best regards,
Cédric



Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 10/26/2016 12:35 PM, Cédric ML wrote:
I've made a new test, replacing mediaproxy "external" address by 
111.122.100.18 (which is the SIG address).
It works fine (rtp stream is complete), but that's not what I'm 
trying to do. I need to have a different address for the SIG and for 
the MEDIA.

Hope it helps...
Regards,
Cédric

Le 26/10/2016 à 10:39, Cédric ML a écrit :

Hello,
I'm trying to set up opensips (v2.2.2) and rtpproxy 
(2.0.beta.20150106) one the same server, using loopback interfaces.

--
network config :
lo:2 : inet 111.122.100.18/32 (SIG address)
lo:4 : inet 111.122.100.20/32 (MEDIA address)
eth1 : 192.168.157.121/24
routing :
222.251.208.61 via 192.168.157.1 dev eth1  src 111.122.100.18
222.251.120.61 via 192.168.157.1 dev eth1  src 111.122.100.20

--
opensips setup :
listen=udp:0.0.0.0:5060
loadmodule "rtpproxy.so"

modparam("rtpproxy", "rtpproxy_sock", 
"unix:/var/run/rtpproxy/rtpproxy.sock")


#routing
...
if (is_method("INVITE")) {
t_on_reply("handle_nat");
$rd="192.168.157.141";
if (has_body("application/sdp"))
{
rtpproxy_offer("afeiroc");
}
}
onreply_route[handle_nat] {
if ( has_body("application/sdp") ){
rtpproxy_answer("afieroc");
}
}
...
--
rtpproxy setup :
/usr/local/bin/rtpproxy -s unix:/var/run/rtpproxy/rtpproxy.sock 
-u rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -l 
192.168.157.121 111.122.100.20 -d DBUG LOG_LOCAL5 -m 1 -M 2 
-w rw

--

When I'm making a call from 222.251.208.61 :
- INVITE arrives on the external side of opensips (111.122.100.18), 
SDP contains 222.251.208.61:18592
- INVITE is relayed on the internal side to 192.168.157.141, SDP is 
modified to 192.168.157.121:17226
- 200 OK : 192.168.157.141 replies with a 200 OK, SDP contains 
192.168.157.141:12704
- 200 OK : opensips relays 200 OK to 193.252.208.61, SDP is modified 
to 111.122.100.20:17826


So everything looks good in the SDP.
Now looking to the rtp streams :

stream from 222.251.208.61:18592 to 111.122.100.20:17826 : OK
stream from 192.168.157.121:17226 to 192.168.157.141:12704 : MISSING
stream from 192.168.157.141:12704 to 192.168.157.121:17226 : OK
stream from 111.122.100.20:17826 to 222.251.208.61:18592 : OK

It seems that rtpproxy fails to bridge the "external -> internal" 
part of the media.



rtpproxy debug :
Oct 26 10:05:04 localhost rtpproxy[775]: DBUG:get_command:GLOBAL: 
received command "UAEIc8,101 
36fe8745364f35b61411304154da2db3@222.251.208.61:5060 222.251.208.61 
18592 as5f5f1868;1"
Oct 26 10:05:04 localhost rtpproxy[775]: 
INFO:rtpp_command_ul_handle:GLOBAL: new session 
36fe8745364f35b61411304154da2db3@222.251.208.61:5060, tag 
as5f5f1868;1 requested, type strong
Oct 26 10:05:04 localhost rtpproxy[775]: 
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
new session on a port 17226 created, tag as5f5f1868;1
Oct 26 10:05:04 localhost rtpproxy[775]: 
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
pre-filling caller's address with 222.251.208.61:18592

Re: [OpenSIPS-Users] opensips + rtpproxy bridge on loopback interfaces

2016-10-26 Thread Răzvan Crainea


Hi, Cedric!

Are you sure that the flows you do not see are the ones you mentioned? 
According to the logs, you do not see the RTP coming from the caller:

RTP stats: 410 in from callee, 0 in from caller

So the problem seems to be not on the private network, but on the public 
one. Or there is a reporting bug in RTPProxy :).


What's the user experience for this call? Do any of the participants 
hear each other? Also, where are you doing the trace of the RTP?


Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 10/26/2016 12:35 PM, Cédric ML wrote:
I've made a new test, replacing mediaproxy "external" address by 
111.122.100.18 (which is the SIG address).
It works fine (rtp stream is complete), but that's not what I'm trying 
to do. I need to have a different address for the SIG and for the MEDIA.

Hope it helps...
Regards,
Cédric

Le 26/10/2016 à 10:39, Cédric ML a écrit :

Hello,
I'm trying to set up opensips (v2.2.2) and rtpproxy 
(2.0.beta.20150106) one the same server, using loopback interfaces.

--
network config :
lo:2 : inet 111.122.100.18/32 (SIG address)
lo:4 : inet 111.122.100.20/32 (MEDIA address)
eth1 : 192.168.157.121/24
routing :
222.251.208.61 via 192.168.157.1 dev eth1  src 111.122.100.18
222.251.120.61 via 192.168.157.1 dev eth1  src 111.122.100.20

--
opensips setup :
listen=udp:0.0.0.0:5060
loadmodule "rtpproxy.so"

modparam("rtpproxy", "rtpproxy_sock", 
"unix:/var/run/rtpproxy/rtpproxy.sock")


#routing
...
if (is_method("INVITE")) {
t_on_reply("handle_nat");
$rd="192.168.157.141";
if (has_body("application/sdp"))
{
rtpproxy_offer("afeiroc");
}
}
onreply_route[handle_nat] {
if ( has_body("application/sdp") ){
rtpproxy_answer("afieroc");
}
}
...
--
rtpproxy setup :
/usr/local/bin/rtpproxy -s unix:/var/run/rtpproxy/rtpproxy.sock 
-u rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -l 
192.168.157.121 111.122.100.20 -d DBUG LOG_LOCAL5 -m 1 -M 2 
-w rw

--

When I'm making a call from 222.251.208.61 :
- INVITE arrives on the external side of opensips (111.122.100.18), 
SDP contains 222.251.208.61:18592
- INVITE is relayed on the internal side to 192.168.157.141, SDP is 
modified to 192.168.157.121:17226
- 200 OK : 192.168.157.141 replies with a 200 OK, SDP contains 
192.168.157.141:12704
- 200 OK : opensips relays 200 OK to 193.252.208.61, SDP is modified 
to 111.122.100.20:17826


So everything looks good in the SDP.
Now looking to the rtp streams :

stream from 222.251.208.61:18592 to 111.122.100.20:17826 : OK
stream from 192.168.157.121:17226 to 192.168.157.141:12704 : MISSING
stream from 192.168.157.141:12704 to 192.168.157.121:17226 : OK
stream from 111.122.100.20:17826 to 222.251.208.61:18592 : OK

It seems that rtpproxy fails to bridge the "external -> internal" 
part of the media.



rtpproxy debug :
Oct 26 10:05:04 localhost rtpproxy[775]: DBUG:get_command:GLOBAL: 
received command "UAEIc8,101 
36fe8745364f35b61411304154da2db3@222.251.208.61:5060 222.251.208.61 
18592 as5f5f1868;1"
Oct 26 10:05:04 localhost rtpproxy[775]: 
INFO:rtpp_command_ul_handle:GLOBAL: new session 
36fe8745364f35b61411304154da2db3@222.251.208.61:5060, tag 
as5f5f1868;1 requested, type strong
Oct 26 10:05:04 localhost rtpproxy[775]: 
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
new session on a port 17226 created, tag as5f5f1868;1
Oct 26 10:05:04 localhost rtpproxy[775]: 
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
pre-filling caller's address with 222.251.208.61:18592
Oct 26 10:05:04 localhost rtpproxy[775]: DBUG:rtpc_doreply:GLOBAL: 
sending reply "17226 192.168.157.121#012"
Oct 26 10:05:05 localhost rtpproxy[775]: DBUG:get_command:GLOBAL: 
received command "LAIEc8,101 
36fe8745364f35b61411304154da2db3@222.251.208.61:5060 192.168.157.141 
12704 as5f5f1868;1 as200acccf;1"
Oct 26 10:05:05 localhost rtpproxy[775]: 
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
lookup on ports 17226/17826, session timer restarted
Oct 26 10:05:05 localhost rtpproxy[775]: 
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
pre-filling callee's address with 192.168.157.141:12704
Oct 26 10:05:05 localhost rtpproxy[775]: DBUG:rtpc_doreply:GLOBAL: 
sending reply "17826 111.122.100.20#012"
Oct 26 10:05:13 localhost rtpproxy[775]: DBUG:get_command:GLOBAL: 
received command "D 
36fe8745364f35b61411304154da2db3@222.251.208.61:5060 as5f5f1868 
as200acccf"
Oct 26 10:05:13 localhost rtpproxy[775]: 
INFO:handle_delete:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
forcefully deleting session 1 on ports 17226/17826
Oct 26 10:05:13 localhost rtpproxy[775]:

Re: [OpenSIPS-Users] opensips + rtpproxy bridge on loopback interfaces

2016-10-26 Thread Cédric ML

I've made a new test, replacing mediaproxy "external" address by 
111.122.100.18 (which is the SIG address).
It works fine (rtp stream is complete), but that's not what I'm trying 
to do. I need to have a different address for the SIG and for the MEDIA.

Hope it helps...
Regards,
Cédric

Le 26/10/2016 à 10:39, Cédric ML a écrit :

Hello,
I'm trying to set up opensips (v2.2.2) and rtpproxy 
(2.0.beta.20150106) one the same server, using loopback interfaces.

--
network config :
lo:2 : inet 111.122.100.18/32 (SIG address)
lo:4 : inet 111.122.100.20/32 (MEDIA address)
eth1 : 192.168.157.121/24
routing :
222.251.208.61 via 192.168.157.1 dev eth1  src 111.122.100.18
222.251.120.61 via 192.168.157.1 dev eth1  src 111.122.100.20

--
opensips setup :
listen=udp:0.0.0.0:5060
loadmodule "rtpproxy.so"

modparam("rtpproxy", "rtpproxy_sock", 
"unix:/var/run/rtpproxy/rtpproxy.sock")


#routing
...
if (is_method("INVITE")) {
t_on_reply("handle_nat");
$rd="192.168.157.141";
if (has_body("application/sdp"))
{
rtpproxy_offer("afeiroc");
}
}
onreply_route[handle_nat] {
if ( has_body("application/sdp") ){
rtpproxy_answer("afieroc");
}
}
...
--
rtpproxy setup :
/usr/local/bin/rtpproxy -s unix:/var/run/rtpproxy/rtpproxy.sock -u 
rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -l 192.168.157.121 
111.122.100.20 -d DBUG LOG_LOCAL5 -m 1 -M 2 -w rw

--

When I'm making a call from 222.251.208.61 :
- INVITE arrives on the external side of opensips (111.122.100.18), 
SDP contains 222.251.208.61:18592
- INVITE is relayed on the internal side to 192.168.157.141, SDP is 
modified to 192.168.157.121:17226
- 200 OK : 192.168.157.141 replies with a 200 OK, SDP contains 
192.168.157.141:12704
- 200 OK : opensips relays 200 OK to 193.252.208.61, SDP is modified 
to 111.122.100.20:17826


So everything looks good in the SDP.
Now looking to the rtp streams :

stream from 222.251.208.61:18592 to 111.122.100.20:17826 : OK
stream from 192.168.157.121:17226 to 192.168.157.141:12704 : MISSING
stream from 192.168.157.141:12704 to 192.168.157.121:17226 : OK
stream from 111.122.100.20:17826 to 222.251.208.61:18592 : OK

It seems that rtpproxy fails to bridge the "external -> internal" part 
of the media.



rtpproxy debug :
Oct 26 10:05:04 localhost rtpproxy[775]: DBUG:get_command:GLOBAL: 
received command "UAEIc8,101 
36fe8745364f35b61411304154da2db3@222.251.208.61:5060 222.251.208.61 
18592 as5f5f1868;1"
Oct 26 10:05:04 localhost rtpproxy[775]: 
INFO:rtpp_command_ul_handle:GLOBAL: new session 
36fe8745364f35b61411304154da2db3@222.251.208.61:5060, tag as5f5f1868;1 
requested, type strong
Oct 26 10:05:04 localhost rtpproxy[775]: 
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
new session on a port 17226 created, tag as5f5f1868;1
Oct 26 10:05:04 localhost rtpproxy[775]: 
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
pre-filling caller's address with 222.251.208.61:18592
Oct 26 10:05:04 localhost rtpproxy[775]: DBUG:rtpc_doreply:GLOBAL: 
sending reply "17226 192.168.157.121#012"
Oct 26 10:05:05 localhost rtpproxy[775]: DBUG:get_command:GLOBAL: 
received command "LAIEc8,101 
36fe8745364f35b61411304154da2db3@222.251.208.61:5060 192.168.157.141 
12704 as5f5f1868;1 as200acccf;1"
Oct 26 10:05:05 localhost rtpproxy[775]: 
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
lookup on ports 17226/17826, session timer restarted
Oct 26 10:05:05 localhost rtpproxy[775]: 
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
pre-filling callee's address with 192.168.157.141:12704
Oct 26 10:05:05 localhost rtpproxy[775]: DBUG:rtpc_doreply:GLOBAL: 
sending reply "17826 111.122.100.20#012"
Oct 26 10:05:13 localhost rtpproxy[775]: DBUG:get_command:GLOBAL: 
received command "D 
36fe8745364f35b61411304154da2db3@222.251.208.61:5060 as5f5f1868 
as200acccf"
Oct 26 10:05:13 localhost rtpproxy[775]: 
INFO:handle_delete:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
forcefully deleting session 1 on ports 17226/17826
Oct 26 10:05:13 localhost rtpproxy[775]: 
INFO:remove_session:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
RTP stats: 410 in from callee, 0 in from caller, 410 relayed, 0 dropped
Oct 26 10:05:13 localhost rtpproxy[775]: 
INFO:remove_session:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
RTCP stats: 1 in from callee, 0 in from caller, 1 relayed, 0 dropped
Oct 26 10:05:13 localhost rtpproxy[775]: 
INFO:remove_session:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
session on ports 17226/17826 is cleaned up
Oct 26 10:05:13 localhost rtpproxy[775]: DBUG:rtpc_doreply:GLOBAL: 
sending reply "0#012"



I can't figure out what's

[OpenSIPS-Users] opensips + rtpproxy bridge on loopback interfaces

2016-10-26 Thread Cédric ML


Hello,
I'm trying to set up opensips (v2.2.2) and rtpproxy (2.0.beta.20150106) 
one the same server, using loopback interfaces.

--
network config :
lo:2 : inet 111.122.100.18/32 (SIG address)
lo:4 : inet 111.122.100.20/32 (MEDIA address)
eth1 : 192.168.157.121/24
routing :
222.251.208.61 via 192.168.157.1 dev eth1  src 111.122.100.18
222.251.120.61 via 192.168.157.1 dev eth1  src 111.122.100.20

--
opensips setup :
listen=udp:0.0.0.0:5060
loadmodule "rtpproxy.so"

modparam("rtpproxy", "rtpproxy_sock", 
"unix:/var/run/rtpproxy/rtpproxy.sock")


#routing
...
if (is_method("INVITE")) {
t_on_reply("handle_nat");
$rd="192.168.157.141";
if (has_body("application/sdp"))
{
rtpproxy_offer("afeiroc");
}
}
onreply_route[handle_nat] {
if ( has_body("application/sdp") ){
rtpproxy_answer("afieroc");
}
}
...
--
rtpproxy setup :
/usr/local/bin/rtpproxy -s unix:/var/run/rtpproxy/rtpproxy.sock -u 
rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -l 192.168.157.121 
111.122.100.20 -d DBUG LOG_LOCAL5 -m 1 -M 2 -w rw

--

When I'm making a call from 222.251.208.61 :
- INVITE arrives on the external side of opensips (111.122.100.18), SDP 
contains 222.251.208.61:18592
- INVITE is relayed on the internal side to 192.168.157.141, SDP is 
modified to 192.168.157.121:17226
- 200 OK : 192.168.157.141 replies with a 200 OK, SDP contains 
192.168.157.141:12704
- 200 OK : opensips relays 200 OK to 193.252.208.61, SDP is modified to 
111.122.100.20:17826


So everything looks good in the SDP.
Now looking to the rtp streams :

stream from 222.251.208.61:18592 to 111.122.100.20:17826 : OK
stream from 192.168.157.121:17226 to 192.168.157.141:12704 : MISSING
stream from 192.168.157.141:12704 to 192.168.157.121:17226 : OK
stream from 111.122.100.20:17826 to 222.251.208.61:18592 : OK

It seems that rtpproxy fails to bridge the "external -> internal" part 
of the media.



rtpproxy debug :
Oct 26 10:05:04 localhost rtpproxy[775]: DBUG:get_command:GLOBAL: 
received command "UAEIc8,101 
36fe8745364f35b61411304154da2db3@222.251.208.61:5060 222.251.208.61 
18592 as5f5f1868;1"
Oct 26 10:05:04 localhost rtpproxy[775]: 
INFO:rtpp_command_ul_handle:GLOBAL: new session 
36fe8745364f35b61411304154da2db3@222.251.208.61:5060, tag as5f5f1868;1 
requested, type strong
Oct 26 10:05:04 localhost rtpproxy[775]: 
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
new session on a port 17226 created, tag as5f5f1868;1
Oct 26 10:05:04 localhost rtpproxy[775]: 
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
pre-filling caller's address with 222.251.208.61:18592
Oct 26 10:05:04 localhost rtpproxy[775]: DBUG:rtpc_doreply:GLOBAL: 
sending reply "17226 192.168.157.121#012"
Oct 26 10:05:05 localhost rtpproxy[775]: DBUG:get_command:GLOBAL: 
received command "LAIEc8,101 
36fe8745364f35b61411304154da2db3@222.251.208.61:5060 192.168.157.141 
12704 as5f5f1868;1 as200acccf;1"
Oct 26 10:05:05 localhost rtpproxy[775]: 
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
lookup on ports 17226/17826, session timer restarted
Oct 26 10:05:05 localhost rtpproxy[775]: 
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
pre-filling callee's address with 192.168.157.141:12704
Oct 26 10:05:05 localhost rtpproxy[775]: DBUG:rtpc_doreply:GLOBAL: 
sending reply "17826 111.122.100.20#012"
Oct 26 10:05:13 localhost rtpproxy[775]: DBUG:get_command:GLOBAL: 
received command "D 36fe8745364f35b61411304154da2db3@222.251.208.61:5060 
as5f5f1868 as200acccf"
Oct 26 10:05:13 localhost rtpproxy[775]: 
INFO:handle_delete:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
forcefully deleting session 1 on ports 17226/17826
Oct 26 10:05:13 localhost rtpproxy[775]: 
INFO:remove_session:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
RTP stats: 410 in from callee, 0 in from caller, 410 relayed, 0 dropped
Oct 26 10:05:13 localhost rtpproxy[775]: 
INFO:remove_session:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
RTCP stats: 1 in from callee, 0 in from caller, 1 relayed, 0 dropped
Oct 26 10:05:13 localhost rtpproxy[775]: 
INFO:remove_session:36fe8745364f35b61411304154da2db3@222.251.208.61:5060: 
session on ports 17226/17826 is cleaned up
Oct 26 10:05:13 localhost rtpproxy[775]: DBUG:rtpc_doreply:GLOBAL: 
sending reply "0#012"



I can't figure out what's wrong in my config. Can you please help me ?
Should I post this message on rtpproxy mailing list too ?
Best regards,
Cédric

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

[OpenSIPS-Users] sippy rtp_cluster usage

2016-10-26 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

[OpenSIPS-Users] OpenSIPS reopen TCP connectios and sends INVITE, but not BYE. How to change it?

Re: [OpenSIPS-Users] How to ensure current IPV6 listening address

Re: [OpenSIPS-Users] How to ensure current IPV6 listening address

Re: [OpenSIPS-Users] Is it a kind of TCP keep alive produced by OpenSIPS?

Re: [OpenSIPS-Users] Is it a kind of TCP keep alive produced by OpenSIPS?

[OpenSIPS-Users] Dialog replication problems

[OpenSIPS-Users] Is it a kind of TCP keep alive produced by OpenSIPS?

Re: [OpenSIPS-Users] opensips + rtpproxy bridge on loopback interfaces

Re: [OpenSIPS-Users] opensips + rtpproxy bridge on loopback interfaces

Re: [OpenSIPS-Users] opensips + rtpproxy bridge on loopback interfaces

Re: [OpenSIPS-Users] opensips + rtpproxy bridge on loopback interfaces

Re: [OpenSIPS-Users] opensips + rtpproxy bridge on loopback interfaces

[OpenSIPS-Users] opensips + rtpproxy bridge on loopback interfaces

[OpenSIPS-Users] sippy rtp_cluster usage

14 matches

Site Navigation

Mail list logo

Footer information