Feature Request: Manually add Teleport peers by IP/port

[bjlt-dev]

Could an option be added to manually add specific Teleport peer IPs/ports that are serving streams? This adds flexibility for connections in networks where stream auto-discovery is inconsistent or unavailable, and could also be useful as a troubleshooting/debugging tool.

This feature could be added under the Tools > Teleport menu as an editable list of stream host IP/ports, and an option to use these sources when configuring a Teleport source in OBS.

I'm currently unable to use Teleport in my network environment because of the auto-discovery failing to find remote streams. I'm unable to adjust the network firewall further, but manually specifying a Teleport peer IP/port should fix my issue.

I've tested the following before submitting this feature request:

• confirmed network connectivity between two PCs with OBS/Teleport plugin installed
• OBS can see and connect to localhost Teleport streams on either PC, but will not discover remote streams
• both PCs are on the same 192.168.1.0 network
• disabled all local firewalls and port restrictions on both systems (network firewall is active)
• I can connect to other network services (RDP, SSH, web, ping, etc.) between these PCs and other PCs on the network when I specify IP/hostname and port
• tested multiple ports for Teleport, and confirmed they are open and available on both PCs and visible across the network

Thanks!

[fzwoch]

I'd rather not add that as an option. For complexity reasons, code and usability wise.

I wonder what the reason is why the multicast does not come across.. But since you said discovery on the machine is working, I can imagine adding something to the protocol so you can inject some data.

For example.. when you run this python script on the machine to receive, does it list the phony teleport stream?

import socket
import struct
import time

def send_multicast(data, multicast_group, port):
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)

    ttl = struct.pack('b', 1)
    sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, ttl)

    multicast_address = (multicast_group, port)
    try:
        print(f"Sending data to {multicast_address}")
        sent = sock.sendto(data.encode(), multicast_address)
        print(f"Sent {sent} bytes")
    finally:
        print("Closing socket")
        sock.close()

if __name__ == "__main__":
    multicast_group = '239.255.255.250'
    port = 9999 
    message = "{ \"Name\": \"Hi\", \"Port\": 2222, \"AudioAndVideo\": true, \"Version\": \"0.7.1\" }"

    while True:
        send_multicast(message, multicast_group, port)
        time.sleep(1)

[bjlt-dev]

Appreciate the time and thought - It definitely appears to be a network firewall/routing restriction with the discovery traffic. I see similar behavior with other apps in my environment where auto-discovery will fail, but a direct/manual connection succeeds.

I tried the script on both of my test systems and got similar results to before. The dummy stream is listed by the local system correctly, but is not seen by the peer machine across the network.

I can appreciate passing on this feature - I'll continue to look into a workaround for my network or possibly implement something in a local build. Thanks!

[fzwoch]

test.zip Try this one.

Modify the scripts payload like this:

message = "{ \"Name\": \"Hi\", \"Address\": \"192.168.99.99\", \"Port\": 2222, \"AudioAndVideo\": true, \"Version\": \"0.7.1\" }"

Address and Port should be from the machine doing the output. Run the script on the machine adding the source. Hopefully when you select that one with the correct data it will connect to the correct machine.

I hope that made sense?

[bjlt-dev]

Thanks, the new build and address inject works to get the stream connected!

I did a few brief tests - looks like the script can be closed once connection is established. The stream will stay connected until a relaunch of OBS, or when refreshing the list of available streams in a Teleport source.

[fzwoch]

Yeah, it is not required while running. If you open the options, depending on what you select it may trigger an update causing a reconnect. Not sure how the reconnect will be done right now, I guess it looks up the set service name/ip combo again which by then may no longer be alive (it gets removed if the multicast ping is not received within 5s intervals) and the reconnect fails.

But nice to know it works as a workaround!