This is quite a basic plugin, as it only takes care of acting as an RTP bridge. It is named "NoSIP" since, as the name suggests, signalling takes no place here, and is entirely up to the application. The typical usage of this application is something like this:

a WebRTC application handles signalling on its own (e.g., SIP), but needs to interact with a peer that doesn't support WebRTC (DTLS/ICE);
it creates a handle with the NoSIP plugin, creates a JSEP SDP offer, and passes it to the plugin;
the plugin creates a barebone SDP that can be used to communicate with the legacy peer, binds to the ports for RTP/RTCP, and sends this plain SDP back to the application;
the application uses this barebone SDP in its signalling, and expects an answer from the peer;
the SDP answer from the peer will be barebone as well, and so unfit for WebRTC usage; as such, the application passes it to the plugin as the answer to match the offer created before;
the plugin matches the answer to the offer, and starts exchanging RTP/RTCP with the legacy peer: media coming from the peer is relayed via WebRTC to the application, and WebRTC stuff coming from the application is relayed via plain RTP/RTCP to the legacy peer.

The same behaviour can be followed if the application is the callee instead, with the only difference being that the barebone offer will come from the peer in this case, and the application will ask the NoSIP plugin for a barebone answer instead.

As you can see, the behaviour is pretty much the same as the SIP plugin, with the key difference being that in this case there's no SIP stack in the plugin itself. All signalling is left to the application, and Janus (via the NoSIP plugin) is only responsible for bridging the media. This might be more appropriate than the SIP plugin in cases where developers want to keep control on the signalling layer, while still involving a server of sorts. Of course, SIP is just an example here: other signalling protocols may be involved as well (e.g., IAX, XMPP, others). The NoSIP plugin, though, will generate and expect plain SDP, so you'll need to take care of any adaptation that may be needed to make this work with the signalling protocol of your choice.

NoSIP Plugin API

The plugin mainly supports two requests, generate and process, which are both asynchronous. The generate request take a JSEP offer or answer, and generates a barebone SDP the "legacy" application can use; the process request, on the other hand, processes a remote barebone SDP, and matches it to the plugin may have generated before, in order to then return a JSEP offer or answer that can be used to setup a PeerConnection.

The generate request must be formatted as follows:

{
        "request" : "generate",
        "info" : "<opaque string that the user can provide for context; optional>",
        "srtp" : "<whether to mandate (sdes_mandatory) or offer (sdes_optional) SRTP support; optional>",
        "srtp_profile" : "<SRTP profile to negotiate, in case SRTP is offered; optional>"
}

As anticipated, this requires a JSEP offer or answer passed via Janus API as part of a WebRTC PeerConnection negotiation. If the conversion of the WebRTC JSEP SDP to barebone SDP is successful, a generated event is sent back to the user:

{
        "event" : "generated",
        "type" : "<offer|answer, depending on the nature of the provided JSEP>",
        "sdp" : "<barebone SDP content>"
}

The process request, instead, must be formatted as follows:

{
        "request" : "process",
        "type" : "<offer|answer, depending on the nature of the provided SDP>",
        "sdp" : "<barebone SDP to convert>"
        "info" : "<opaque string that the user can provide for context; optional>",
        "srtp" : "<whether to mandate (sdes_mandatory) or offer (sdes_optional) SRTP support; optional>",
        "srtp_profile" : "<SRTP profile to negotiate, in case SRTP is offered; optional>"
}

As anticipated, this requires a "legacy" SDP offer or answer passed via NoSIP plugin messaging, which is why the caller must specify if it's an offer or answer. If the request is successful, a processed event is sent back to the user, along to the JSEP offer or answer that Janus generated out of the barebone SDP:

{
        "event" : "processed",
        "srtp" : "<whether the barebone SDP mandates (sdes_mandatory) or offers (sdes_optional) SRTP support; optional>"
}

To close a session you can use the hangup request, which needs no additional arguments, as the whole context can be extracted from the current state of the session in the plugin:

{
        "request" : "hangup"
}

An hangingup event will be sent back, as this is an asynchronous request.

Finally, just as in the SIP and SIPre plugins, the multimedia session can be recorded. Considering the NoSIP plugin also assumes two peers are in a call with each other (although it makes no assumptions on the signalling that ties them together), it works exactly the same way as the SIP and SIPre plugin do when it comes to recording. Specifically, you make use of the recording request to either start or stop a recording, using the following syntax:

{
        "request" : "recording",
        "action" : "<start|stop, depending on whether you want to start or stop recording something>"
        "audio" : <true|false; whether or not our audio should be recorded>,
        "video" : <true|false; whether or not our video should be recorded>,
        "peer_audio" : <true|false; whether or not our peer's audio should be recorded>,
        "peer_video" : <true|false; whether or not our peer's video should be recorded>,
        "filename" : "<base path/filename to use for all the recordings>"
}

As you can see, this means that the two sides of conversation are recorded separately, and so are the audio and video streams if available. You can choose which ones to record, in case you're interested in just a subset. The filename part is just a prefix, and dictates the actual filenames that will be used for the up-to-four recordings that may need to be enabled.

A recordingupdated event is sent back in case the request is successful.