You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* \c hold , \c unhold , \c update and \c hangup . \c register can be used,
42
42
* as the name suggests, to register a username at a SIP registrar to
43
43
* call and be called, while \c unregister unregisters it; \c call is used
44
-
* to send an INVITE to a different SIP URI through the plugin, while
45
-
* \c accept and \c decline are used to accept or reject the call in
46
-
* case one is invited instead of inviting; \c transfer takes care of
47
-
* attended and blind transfers (see \ref siptr for more details);
48
-
* \c hold and \c unhold can be used respectively to put a
44
+
* to send an INVITE to a different SIP URI through the plugin; in case one
45
+
* is invited instead of inviting, \c progress, \c accept and \c decline
46
+
* requests may be used. \c progress request is optional, and it is used to
47
+
* send 183 Session Progress response back to the caller, while
48
+
* \c accept and \c decline are used to accept or reject the call respectively;
49
+
* \c transfer takes care of attended and blind transfers (see \ref siptr for
50
+
* more details); \c hold and \c unhold can be used respectively to put a
49
51
* call on-hold and to resume it; \c info allows you to send a generic
50
52
* SIP INFO request, while \c dtmf_info is focused on using INFO for DTMF
51
53
* instead; \c message is the method you use to send a SIP message
@@ -299,8 +301,28 @@
299
301
\endverbatim
300
302
*
301
303
* The \c incomingcall may or may not be accompanied by a JSEP offer, depending
302
-
* on whether the caller sent an offerless INVITE or a regular one. Either
303
-
* way, you can accept the incoming call with the \c accept request:
304
+
* on whether the caller sent an offerless INVITE or a regular one. Optionally,
305
+
* you can progress the incoming call with the \c progress request:
306
+
*
307
+
\verbatim
308
+
{
309
+
"request" : "progress",
310
+
"srtp" : "<whether to mandate (sdes_mandatory) or offer (sdes_optional) SRTP support; optional>",
311
+
"headers" : "<object with key/value mappings (header name/value), to specify custom headers to add to the SIP OK; optional>"
312
+
"autoaccept_reinvites" : <true|false, whether we should blindly accept re-INVITEs with a 200 OK instead of relaying the SDP to the browser; optional, TRUE by default>
313
+
}
314
+
\endverbatim
315
+
*
316
+
* A \c progressing event will be sent back, as this is an asynchronous request.
317
+
*
318
+
* This will result in a <code>183 Session Progress</code> to be sent back to the caller.
319
+
* A \c progress request must always be accompanied by a JSEP answer (if the
320
+
* \c incomingcall event contained an offer) or offer (in case it was an
321
+
* offerless INVITE). This request can be used to inform the caller that the early
322
+
* media is available, such as ringback audio, announcements or other audio streams,
323
+
* without the call being fully established.
324
+
*
325
+
* Furthermore, you can accept the incoming call with the \c accept request:
304
326
*
305
327
\verbatim
306
328
{
@@ -314,13 +336,13 @@
314
336
* An \c accepting event will be sent back, as this is an asynchronous request.
315
337
*
316
338
* This will result in a <code>200 OK</code> to be sent back to the caller.
317
-
* An \c accept request must always be accompanied by a JSEP answer (if the
318
-
* \c incomingcall event contained an offer) or offer (in case it was an
319
-
* offerless INVITE). In the former case, an \c accepted event will be
320
-
* sent back just to confirm the call can be considered established;
321
-
* in the latter case, instead, an \c accepting event will be sent back
322
-
* instead, and an \c accepted event will only follow later, as soon as
323
-
* a JSEP answer is available in the SIP ACK the caller sent back.
339
+
* As was the case for \c progress request, an \c accept request must always
340
+
* be accompanied by a JSEP answer (if the \c incomingcall event contained an
341
+
* offer) or offer (in case it was an offerless INVITE). In the former case,
342
+
* an \c accepted event will be sent back just to confirm the call can be
343
+
* considered established; in the latter case, instead, an \c accepting event
344
+
* will be sent back instead, and an \c accepted event will only follow later,
345
+
* as soon as a JSEP answer is available in the SIP ACK the caller sent back.
324
346
*
325
347
* Notice that in case you get an incoming call while you're in another
326
348
* call, you will NOT get an \c incomingcall event, but a \c missed_call
0 commit comments