Is there an example for using an external signaling server?

[paulomorgado]

All the examples I've seen seem to use the WebRTC server as the signaling server.

I have a use case where both client and server connect to signaling server that is not the WebRTC server.

What RTCPeerConnection events do I need to handle and what methods do I need to call?

[sipsorcery]

WebRTC signalling can be as simple as sending an SDP offer and getting an SDP answer.

If you want also want to trickle ICE candidates and maybe SDP updates you need something more. There is this class that I used at one point for a rudimentary REST server implementation. The server side of it is here.

[paulomorgado]

My rought understanding of how it works (minus ICE) is:

sequenceDiagram
    participant Client
    participant Server as Server (SIPSorcery)
    participant Signaling as Signaling (Web Sockets)
    participant ICE

    Client->>Signaling: Connect
    Signaling->>Server: Relay client connected
    Server->>Server: createOffer()
    Server->>ICE: Gather ICE candidates
    ICE->>Server: Send ICE candidates
    Server->>Server: onicecandidate - signalingState is closed
    Server->>Server: setLocalDescription()
    Server->>Signaling: Send offer
    Signaling->>Client: Relay offer
    Client->>Client: setRemoteDescription()
    Client->>Client: createAnswer()
    Client->>Client: setLocalDescription()
    Client->>Signaling: Send answer
    Signaling->>Server: Relay answer
    Client->>Client: onicecandidate
    Server->>Server: RTCPeerConnection.setRemoteDescription()

Loading

Am I correct?

[paulomorgado]

One of the issues I was having was that the create offer of MixedReality serializes to:

{
    Content: "<sdp content>",
    Type: "<numeric>"
}

[sipsorcery]

Your diagram is laregly correct. It doesn't make sense to have a separate element for ICE since it's just a bit of logic in each WebRTC peer ( perhaps you meant a STUN/TURN server). Another problem is the ICE candidates also need to be sent between teh peers via the signalling server. If ICE trickling is being used, which is now the default, ICE candidates can be ready at any stage and ideally you need to get them to the remote peer quickly.

In your serialisation example looks like you jsut need to use the enum to string serialisation. That will get the Type set as offer or answer rather than a numeric value.