How to set ipaddress and port on "appRTCDemo" instead of usings public servers (STUN server, etc...)

[fau....@gmail.com]

Hi, I don't know if somebody can help here, but I'm fighting with this problem from a lot of time and I'm almost desperate...

I'm developping a sotware that needs, among various other functionalities, to setup voip communications. I have some applications on PC side (server, clients) and another on Android (clients).
I tried several voip library: on Android clients: "sipdroid", native "android.net.rtp"; on Pc clients "mjsip".
The results are not good, moreover on Android side.
So now I'm trying to work with libjingle libraries, using OPUS codec.

I'm trying to use "appRTCDemo" code in Android side.

For several reasons (one is for example that it runs in a private network without public internet connectivity), long to explain, I need simply to get inside "appRTCDemo" the way to change the code so that:

- In transmission, to skip the presentation session with the public server /STUN, etc..) and to send directly the voip packets to a precise (to a choosen by me) ipaddress and port receiver (so without idroom).

-  In receiving, simply choose the port where to receive the voip packet.

I don't need any STUN server or whatever other server because in my app the signalling in order to know the ipaddress and port is already working.

It is possible??? And if yes, how?

I'll really appreciate any help, I work in this my own project from years, many other functionalities are ready, but this Voip problem is destroying me... it is a basic functionality, and without it everything is unuseful.

Thank you in Advance

Fausto

[Taylor Brandstetter]

Would it be possible to make your server respond to STUN pings? Then, you could add your server's address/port as a remote ICE candidate of type "local". WebRTC will send a STUN ping as a connectivity check to this address, and once it receives a response it will start using the connection.

If you need to control WebRTC's local port, you can do that by passing your own PortAllocator into CreatePeerConnection. You could implement your own PortAllocator from scratch, but it may suffice to use a BasicPortAllocator and simply call SetPortRange.

Hope I was able to help.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/f0a02024-c624-43c0-b639-e36cd192560e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[fau....@gmail.com]

Hi,

first of all thank you for your reply.

I'm not so expert so I'm trying to understand.

When you say that the server respond to STUN pings, do you mean that  my server should act as STUN server

or do you mean that my server should reply to ping coming from STUN server?

By the way, my real target is to avoid the STUN server (or whathelse server) and also the mechanism of room_id; 

I thought  that, at the end of the story, this is a peer-to-peer connection, so when the call is already ongoing the ANdroid sender  sends packet to an IPaddress and port, and the Android receiver receives those packets on that port.

Therefore somewhere in the code should be this info. I just need to make 2 methods inside "appRTCDemo":

- method1 (to be used in sender Android): start voip transmission sending voip packets to this ipaddress and port xxx 

- method2 (to be used in receiver android): start voip receiving on port xxx

I'm also searching for a freelancer able to do that. I'll provide to him an Android app that already include appRTCDemo,

Thank you in advance

Fausto

[Taylor Brandstetter]

Yes, the server should act as a STUN server, responding to binding requests from the client. What I'm talking about is referred to as "ICE lite"; see: https://tools.ietf.org/html/rfc5245#section-2.7

You don't need to use any external STUN/TURN server though. The STUN server implementation is only for the purpose of ICE connectivity checks between the peers.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/112a46ad-fd38-4a2f-a2da-ab2b685aff49%40googlegroups.com.

[fau....@gmail.com]

Hi again, and thanks again.

Supposing I solve the problem of the STUN server, then an external STUN server is not needed.

I need in any case in Android side to send the voip packets to an Ip address and port fixed by me (or better by my app).

I try to explain why, it is a little bit long, I hope to no be boring.

My application does Indivdual Call and Group calls (PTT -  one talk and other N listen).

In Group Call I have a "Bounce server": it receives every voip packet from the transmitter and send the same packet to the N receivers.

The the mechanism (already implemented and working with other voip libraries) is:

- the transmitter sends voip packets to the ip address and port xxx of Bounce Server

- the Bounce Server receives the voip packet on port xxx

- The Bounce Server send the voip packet to ipadrress and port yyy_1 of receiver 1

- The Bounce Server send the voip packet to ipadrress and port yyy_2 of receiver 2

.....

- The Bounce Server send the voip packet to ipadrress and port yyy_N of receiver N

- The user 1 receive the voip packet on port yyy_1

- The user 2 receive the voip packet on port yyy_2

.....

- The user N receive the voip packet on port yyy_N

That's why I should have the possibility to fix ipaddress and port of receiver...

Do you have any suggestion on that?

Do you know some freelancer that could help me?

Thank you in advance

Fausto

[Taylor Brandstetter]

You should be able to accomplish this by doing what I described in my original email:

1. For the transmitter and each receiver, add an ICE candidate representing the Bounce server.

2. For the receivers, use a custom PortAllocator (or call SetPortRange on the BasicPortAllocator to control) which UDP port is used.

3. Add an audio-only stream to the transmitter's PeerConnection, and do an SDP offer/answer exchange with the Bounce server.

4. Do an offer/answer exchange between the receiver and the Bounce server.

I can't help find a freelancer though, sorry.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/4f2f85d2-2907-43df-a0f5-e25492a27f27%40googlegroups.com.

[fau....@gmail.com]

Thank you very much,

I'll try, but I think I have to study a little bit before...
In case of success I'll write a report here for some other

Ciao

[andj222]

So, for others reading this thread in the future, the BasicPortAllocator / SetPortRange part that Taylor mentioned could look something like this:

default_network_manager_.reset(new rtc::BasicNetworkManager());

port_allocator_.reset(new cricket::BasicPortAllocator(default_network_manager_.get()));

port_allocator_->SetPortRange(10200, 10400);

peer_connection_ = peer_connection_factory_->CreatePeerConnection(rtc_config, &constraints, std::move(port_allocator_), NULL, this);

This does work fine in my experience. Taylor, I had a question or two if you don't mind:

Any problem with using "new BasicNetworkManager()" in this way? i.e. Should I perhaps be doing something more with the network manager instance than accepting the defaults?

There's a variant of the BasicPortAllocator constructor that also accepts a PacketSocketFactory as its second argument... am I missing out or causing any problems by not passing this?

[Taylor Brandstetter]

Any problem with using "new BasicNetworkManager()" in this way? i.e. Should I perhaps be doing something more with the network manager instance than accepting the defaults? 

No, there shouldn't be a problem; this is the solution I was describing.

There's a variant of the BasicPortAllocator constructor that also accepts a PacketSocketFactory as its second argument... am I missing out or causing any problems by not passing this?

Not that I know of. You could probably pass in a custom PacketSocketFactory that only creates sockets in the configured range, but I think this would just be more work for no benefit.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/b77c408b-03e5-4e5e-b845-cb122a174aea%40googlegroups.com.