videocallprotocol.txt

    Some ideas for how the dAmn protocol could be adapted for video calls.
    
    Sticking to existing protocol packet structures as closely as possible,
    send and recv packets could be used if subpacket namespaces were permitted.
    
    For subpackets, namespaces of the form call:callname could be used. Any
    name could be used for a call, so long as that name is not already in use
    within the channel the call is being operated in.
    
    Here ideas will be discussed as appropriate for managing a private call
    in a private chat between userA and userB.
    
    To open a call or start a call, a userA's client could send a packet
    similar to the following.
    
        send pchat:userA:userB
        
        open call:userA
    
    The server would then check if call:userA already exists in
    pchat:userA:userB. If not, the following packet is forwarded to all users
    in the channel.
    
        recv pchat:userA:userB
        
        open call:userA
        from=userA
    
    If userB wants to join the call, they can do so using the following packet.
    
        send pchat:userA:userB
        
        join call:userA
    
    The server adds userB to call:userA. Then all of the users in call:userA,
    except userB, receive the following.
    
        recv pchat:userA:userB
        
        join call:userA
        from=userB
    
    In response to this, clients should then create a WebRTC peer connection
    for userB. Clients can then create an offer for a connection and send the
    following packet.
    
        send pchat:userA:userB
        
        offer call:userA
        user=userB
        
        <PeerConnection Offer>
    
    The server then sends all offers to `user` in the following packet. Seeing
    as only userA and userB are in the working example, only userA sent an
    offer for userB.
    
        recv pchat:userA:userB
        
        offer call:userA
        from=userA
        
        <PeerConnection Offer>
    
    For each offer that is received, the client creates a new WebRTC peer
    connection, applies the offer, and generates an answer. This allows the
    client to send back a connection answer as follows.
    
        send pchat:userA:userB
        
        answer call:userA
        user=userA
        
        <PeerConnection Answer>
    
    Which is forwarded as such.
    
        recv pchat:userA:userB
        
        answer call:userA
        from=userB
        
        <PeerConnection Answer>
    
    After this point, WebRTC peer connections begin generating ICE candidates,
    which need to be exchanged. The following packets could be used for this.
    
        send pchat:userA:userB
        
        candidate call:userA
        user=userB
        
        <ICE candidate>
    
    And the corresponding recv packet.
    
        recv pchat:userA:userB
        
        candidate call:userA
        from=userA
        
        <ICE candidate>
    
    This should allow the connections to work.
    
    If a user exits the call for any reason (hanging up, disconnecting, or
    leaving the channel), then the server should notify other clients. A user
    can hang up intentionally by sending the following packet.
    
        send pchat:userA:userB
        
        part call:userA
    
    When a user is removed from a call, the following packet is send to the
    users still in the call.
    
        recv pchat:userA:userB
        
        part call:userA
        from=userB
    
    If all users have left a call, or if a host leaves a call, then the call
    ends. When a call ends, all users in the channel receive the following
    packet.
    
        recv pchat:userA:userB
        
        close call:userA
    
    Having this sort of setup should allow for both group and private calls.
    
    When receiving `recv open` and `recv close` packets for calls, clients
    should use the information provided to maintain a list of calls currently
    open within the channel.
    
    In a private chat, a user should be able to reject a call. This could be
    done by sending the following packet to the server.
    
        send pchat:userA:userB
        
        reject call:userA
    
    The call would be forcibly closed with a `recv close` packet in that case.
    
    When joining a public channel, it would be useful to inform the user of
    any calls currently operating in the channel. This could be done using
    something similar to this packet.
    
        recv chat:devart
        
        open call:userA
        
        open call:userB
        
        open call:userC
        
        ...