Add possibility to define webrtc address independently from external a…

[pchlupacek]

…ddress for b2b appliactions

[pchlupacek]

@hrosa this actually addresses issue where the external address behaviour in 5.0 was changed heavily (btw that shall be documented in bold, or better than avoided for next time). For dual back 2 back application where you need different WebRTC address from the SIP address, that change was breaking that functionality. This adds back possibility to configure WebRTC SIP address independently from SIP addressing.

[hrosa]

Hi @pchlupacek

Can you elaborate a bit more on your use case?

I'm not really fond of the idea of adding more addresses to the config file, it only adds complexity and confusion. Maybe we can review the MS behaviour and check if we can improve it somehow?
I also think the name webRtcAddress is misleading/confusing.

Is this some problem that could be solved by using ICE (that I know you're working on)?

Regards

[pchlupacek]

@hrosa yes, ice will have own config, so we may decide how that will be plugged in. The proposed change solves the situation where you need Public address for WebRTC but for SIP/RTP traffic you still need private address (you don't want to expose it over public interface) . The change you have made to ExternalAdress makes that setup impossible.

Essentially I am talking here about scenario where you want to have all SIP/RTP traffic local, and you want only expose the public WebRTC traffic/port . Because you have now ICE Lite, there is no other mechanism except define them independently I am aware of.

[hrosa]

@pchlupacek I see, but I don't think it's good to have this external/webrtc duality. Let's try to implement this in a more generic way, configurable according to each user's needs.

Ideally we could have several addresses loaded from configuration, but once MS is booted just one address is injected to corresponding components.

We already have an open issue related to this #102.

What do you think? Are you willing to contribute to this one?

[pchlupacek]

@hrosa given the current stage of mgcp and udp stack, I am kind of restrain to any systematic and significant effort approach, before these two will see day of the light :-) The amount of quirks and wiring plugs is so intense, that I am not sure I have good picture on where to start and how much effort that will be.

So if you think this is not appropriate to introduce into mainstream, we can leave it as it is and keep it in our fork only. My intention was to do something quick and easy.

Also I would like first to finish that ICE module too, as that in turn will render need to have external address for webrtc obsolete.

[hrosa]

Understood @pchlupacek

As I mentioned, we need to be careful here because each user will have their own requirements and will need MS to behave in a certain way. A solution that satisfies everyone is having ICE + extra address configuration to help users control traffic.

Can't wait to see that ICE module you're working on. Let's keep in touch about this one because it's really important indeed.

[pchlupacek]

The subject of this PR is to allow different IP address to be announced by RMS when creating SDP Offer with WebRTC contrary to non-webrtc SDP. The application is dual-homed RMS with one IP at public side and one IP at private side.

[pchlupacek]

IWhat we need to achieve is following SDP behaviour:

On private side (non-webrtc call) :

sdp=v=0
o=- 326911306 0 IN IP4 10.20.0.200
s=-
c=IN IP4 10.20.0.200
t=0 0
m=audio 13842 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20

and on public (webrtc) side:

v=0
o=- 1498232074084 1 IN IP4 1.1.1.1
s=Mobicents Media Server
c=IN IP4 1.1.1.1
t=0 0
a=ice-lite
m=audio 65534 RTP/SAVPF 0 8 126
c=IN IP4 1.1.1.1
a=sendrecv
a=rtcp:65534 IN IP4 1.1.1.1
a=rtcp-mux
a=ptime:20
a=ice-ufrag:btgqf
a=ice-pwd:5ejv7g43li9vjqbde701g3nth8
a=candidate:11111111 1 udp 1 10.20.0.200 65534 typ host generation 0
a=candidate:11111111 1 udp 1 1.1.1.1 65534 typ srflx raddr 192.168.1.64 rport 65534 generation 0
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:126 telephone-event/8000
a=setup:passive
a=fingerprint:sha-256 82:1E:5E:EB:B5:0D:F8:CF:7A:72:43:FE:91:3A:CE:DC:20:D1:4E:F4:69:4B:06:B4:AA:03:41:67:19:F1:E5:24
a=ssrc:4287553934 cname:hp3/B+PNDB/TbCNX)

Where 10.20.0.200 is private ip and 1.1.1.1 is public IP.

[pchlupacek]

Once we agree on the form I can update this PR agains the master

[hrosa]

Hi @pchlupacek

I understand your problem. But as I last mentioned in this thread, we need to be careful because each user will have their own requirements and will need MS to behave in a certain way.

For this problem in particular, I think the proper solution is to fully support ICE. But we're still delayed there, and I do not wish to block you.

That being said, I think that adding a new field for a repeated address is confusing. Same as the naming "webRTC address".

A more elegant solution for this case would be to add a new parameter to externalAddress named "overwrite":

<externalAddress overwrite="true">127.0.0.1</externalAddress>

If overwrite is set to true, it will overwrite SDP fields "origin" and "connection".
If overwrite is set to false, it will only be used in ICE SRFLX candidate.

Would this work for you?

[pchlupacek]

@hrosa I have no problem with doing it the way you suggested, to me is just sort of same way. Perhaps only I think overwrite is confusing, so I would suggest "scope='WebRTC'" that to me is more expressive and shows what has been intended here. If you ensist on your syntax no prob with it.

[hrosa]

ok @pchlupacek that's ok with me, let's make it scope="ice"