# Sgcwebsockets Dotnet P2p

> sgcWebSockets .NET P2P and WebRTC

- Skill: `esegece-com/sgcwebsockets-dotnet-p2p` (Agent Skill, multi-file: 87 files)
- Install (CLI): `npx skillmds@latest add esegece-com/sgcwebsockets-dotnet-p2p`
- Raw SKILL.md: https://api.skillmd.com/api/skills/esegece-com/sgcwebsockets-dotnet-p2p/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: esegece-com (https://skillmd.com/u/esegece-com)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/esegece-com/sgcwebsockets-dotnet-p2p

---


# sgcWebSockets .NET P2P and WebRTC

Five components for getting two peers to talk to each other directly: STUN to
discover your public address, TURN to relay when that fails, and a WebRTC
signalling server.

What this skill covers is the part that gets peers connected. It does not
encode or decode media.

## When to use this skill

- Discover the public address and port a NAT has given you
- Relay traffic through a TURN server when a direct path is impossible
- Run the signalling server two browsers use to exchange offers and candidates
- Run your own STUN or TURN server

## Components in this skill

| Component | Role |
| --- | --- |
| `TsgcSTUNClient` | asks a STUN server what your public address is |
| `TsgcSTUNServer` | answers that question for others |
| `TsgcTURNClient` | allocates a relay and sends through it |
| `TsgcTURNServer` | provides the relay |
| `TsgcWSPServer_WebRTC` | signalling server for browser peers |

## Before you start, ask the developer

Use a structured question tool if your host has one, for example Claude Code's
`AskUserQuestion`. Otherwise ask in chat:

1. **Are the peers browsers, or your own applications?** Browsers need the
   signalling server and do the WebRTC themselves. Two of your own applications
   may only need STUN and a socket.
2. **Do you need a relay?** Roughly one connection in five cannot be made
   directly. If the application must work for everyone, TURN is not optional,
   and a relay costs bandwidth you pay for.
3. **Whose STUN and TURN servers?** A public STUN server is fine for discovery.
   A public TURN server is not: relaying is expensive, and open relays are
   abused, which is why they need credentials.
4. **UDP or TCP?** `Transport` takes `stunUDP` or `stunTCP`. UDP is the normal
   answer; TCP is the fallback where UDP is blocked.

## Quickstart, what is my public address

```csharp
using esegece.sgcWebSockets;

var stun = new TsgcSTUNClient();
stun.Host = "stun.l.google.com";
stun.Port = 19302;
stun.Transport = TsgcSTUNTransport.stunUDP;

stun.SendRequest();
```

The answer arrives on an event, not as a return value. The events and their
delegate signatures are on the API page; wire the response handler before
calling `SendRequest`.

`RetransmissionOptions` controls how a lost request is retried, which matters
because STUN over UDP has no delivery guarantee at all.

## Signalling, and what it is not

`TsgcWSPServer_WebRTC` attaches to a `TsgcWebSocketServer` through `Server` and
relays the offers, answers and ICE candidates that two browsers exchange while
setting up a peer connection. Once they are connected, their media does not go
through it, which is the point.

Signalling is a small amount of message passing and a large amount of
correctness: peers have to be matched to each other, and a candidate delivered
to the wrong peer produces a connection that never completes and no error
anywhere. Decide how peers find each other before writing the handler.

## Things that catch people out

- STUN tells you your address. It does not connect anything. The connecting is
  still yours to do, or the browser's.
- A public STUN server is a reasonable dependency; a public TURN server is not.
  Relay traffic costs real money and open relays get abused, so TURN servers
  want credentials and yours should too.
- `SendRequest` is asynchronous. Code that reads a property on the next line
  reads the previous value.
- Symmetric NAT defeats STUN. When discovery works in testing and fails on a
  corporate network, that is usually why, and TURN is the answer.
- The signalling server relays. It has no idea whether the peer connection
  succeeded, so "connected to the signalling server" is not "connected to the
  peer", and a UI that conflates them will lie to the user.
- The Delphi library also has ICE and a native WebRTC media engine. Neither is
  in this assembly. `concepts/coverage.md` is the list.

## Routing

- **API detail**: `reference/api/<Component>.md` has the properties, events and methods, each with its C# signature.
- **Option / enum / delegate types**: property and event types link to `reference/types/<TypeName>.md`.
- **Examples**: `examples/<Component>.md` is a trimmed snippet from the shipped demo; `examples/index.md` maps every component to its demo.
- **Getting started**: `concepts/overview.md` covers the single `using`, the target frameworks and the naming.

## What is documented

Public instance properties, events and methods declared anywhere in the
library's own class chain. Members inherited from the .NET base classes are
left out, as are internals, so a page shows the surface a caller writes
against and nothing else.

If a component you need is not here, read `concepts/coverage.md` in the
`sgcwebsockets-dotnet` skill before assuming a different name for it.
This assembly carries fewer components than the Delphi library, and saying
so is more useful than guessing an API that does not exist.