-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
does anybody know, if openser+rtpproxy are able to detect rtp-timeouts and react on them? It would be good for billing.
regards Helmut
As far as I know, nope. However, the much slower and bloated (in my opinion) mediaproxy does exactly this and even more in terms of "billing safeties".
On Thu, 2008-01-10 at 16:11 +0100, Helmut Kuper wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
does anybody know, if openser+rtpproxy are able to detect rtp-timeouts and react on them? It would be good for billing.
regards Helmut -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHhjWa4tZeNddg3dwRAmZcAJkBmJGh6b2qt/6NbFri0mBZU9BwPQCeNYNS Pb+u2IWB4Xp2K8G9fHkQKyo= =MxAh -----END PGP SIGNATURE-----
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Jérôme Martin | LongPhone Responsable Architecture Réseau 122, rue la Boetie | 75008 Paris Tel : +33 (0)1 56 26 28 44 Fax : +33 (0)1 56 26 28 45 Mail : jmartin@longphone.fr Web : www.longphone.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
yeah, I know. Mediaproxy does this as far as I know, but I fear it's just to slow for larger installation. I currently think of openSBC to do this, but it seems to be a bit unstable. I read about a patch for rtpproxy to send rtp-timeouts through a unix sock to a application. So this could be a way to solv my problem without introducing a slow proxy.
http://osdir.com/ml/linux.debian.packages.voip.devel/2006-04/msg00170.html
regards Helmut
Jerome Martin schrieb: | As far as I know, nope. | However, the much slower and bloated (in my opinion) mediaproxy does | exactly this and even more in terms of "billing safeties". | | On Thu, 2008-01-10 at 16:11 +0100, Helmut Kuper wrote: | Hello, | | does anybody know, if openser+rtpproxy are able to detect rtp-timeouts | and react on them? It would be good for billing. | | regards | Helmut |> _______________________________________________ Users mailing list Users@lists.openser.org mailto:Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
| *Jérôme Martin **| **LongPhone* | *Responsable Architecture Réseau* | 122, rue la Boetie | 75008 Paris | Tel : +33 (0)1 56 26 28 44 | Fax : +33 (0)1 56 26 28 45 | Mail : *jmartin*@longphone.fr | Web : www.longphone.com http://www.longphone.com
Helmut Kuper wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
yeah, I know. Mediaproxy does this as far as I know, but I fear it's just to slow for larger installation. I currently think of openSBC to do this, but it seems to be a bit unstable.
Grr - Do it the right way and use Asterisk - doing both RTP proxying (if its even necessary) and call accounting in Asterisk.
Jeremy McNamara
On Thursday 10 January 2008 17:49:01 Jeremy McNamara wrote:
yeah, I know. Mediaproxy does this as far as I know, but I fear it's just to slow for larger installation. I currently think of openSBC to do this, but it seems to be a bit unstable.
Grr - Do it the right way and use Asterisk - doing both RTP proxying (if its even necessary) and call accounting in Asterisk.
IMHO Asterisk for CDR without RTP proxing is insane, at least until Session Timers are implemented (I know there is already code about it). CDR should always be managed by a system knowing the state of the RTP.
Anyone using Asterisk for both RTP proxying and CDR in a **large** installation as VoIP provider?
Iñaki Baz Castillo wrote:
IMHO Asterisk for CDR without RTP proxing is insane, at least until Session Timers are implemented (I know there is already code about it). CDR should always be managed by a system knowing the state of the RTP.
Anyone using Asterisk for both RTP proxying and CDR in a **large** installation as VoIP provider?
I have provided consulting services for 5 or 6 major VoIP providers that run OpenSER+Asterisk and do RTP and CDRs within Asterisk.
The secret is in the sauce.
Jeremy McNamara
On Thu, 2008-01-10 at 18:06 +0100, Iñaki Baz Castillo wrote:
CDR should always be managed by a system knowing the state of the RTP.
I don't agree. This is a myth if you ask me. The only proper way to garantee that an UAC is still alive is to make sure it is responsive to signaling. What you care about in that context is signaling (BYE _is_ signaling).
RTP detection can help, but I consider this an ugly workaround when used alone. What happens when someone hit the "secret" key on his phone with blank compressions enabled and go get a coffee cup ? What happens for SIP sessions without RTP ? Or one-way RTP only ?
Also, when your installations gets serious, you have MANY situations where you want to optimize RTP path. Sometimes you want to avoid RTP proxying completely.
To summarize, I'd say that if you rely on RTP detection for billing, then you have the following limitations : - unreliable problem detection - stuck with RTP proxying for ALL calls - problems with VAD - problems in corner cases with re INVITES changing the RTP stream extremities
What do you think ?
BTW, I work for a telco, so YMMV. In a setup with only one or two million minutes per month, well I supose this might be a different story.
Regards,
Hi !
I´m having problem to running RTPPROXY. Please, someone help me ?
Logs bellow:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-> SIP Logs
Jan 10 15:45:14 src@sip2 /usr/sbin/openser[19438]: WARNING: rtpp_test: can't get version of the RTP proxy Jan 10 15:45:14 src@sip2 /usr/sbin/openser[19438]: WARNING: rtpp_test: support for RTP proxy udp:200.176.6.90:8899has been disabled temporarily
Jan 10 15:45:14 src@sip2 /usr/sbin/openser[19408]: ERROR: send_rtpp_command: can't send command to a RTP proxy Jan 10 15:45:14 src@sip2 /usr/sbin/openser[19408]: send_rtpp_command(): proxy udp:200.176.6.90:8899 does not responding, disable it
Jan 10 15:45:14 src@sip2 /usr/sbin/openser[19408]: WARNING: rtpp_test: can't get version of the RTP proxy Jan 10 15:45:14 src@sip2 /usr/sbin/openser[19408]: WARNING: rtpp_test: support for RTP proxy udp:200.176.6.90:8899has been disabled temporarily
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[openser.cfg]
# ------------- !! Nathelper
modparam("registrar", "nat_flag", 6) modparam("nathelper", "natping_interval", 30) # Ping interval 30 s modparam("nathelper", "ping_nated_only", 1) # Ping only clients behind NAT modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") # Nathelper with RTPproxy modparam("nathelper", "rtpproxy_sock", "udp:xxx.xxx.xxx.xxx:8899") modparam("nathelper", "rtpproxy_disable_tout", 30) modparam("nathelper", "rtpproxy_tout", 2) modparam("nathelper", "rtpproxy_retr", 10)
# -------------
[root@sip2 run]# rpm -qa | grep rtp rtpproxy-0.3-1.fc5
[root@sip2 run]# netstat -axep |grep rtpproxy unix 2 [ ACC ] STREAM LISTENING 8070094 19061/rtpproxy /var/run/rtpproxy.sock
[root@sip2 run]# ls -al rtpproxy.sock srwxr-xr-x 1 root root 0 Jan 10 15:44 rtpproxy.sock
[root@sip2 run]# ps -aux | grep rtp Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.6/FAQ root 19061 0.0 0.0 2532 344 ? Ss 15:44 0:00 /usr/bin/rtpproxy root 19080 0.0 0.0 2532 344 ? Ss 15:44 0:00 /usr/bin/rtpproxy -l xxx.xxx.xxx.xxx -s udp:xxx.xxx.xxx.xxx 8899
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Hi.
My remarks below.
On Thu, 2008-01-10 at 16:06 -0200, Jeferson Prevedello wrote:
Hi !
I´m having problem to running RTPPROXY. Please, someone help me ?
Logs bellow:
Removed the logs from the answer as you IPs are in clear there.
[openser.cfg]
# ------------- !! Nathelper
modparam("registrar", "nat_flag", 6) modparam("nathelper", "natping_interval", 30) # Ping interval 30 s modparam("nathelper", "ping_nated_only", 1) # Ping only clients behind NAT modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") # Nathelper with RTPproxy modparam("nathelper", "rtpproxy_sock", "udp:xxx.xxx.xxx.xxx:8899")
I would first try to remove the unix-socket rtpproxy_sock declaration, even though you log messages tend to let one think openser is using only the second one (UDP).
modparam("nathelper", "rtpproxy_disable_tout", 30) modparam("nathelper", "rtpproxy_tout", 2) modparam("nathelper", "rtpproxy_retr", 10)
# -------------
[root@sip2 run]# rpm -qa | grep rtp rtpproxy-0.3-1.fc5
[root@sip2 run]# netstat -axep |grep rtpproxy unix 2 [ ACC ] STREAM LISTENING 8070094 19061/rtpproxy /var/run/rtpproxy.sock
[root@sip2 run]# ls -al rtpproxy.sock srwxr-xr-x 1 root root 0 Jan 10 15:44 rtpproxy.sock
[root@sip2 run]# ps -aux | grep rtp
if you want to use "-" options a la systemV, use "ps -eaf" to achieve the same than the BSD-style "ps aux" :-)
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.6/FAQ root 19061 0.0 0.0 2532 344 ? Ss 15:44 0:00 /usr/bin/rtpproxy root 19080 0.0 0.0 2532 344 ? Ss 15:44 0:00 /usr/bin/rtpproxy -l xxx.xxx.xxx.xxx -s udp:xxx.xxx.xxx.xxx 8899
There is a missing ":" between the ip and the port. Try to use -l xxx.xxx.xxx.xxx -s udp:xxx.xxx.xxx.xxx:8899
Tell us if this helps.
Regards,
I think I was too fast there.
On Thu, 2008-01-10 at 19:19 +0100, Jerome Martin wrote:
Hi.
My remarks below.
On Thu, 2008-01-10 at 16:06 -0200, Jeferson Prevedello wrote:
Hi !
I´m having problem to running RTPPROXY. Please, someone help me ?
Logs bellow:
Removed the logs from the answer as you IPs are in clear there.
[openser.cfg]
# ------------- !! Nathelper
modparam("registrar", "nat_flag", 6) modparam("nathelper", "natping_interval", 30) # Ping interval 30 s modparam("nathelper", "ping_nated_only", 1) # Ping only clients behind NAT modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") # Nathelper with RTPproxy modparam("nathelper", "rtpproxy_sock", "udp:xxx.xxx.xxx.xxx:8899")
I would first try to remove the unix-socket rtpproxy_sock declaration, even though you log messages tend to let one think openser is using only the second one (UDP).
modparam("nathelper", "rtpproxy_disable_tout", 30) modparam("nathelper", "rtpproxy_tout", 2) modparam("nathelper", "rtpproxy_retr", 10)
# -------------
[root@sip2 run]# rpm -qa | grep rtp rtpproxy-0.3-1.fc5
[root@sip2 run]# netstat -axep |grep rtpproxy unix 2 [ ACC ] STREAM LISTENING 8070094 19061/rtpproxy /var/run/rtpproxy.sock
Your netstat is the primary reason to make me believe rtpproxy was not launched with proper parameters. You would not catch the udp socket rtpproxy uses with the netstat options you provided, but here it seems your running proxy is waiting for control on a unix socket. And rtpproxy cannot listen both on udp AND unixsocket. You need to choose udp or unixsocket both in openser.cfg and in rtpproxy commandline.
[root@sip2 run]# ls -al rtpproxy.sock srwxr-xr-x 1 root root 0 Jan 10 15:44 rtpproxy.sock
[root@sip2 run]# ps -aux | grep rtp
if you want to use "-" options a la systemV, use "ps -eaf" to achieve the same than the BSD-style "ps aux" :-)
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.6/FAQ root 19061 0.0 0.0 2532 344 ? Ss 15:44 0:00 /usr/bin/rtpproxy root 19080 0.0 0.0 2532 344 ? Ss 15:44 0:00 /usr/bin/rtpproxy -l xxx.xxx.xxx.xxx -s udp:xxx.xxx.xxx.xxx 8899
Are you sure the ps and the netstat are from the same machine ? What does cat /proc/19080/cmdline | tr "\0" "\n" gives you ? Would you by chance have a second -s option after the first one, truncated by ps, which would be taken into account instead of the udp socket ? That would explain your netstat result.
There is a missing ":" between the ip and the port. Try to use -l xxx.xxx.xxx.xxx -s udp:xxx.xxx.xxx.xxx:8899
In fact, command line syntax for -s option is udp:ip:port. If you omit the ":" between ip and port, there will be no warning, and rtpproxy will listen (for the original version, dunno for fedora versions) on port 22222. But the behavior might be different on your version. Note that I cannot be 100% sure that you got that one wrong here because indead, even if you use the proper syntax, rtpproxy does not report the ":" in the commandline"
Thanks Jérôme! :-)
I comment the following lines in the openser.cfg file:
#modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") # Nathelper with RTPproxy #modparam("nathelper", "rtpproxy_sock", "udp:200.176.6.90:8899")
And started the rtpproxy with the following command:
/usr/bin/rtpproxy -l 200.176.6.90 -s udp:200.176.6.90:8899
Logs:
Jan 10 18:04:26 src@sip2 /usr/sbin/openser[2805]: rtpp_test: RTP proxy unix:/var/run/rtpproxy.sock found, support for it enabled
Unfortunately I still have a problem that I believe to be related to rtpproxy. When I make calls through of a branch connect the openser exists audio in both directions, but when I receive calls not have audio on any of directions.
Any suggestion ?
Regards Jeferson
-----Mensagem original----- De: Jerome Martin [mailto:jmartin@longphone.fr] Enviada em: quinta-feira, 10 de janeiro de 2008 16:39 Para: Jeferson Prevedello Cc: users@lists.openser.org Assunto: Re: [OpenSER-Users] Problems with RTP-Proxy
I think I was too fast there.
On Thu, 2008-01-10 at 19:19 +0100, Jerome Martin wrote:
Hi.
My remarks below.
On Thu, 2008-01-10 at 16:06 -0200, Jeferson Prevedello wrote:
Hi !
I´m having problem to running RTPPROXY. Please, someone help me ?
Logs bellow:
Removed the logs from the answer as you IPs are in clear there.
[openser.cfg]
# ------------- !! Nathelper
modparam("registrar", "nat_flag", 6) modparam("nathelper", "natping_interval", 30) # Ping interval 30 s modparam("nathelper", "ping_nated_only", 1) # Ping only clients behind NAT modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") # Nathelper with RTPproxy modparam("nathelper", "rtpproxy_sock", "udp:xxx.xxx.xxx.xxx:8899")
I would first try to remove the unix-socket rtpproxy_sock declaration, even though you log messages tend to let one think openser is using only the second one (UDP).
modparam("nathelper", "rtpproxy_disable_tout", 30) modparam("nathelper", "rtpproxy_tout", 2) modparam("nathelper", "rtpproxy_retr", 10)
# -------------
[root@sip2 run]# rpm -qa | grep rtp rtpproxy-0.3-1.fc5
[root@sip2 run]# netstat -axep |grep rtpproxy unix 2 [ ACC ] STREAM LISTENING 8070094 19061/rtpproxy /var/run/rtpproxy.sock
Your netstat is the primary reason to make me believe rtpproxy was not launched with proper parameters. You would not catch the udp socket rtpproxy uses with the netstat options you provided, but here it seems your running proxy is waiting for control on a unix socket. And rtpproxy cannot listen both on udp AND unixsocket. You need to choose udp or unixsocket both in openser.cfg and in rtpproxy commandline.
[root@sip2 run]# ls -al rtpproxy.sock srwxr-xr-x 1 root root 0 Jan 10 15:44 rtpproxy.sock
[root@sip2 run]# ps -aux | grep rtp
if you want to use "-" options a la systemV, use "ps -eaf" to achieve the same than the BSD-style "ps aux" :-)
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.6/FAQ root 19061 0.0 0.0 2532 344 ? Ss 15:44 0:00 /usr/bin/rtpproxy root 19080 0.0 0.0 2532 344 ? Ss 15:44 0:00 /usr/bin/rtpproxy -l xxx.xxx.xxx.xxx -s udp:xxx.xxx.xxx.xxx 8899
Are you sure the ps and the netstat are from the same machine ? What does cat /proc/19080/cmdline | tr "\0" "\n" gives you ? Would you by chance have a second -s option after the first one, truncated by ps, which would be taken into account instead of the udp socket ? That would explain your netstat result.
There is a missing ":" between the ip and the port. Try to use -l xxx.xxx.xxx.xxx -s udp:xxx.xxx.xxx.xxx:8899
In fact, command line syntax for -s option is udp:ip:port. If you omit the ":" between ip and port, there will be no warning, and rtpproxy will listen (for the original version, dunno for fedora versions) on port 22222. But the behavior might be different on your version. Note that I cannot be 100% sure that you got that one wrong here because indead, even if you use the proper syntax, rtpproxy does not report the ":" in the commandline"
On Thu, 2008-01-10 at 18:28 -0200, Jeferson Prevedello wrote:
Thanks Jérôme! :-)
I comment the following lines in the openser.cfg file:
#modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") # Nathelper with RTPproxy #modparam("nathelper", "rtpproxy_sock", "udp:200.176.6.90:8899")
Did you really comment out both lines ? I means comment only the first moparam, not the one with the udp port :-)
And started the rtpproxy with the following command:
/usr/bin/rtpproxy -l 200.176.6.90 -s udp:200.176.6.90:8899
Logs:
Jan 10 18:04:26 src@sip2 /usr/sbin/openser[2805]: rtpp_test: RTP proxy unix:/var/run/rtpproxy.sock found, support for it enabled
Unfortunately I still have a problem that I believe to be related to rtpproxy. When I make calls through of a branch connect the openser exists audio in both directions, but when I receive calls not have audio on any of directions.
Any suggestion ?
Regards Jeferson
-----Mensagem original----- De: Jerome Martin [mailto:jmartin@longphone.fr] Enviada em: quinta-feira, 10 de janeiro de 2008 16:39 Para: Jeferson Prevedello Cc: users@lists.openser.org Assunto: Re: [OpenSER-Users] Problems with RTP-Proxy
I think I was too fast there.
On Thu, 2008-01-10 at 19:19 +0100, Jerome Martin wrote:
Hi.
My remarks below.
On Thu, 2008-01-10 at 16:06 -0200, Jeferson Prevedello wrote:
Hi !
I´m having problem to running RTPPROXY. Please, someone help me ?
Logs bellow:
Removed the logs from the answer as you IPs are in clear there.
[openser.cfg]
# ------------- !! Nathelper
modparam("registrar", "nat_flag", 6) modparam("nathelper", "natping_interval", 30) # Ping interval 30 s modparam("nathelper", "ping_nated_only", 1) # Ping only clients behind NAT modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") # Nathelper with RTPproxy modparam("nathelper", "rtpproxy_sock", "udp:xxx.xxx.xxx.xxx:8899")
I would first try to remove the unix-socket rtpproxy_sock declaration, even though you log messages tend to let one think openser is using only the second one (UDP).
modparam("nathelper", "rtpproxy_disable_tout", 30) modparam("nathelper", "rtpproxy_tout", 2) modparam("nathelper", "rtpproxy_retr", 10)
# -------------
[root@sip2 run]# rpm -qa | grep rtp rtpproxy-0.3-1.fc5
[root@sip2 run]# netstat -axep |grep rtpproxy unix 2 [ ACC ] STREAM LISTENING 8070094 19061/rtpproxy /var/run/rtpproxy.sock
Your netstat is the primary reason to make me believe rtpproxy was not launched with proper parameters. You would not catch the udp socket rtpproxy uses with the netstat options you provided, but here it seems your running proxy is waiting for control on a unix socket. And rtpproxy cannot listen both on udp AND unixsocket. You need to choose udp or unixsocket both in openser.cfg and in rtpproxy commandline.
[root@sip2 run]# ls -al rtpproxy.sock srwxr-xr-x 1 root root 0 Jan 10 15:44 rtpproxy.sock
[root@sip2 run]# ps -aux | grep rtp
if you want to use "-" options a la systemV, use "ps -eaf" to achieve the same than the BSD-style "ps aux" :-)
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.6/FAQ root 19061 0.0 0.0 2532 344 ? Ss 15:44 0:00 /usr/bin/rtpproxy root 19080 0.0 0.0 2532 344 ? Ss 15:44 0:00 /usr/bin/rtpproxy -l xxx.xxx.xxx.xxx -s udp:xxx.xxx.xxx.xxx 8899
Are you sure the ps and the netstat are from the same machine ? What does cat /proc/19080/cmdline | tr "\0" "\n" gives you ? Would you by chance have a second -s option after the first one, truncated by ps, which would be taken into account instead of the udp socket ? That would explain your netstat result.
There is a missing ":" between the ip and the port. Try to use -l xxx.xxx.xxx.xxx -s udp:xxx.xxx.xxx.xxx:8899
In fact, command line syntax for -s option is udp:ip:port. If you omit the ":" between ip and port, there will be no warning, and rtpproxy will listen (for the original version, dunno for fedora versions) on port 22222. But the behavior might be different on your version. Note that I cannot be 100% sure that you got that one wrong here because indead, even if you use the proper syntax, rtpproxy does not report the ":" in the commandline"
El Jueves, 10 de Enero de 2008, Jerome Martin escribió:
To summarize, I'd say that if you rely on RTP detection for billing, then you have the following limitations :
- unreliable problem detection
- stuck with RTP proxying for ALL calls
- problems with VAD
- problems in corner cases with re INVITES changing the RTP stream
extremities
What do you think ?
I think that I should thank to you for a great explanation ;)
On Thu, 2008-01-10 at 20:10 +0100, Iñaki Baz Castillo wrote:
El Jueves, 10 de Enero de 2008, Jerome Martin escribió:
To summarize, I'd say that if you rely on RTP detection for billing, then you have the following limitations :
- unreliable problem detection
- stuck with RTP proxying for ALL calls
- problems with VAD
- problems in corner cases with re INVITES changing the RTP stream
extremities
What do you think ?
I think that I should thank to you for a great explanation ;)
What, you're not even arguing ? :-) You're too kind. But seriously, this is a pretty hot subject, and I've never met anyone suggesting the same as I did here, most of the time I hear the same thing about rtpproxy + CDRs reliability.
I'm sure some people are challenging what I wrote right now, in their mind ! If we are lucky, we'll even get emails !
Disclaimer: the above paragraph was not meant to start a flame war on the topic between SST/pinging schools and RTP detection ones. At worst, the two techniques can really complement each other.
Regards,
Jerome,
In my opinion it depends on the policy of the VoIP provider rather than on technical issues.
Proper implementation of RFC 4028 of all involved UACs might render RTP analysis useless, if it's in line with the policy of the the VoIP provider to have some minutes of tolerance in their CDRs in case of missing BYEs (the tolerance can be controlled by the provider via the defined headers). If that is still unacceptable by a provider, there maybe should be some SIP/RTP-aware billing engines in place though.
Andreas
Jerome Martin wrote:
On Thu, 2008-01-10 at 20:10 +0100, Iñaki Baz Castillo wrote:
El Jueves, 10 de Enero de 2008, Jerome Martin escribió:
To summarize, I'd say that if you rely on RTP detection for billing, then you have the following limitations :
- unreliable problem detection
- stuck with RTP proxying for ALL calls
- problems with VAD
- problems in corner cases with re INVITES changing the RTP stream
extremities
What do you think ?
I think that I should thank to you for a great explanation ;)
What, you're not even arguing ? :-) You're too kind. But seriously, this is a pretty hot subject, and I've never met anyone suggesting the same as I did here, most of the time I hear the same thing about rtpproxy + CDRs reliability.
I'm sure some people are challenging what I wrote right now, in their mind ! If we are lucky, we'll even get emails !
Disclaimer: the above paragraph was not meant to start a flame war on the topic between SST/pinging schools and RTP detection ones. At worst, the two techniques can really complement each other.
Regards,
On Fri, 2008-01-11 at 02:39 +0100, Andreas Granig wrote:
Jerome,
In my opinion it depends on the policy of the VoIP provider rather than on technical issues.
Agreed, the definitive solution does not exists, and is policy and environment-dependent.
Proper implementation of RFC 4028 of all involved UACs might render RTP analysis useless, if it's in line with the policy of the the VoIP provider to have some minutes of tolerance in their CDRs in case of missing BYEs (the tolerance can be controlled by the provider via the defined headers). If that is still unacceptable by a provider, there maybe should be some SIP/RTP-aware billing engines in place though.
What I don't get here is the "minutes of tolerance". Typically, RTP timeout is in the same order of time, for what I've seen. Do you use an RTP timeout of a few seconds only ? If so, clearly the issues I've mentionned earlier are even worse with such a short timeout.
Talking about policy, I would say it is in the best interest of every provider to limit the amount of "potentially post-BYE, hard-to-bill" minutes. But even with RTP detection, this is hard to acheive.
Or maybe you're thinking more of a hybrid solution ? Like RTP timeout triggering a SIP ping, which in return, if failling, triggers call termination. But this is really tough to handle, particulary the case when you don't have RTP but the UAC is still responding to SIP signaling.
I'm really curious, could you give me a real-world example of an RTP-detection based soution providing sub-minute dead UA detection ?
Regards,
Jerome Martin napsal(a):
On Fri, 2008-01-11 at 02:39 +0100, Andreas Granig wrote:
Jerome,
In my opinion it depends on the policy of the VoIP provider rather than on technical issues.
Agreed, the definitive solution does not exists, and is policy and environment-dependent.
Proper implementation of RFC 4028 of all involved UACs might render RTP analysis useless, if it's in line with the policy of the the VoIP provider to have some minutes of tolerance in their CDRs in case of missing BYEs (the tolerance can be controlled by the provider via the defined headers). If that is still unacceptable by a provider, there maybe should be some SIP/RTP-aware billing engines in place though.
What I don't get here is the "minutes of tolerance". Typically, RTP timeout is in the same order of time, for what I've seen. Do you use an RTP timeout of a few seconds only ? If so, clearly the issues I've mentionned earlier are even worse with such a short timeout.
Talking about policy, I would say it is in the best interest of every provider to limit the amount of "potentially post-BYE, hard-to-bill" minutes. But even with RTP detection, this is hard to acheive.
Or maybe you're thinking more of a hybrid solution ? Like RTP timeout triggering a SIP ping, which in return, if failling, triggers call termination. But this is really tough to handle, particulary the case when you don't have RTP but the UAC is still responding to SIP signaling.
I'm really curious, could you give me a real-world example of an RTP-detection based soution providing sub-minute dead UA detection ?
My provider (about 50.000 customers, few milion minutes per month) detects RTP streams and terminate calls after 10 seconds without RTP. VAD is disabled, of course :-) Its solution is based on propritary telco SIP to SS7 gateway... BTW: The same thing I do with Asterisks behind my OpenSER (10 secs RTP timeout), but I'm very interested in SIP pinging. Could you point me to some hint/working example how to do it with SIP proxy (like OpenSER)?
Thanks in advance,
kokoska.rokoska
Jerome,
Jerome Martin wrote:
What I don't get here is the "minutes of tolerance". Typically, RTP timeout is in the same order of time, for what I've seen. Do you use an RTP timeout of a few seconds only ? If so, clearly the issues I've mentionned earlier are even worse with such a short timeout.
Let me clear this up. In some deployments billing relies on successful re-INVITEs (with an interval of some minutes) rather than on RTP timeouts (which may be detected within some seconds). This works because they are rather closed systems with UACs which support the Session Timer standard. So if a BYE is lost for some reason, the call is torn down on the next re-INVITE latest.
I'm really curious, could you give me a real-world example of an RTP-detection based soution providing sub-minute dead UA detection ?
No, sorry, since I also don't rely on RTP regarding the billing :)
Andreas
Andreas,
On Fri, 2008-01-11 at 15:41 +0100, Andreas Granig wrote:
Let me clear this up. In some deployments billing relies on successful re-INVITEs (with an interval of some minutes) rather than on RTP timeouts (which may be detected within some seconds).
Right. That's the solution I like the most.
This works because they are rather closed systems with UACs which support the Session Timer standard.
Well, you only need 1 SIP endpoint in the chain supporting SST for this to work, but obviously if this one breaks, well, you loose it all :-)
So if a BYE is lost for some reason, the call is torn down on the next re-INVITE latest.
I know :-)
I'm really curious, could you give me a real-world example of an RTP-detection based soution providing sub-minute dead UA detection ?
No, sorry, since I also don't rely on RTP regarding the billing :)
Well, seems in the end we have the same approch :)
What was strange to me (and still is), is the fact that some people are using RTP detection with a few seconds threshold. This is insane in my environment, and really I don't see an environment where it would not be a huge penalty, for the reasons I've given before in this thread : - you cannot use VAD - you're stuck with RTP proxying - users cannot cut the mike on their phone (with business subscribers, this is a clear no-go) - it's not generic at all, aka, it does not work for SIP sessions that are not phone calls (IM sessions, using something else than RTP, or just oneway RTP like message diffusion etc...)
So I'm saying it again: using RTP detection is an UGLY HACK (when used alone). On the other hand, RTP detection + ping when you detect the stream went down, so you can check if the stream went down but the user is still in control, is a good idea. So RTP detection is interesting when used AS A PART OF A MORE COMPLEX SCHEME, but NOT standing alone.
What do you think ?
Regards,
Jérôme Martin | LongPhone Responsable Architecture Réseau 122, rue la Boetie | 75008 Paris Tel : +33 (0)1 56 26 28 44 Fax : +33 (0)1 56 26 28 45 Mail : jmartin@longphone.fr Web : www.longphone.com
Andreas Granig schrieb:
Jerome,
In my opinion it depends on the policy of the VoIP provider rather than on technical issues.
Proper implementation of RFC 4028 of all involved UACs might render RTP analysis useless, if it's in line with the policy of the the VoIP provider to have some minutes of tolerance in their CDRs in case of missing BYEs (the tolerance can be controlled by the provider via the defined headers). If that is still unacceptable by a provider, there maybe should be some SIP/RTP-aware billing engines in place though.
Yes. If you do accounting for billing purpose, you should the accounting where the costs happen and were you have reliable CDRs.
E.g. if you have you own PSTN gateway I recommend doing accounting on the gateway. The gateway always knows the SIP state and the RTP state. Further, the gateway should have RTP timeout and/or Session Timer support to detect dead sessions.
If do you not have your own PSTN gateway but use some PSTN gateway provider then you either trust the gateway provider and use the CDRs of the gateway provider or put a B2BUA between your SIP proxy and your gateway provider (thus the B2BUA is somehow a gateway to the PSTN provider) and do accounting on the B2BUA.
Doing accounting on the sIP proxy and RTP proxy works too if the gateway can detect dead sessions - neverthless the CDRs wont be as accurate as the CDRs from the gateway.
Regarding accounting of SIP-to-SIP calls - if you do not bill them then you can use accounting on the SIP proxy for statistical reasons. if you want to bill them, the same as above applies.
regards Klaus
Andreas
Jerome Martin wrote:
On Thu, 2008-01-10 at 20:10 +0100, Iñaki Baz Castillo wrote:
El Jueves, 10 de Enero de 2008, Jerome Martin escribió:
To summarize, I'd say that if you rely on RTP detection for billing, then you have the following limitations :
- unreliable problem detection
- stuck with RTP proxying for ALL calls
- problems with VAD
- problems in corner cases with re INVITES changing the RTP stream
extremities
What do you think ?
I think that I should thank to you for a great explanation ;)
What, you're not even arguing ? :-) You're too kind. But seriously, this is a pretty hot subject, and I've never met anyone suggesting the same as I did here, most of the time I hear the same thing about rtpproxy + CDRs reliability.
I'm sure some people are challenging what I wrote right now, in their mind ! If we are lucky, we'll even get emails !
Disclaimer: the above paragraph was not meant to start a flame war on the topic between SST/pinging schools and RTP detection ones. At worst, the two techniques can really complement each other.
Regards,
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-
Andreas Granig -
Helmut Kuper -
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Jeferson Prevedello -
Jeremy McNamara -
Jerome Martin -
Klaus Darilion -
kokoska rokoska