![]() Offers and answers are communicated in Session Description Protocol (SDP) format, which look like this: v=0 JSEP requires the exchange between peers of offer and answer, the media metadata mentioned above. Instead, signaling state can be saved on a server. This would be problematic if, for example, signaling data was lost each time a page was reloaded. JSEP's architecture also avoids a browser having to save state, that is, to function as a signaling state machine. In this approach, the key information that needs to be exchanged is the multimedia session description, which specifies the necessary transport and media configuration information necessary to establish the media plane. The rationale is that different apps may prefer to use different protocols, such as the existing SIP or Jingle call signaling protocols, or something custom to the particular app, perhaps for a novel use case. The thinking behind WebRTC call setup has been to fully specify and control the media plane, but to leave the signaling plane up to the app as much as possible. This approach is outlined by the JavaScript Session Establishment Protocol (JSEP): To avoid redundancy and to maximize compatibility with established technologies, signaling methods and protocols are not specified by WebRTC standards. ![]() Why is signaling not defined by WebRTC? # First, however, you need a little context. Later in this article, you learn ways to build a signaling service. That mechanism is not implemented by the WebRTC APIs. This signaling process needs a way for clients to pass messages back and forth. Network data, such as a host's IP address and port as seen by the outside world. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |