Question on signalling versus RTP on Teleworker phones via MBG

[rdpayne]

Trying to get a good answer on the actual signalling and RTP flow between MiNet teleworker phones and MBG.

Teleworker IP extension dials internal IP extension.

Teleworker is 'always on' with MBG public IP address.

SSL (I believe) signalling to the RTC on the LAN via the MBG.

RTC finds destination extension and starts to build the call.

Distant end answers, RTC hands off information for speech path.

Peer to peer set up for RTP through MBG as the proxy?

Thanks all.

 

[DoubleUT]

In server/Gateway mode and in DMZ server only mode the RTP will be routed through the MBG server. If you activate local streaming and two teleworker sets are at the same location then the RTP will stream from phone to phone.

 

[LoopyLou]

Think the teleworker is using SRTP as well.

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[IrwinMFletcher]

All correct.

To the Controller, MBG looks like a bunch of phones. To the TW phones, MBG looks like a controller.

All of the streaming (from internal to external sets) goes through the MBG. That's the whole purpose of it.

 

[rdpayne]

Got it. And if you want compression, better to define zones to apply compression set to set / MCD (E2T) to set instead of telling MBG to apply compression due to the cpu utilization. Higher processing on the CPU means less resources available for everything else.

Can use upstream / downstream MBG so you can better manage traffic for specific subnets (remote or SRC / recorded devices).

And the purpose of why the SRTP packets are passed through the MBG instead of peer to peer (unless they are local and local-streaming is turned on) is so we can maintain some measure of QOS(?) as peer to peer across the internet between IP phones is still only best effort?

And that still holds true for internal to external sets? Internal / internal peer to peer SRTP. Internal to external / peer to peer SRTP from Internal device to MBG as that is what the MCD has build the signalling path to. MBG handles the proxy services of managing the SRTP from internal network to remote teleworker.

I think the big misunderstanding I am trying to clear for our group is that it makes sense for the peer to peer internally, but many techs are seeing that same connection between internal to external devices. Because when the MCD internally provides the internal device the parameters for the voice streaming session, the MCD can't see past the MBG. Only the MBG. So it makes sense that the signallin / SRTP path is:


SIGNALLING (SSL)

MCD <------ MBG <------TW DEVICE

VOICE STREAM (SECURE RTP)

INTERNAL <---> MBG <---> TW DEVICE

Where we've been hung up is the understanding (and this is after the selfstudy training on MOL and engineering / GIG documentation) that is looks like this:

SIGNALLING (SSL)

MCD <----- MBG <----- TW DEVICE

VOICE STREAM (SECURE RTP)

INTERNAL <----> TW DEVICE

Proxy is the key word I think we have to remember. Thus the ability to use upstream / downstream MBG's to handle traffic and to manage remote subnets via another MBG.

Sorry this is a long post, but the folks on this forum are a great source to ping this type of information to so we can better understand our product while trying to work through sometimes dense information in the documentation. Thanks all.

 

[LoopyLou]

The best way to figure it all out is with wireshark and look at the actual traces.

whether SRTP is INTERNAL <> TW device will depend on how the customers network is setup. Once a call is in progress SRTP will be between the INTERNAL and EXTERNAL party but how exactly it gets there will depend on the setup

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[rdpayne]

Thanks for the tip. What's the best setup for wireshark for the monitored ports? Both the MCD and Stations and Internal nic of the MBG I assume.

 

[LoopyLou]

You would want to see where the packets from the telework go so you could start by putting the phone into monitor mode and plugging your wireshark PC into the back of the phone.

You would want to see where the packets from the internal phone go so you could also do the same from an internal phone.

After that you could of course mirror the MCD port but it would only be involved during call setup and tear down but has no involvment with SRTP ( unless a TDM trunk is involved in the call ). Finlly you could mirror the internal MBG port for the complete picture but you might get enough info just from the traces on the phones themselves.


I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.