Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot use rtp_cluster #1

Open
owais-a opened this issue Oct 25, 2016 · 3 comments
Open

Cannot use rtp_cluster #1

owais-a opened this issue Oct 25, 2016 · 3 comments

Comments

@owais-a
Copy link

owais-a commented Oct 25, 2016

When I change rtpproxy IP to rtpcluster, things stop working. I get the following error on the SIP router:
rtpproxy ERR:rtpp_command_pre_parse:GLOBAL: lookup command syntax error: invalid number of arguments (8)

It seems rtp_cluster does not act like rtpproxy.

@sobomax
Copy link
Member

sobomax commented Oct 31, 2016

Hi, OwaisAhmadJan. Thank you for reporting the issue. Would you mind clarifying several things so that we can debug it further:

  1. Which SIP router are you using (flavour, version number), e.g. "opensips 1.19"
  2. What type of control socket (UDP, UNIX etc) between SIP router and rtp_cluster?
  3. What type of control socket (UDP, UNIX etc) between rtp_cluster and rtpproxy in question?
  4. What version of rtpproxy are you using?

In general it would be nice if you can share .xml configuration file as well, replacing any sensitive information (i.e. public IP addresses) with placeholders.

Thanks!

@owais-a
Copy link
Author

owais-a commented Oct 31, 2016

I am using opensips 2.1.3. I tried using both UDP and UNIX socket for rtp_cluster and the control socket.
rtpproxy version is: version 2.0.0

Config is the same as the example except the IPs and ports.

I got around this issue by removing the wan_address parameter.

@sobomax
Copy link
Member

sobomax commented Nov 1, 2016

I think you might have a point here. I believe that "wan_address" feature requires some RTPP protocol extension that is not available in 2.0 rtpproxy. We suggest you to test your stuff with rtpp_2_1 branch if possible. That feature ("wan_address"), however, should be only needed if are you dealing with the AWS-like 1:1 NAT setup, where IP as seen by outside world is different from IP that rtpproxy itself can use. That being said, this also suggests that we probably need to check if that extension is supported and generate an exception or warning of some sorts that "wan_address" cannot be used with this particular rtpproxy node or instance. Thanks for reporting in any case, we will look into adding such a safeguard check and also putting it into our testing rig on the Travis.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants