IP to IP Gateways: Connecting LAN Distribution and WAN Streaming
An IP-to-IP gateway adapts an existing media stream to a different IP transport or delivery environment. It can connect WAN Streaming to LAN Distribution while preserving compressed video and audio when the source and destination formats are compatible.
The Interworking Layer between Media Networks
An existing source may already contain the right programme, video codec and audio format, but arrive through a transport that the destination cannot accept. An IP-to-IP gateway receives that stream and creates a supported output suited to the next part of the system.
Depending on the verified product functions, this can include session termination, protocol conversion, packetisation, addressing changes, service filtering or remultiplexing. A list of supported protocols must not be interpreted as proof that every input can be converted directly into every output.
Conversion is not transcoding
Repackaging H.264 video from one transport into another does not change it into H.265, lower its resolution or reduce its encoded bitrate. Those changes require a transcoding function verified for the intended formats.
WAN Ingest to Managed LAN Distribution
-
Receive
- Existing WAN media source
- Supported session or URL
- Compatible compressed payload
-
Process
- Terminate input transport
- Select supported services
- Adapt packetisation and timing
-
Deliver
- Supported LAN transport
- Unicast or multicast addressing
- Defined output stream map
-
Use
- Compatible IPTV receivers
- IP-input headend equipment
- Monitoring and distribution
Conceptual interworking architecture. For a reverse LAN-to-WAN path, select a gateway with the required input/output direction and remote-end compatibility.
LAN/WAN defines the network domain. Multicast/unicast defines how media is delivered to receivers. A managed WAN may carry multicast if specifically engineered, while a public-internet path normally needs unicast transport or HTTP distribution infrastructure.
Separate Transport, Packaging and Media Processing
| Function | What changes | What does not follow automatically |
|---|---|---|
| Protocol conversion | The input/output transport or delivery method. | Codec conversion or a lower encoded bitrate. |
| Repacketisation | How media data is grouped and carried. | A change in picture resolution or quality. |
| Service filtering / remultiplexing | Which programme components are carried and how services are organised. | Unlimited stream capacity or arbitrary receiver compatibility. |
| Unicast / multicast adaptation | Delivery addressing and stream replication. | Multicast availability across the public internet. |
| Transcoding | Compressed video/audio representation, where supported. | Availability in a product sold primarily as a protocol gateway. |
A compatible container and codec remain essential. An RTSP camera source, an HLS service and a broadcast transport stream may differ in audio, timestamps, service metadata and packaging. Validate the actual source and receiver combination, not just the protocol names.
Three Practical Interworking Paths
A · SRT from a remote site → UDP/RTP for the LAN
The gateway receives a supported WAN stream and delivers the compressed media through a LAN transport. The local network and receivers must accept the output format and addressing.
B · Local UDP/RTP → SRT for another site
The gateway adapts a compatible local feed for a WAN contribution session. Connection roles, remote reachability, recovery capacity and delay remain part of the link design.
C · HLS source → managed LAN transport
Where the implementation supports the source, the gateway retrieves playlists and media segments, then produces a compatible output stream. Existing source and player/segment buffering impose a delay floor; conversion cannot retrieve live content before the source publishes it.
For pulled streams, establish authorised access and confirm URL behaviour, authentication, encryption and playlist/segment compatibility. A normal playable web page is not necessarily a directly ingestible media URL. HLS reception does not by itself prove HLS output support.
Capacity and Compatibility Limits
Count input streams, output streams and duplicated outputs separately. Then calculate aggregate traffic on each interface and the processing load imposed by the chosen functions. A headline stream count is not a guarantee for every combination of bitrate, remultiplexing and simultaneous delivery.
Gateway buffering and timing adaptation may alter transport delay without changing picture compression. Null-packet insertion can change a transport stream’s total bitrate without reducing or re-encoding the video. This must not be described as picture-quality optimisation.
- Provide representative source streams and the intended destination model.
- Specify each required input-to-output direction explicitly.
- Check video/audio formats, service signalling and timestamp behaviour.
- Measure source-to-destination latency and behaviour during source reconnects.
- Confirm management access, monitoring and separation of media/network interfaces.
A gateway is not automatically a firewall
Media termination or multiple network interfaces do not establish firewall protection. Apply the network security controls required by the installation independently.
Where a Gateway Avoids Unnecessary Re-encoding
The BLANKOM BIG-1050X/BIG-1100X family addresses stream protocol interworking. Its published headline capacities are 50 and 100 streams respectively; the exact source, output direction and aggregate loading must be checked against the supplied configuration. HLS input and HLS output are separate requirements.
Relevant BLANKOM Building Blocks
Use the selected product page’s Data Sheet and User Manual to verify model-specific interfaces, capacities and firmware functions. Send your requirements to IRENIS for a configuration matched to your project.
BLANKOM device licensing is lifetime, with no recurring BLANKOM licence fee or mandatory SLA. Third-party services and optional system components have their own commercial terms; the supplied configuration should state what is included.
For the broader system context, see What Is IPTV? and the Technical Library.
Frequently Asked Questions
Will a gateway improve picture quality?
Transport conversion can preserve existing compressed content. It does not recreate detail that is absent from the source.
Can a gateway convert H.265 into H.264?
Only if it includes a verified transcoding function. Protocol conversion alone cannot do this.
Can every HLS service be converted into multicast?
No. Source access, encryption, playlist/segment format, codecs and implementation support must be compatible.
Does a 100-stream model support any 100 sources?
No. Stream count must be assessed together with bitrate, simultaneous outputs, processing and the documented configuration.
Technical and Product References
Define the Signal Chain Before Selecting Equipment
Send the information below so IRENIS can identify appropriate BLANKOM products and any compatibility checks needed for your system.
© 2026 IRENIS GmbH. All rights reserved. Unless otherwise stated, the original text, diagrams, tables and illustrations in this publication are protected by copyright. Except where permitted by applicable law, they may not be reproduced, republished, distributed, translated, adapted or used commercially, in whole or in part, without the prior written permission of IRENIS GmbH. Any permitted quotation or reference must clearly identify IRENIS GmbH as the source and, for online use, include a link to the original publication. Third-party trademarks and credited materials remain the property of their respective owners.
Original publication: IP to IP Gateways: Connecting LAN Distribution and WAN Streaming
