ben.carrasco/next-static-site
1
0
Fork 0
mirror of https://github.com/jambonz/next-static-site.git synced 2025-12-19 04:47:44 +00:00
Code Issues Packages Projects Releases Wiki Activity

0.6.7 content (#23)

Browse Source 
* added docs for sip refer and bidrectional audio

* typos

* more detail on bidirectional audio

* say supports azure in 0.6.7

* minor updates

* minor
This commit is contained in:
Dave Horton
2021-11-20 14:20:30 -05:00
committed by GitHub
parent 0ac2b9e683
commit 469518e776
6 changed files with 93 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
data/docs.yml
View File

@@ -57,6 +57,12 @@ navi:
-
path: say
title: say
-
path: sip-decline
title: sip:decline
-
path: sip-refer
title: sip:refer
-
path: tag
title: tag

40
markdown/docs/webhooks/listen.md
View File

@@ -10,8 +10,6 @@ The listen verb can also be nested in a [dial](#dial) verb, which allows the aud
To utilize the listen verb, the customer must implement a websocket server to receive and process the audio. The endpoint should be prepared to accept websocket connections with a subprotocol name of 'audio.jambonz.org'.
The listen verb includes a **url** property which is the url of the remote websocket server to send the audio to. The url may be an absolute or relative URL. HTTP Basic Authentication can optionally be used to protect the websocket endpoint by using the **wsAuth** property.
The format of the audio data sent over the websocket is 16-bit PCM encoding, with a user-specified sample rate. The audio is sent in binary frames over the websocket connection.
Additionally, one text frame is sent immediately after the websocket connection is established. This text frame contains a JSON string with all of the call attributes normally sent on an HTTP request (e.g. callSid, etc), plus **sampleRate** and **mixType** properties describing the audio sample rate and stream(s). Additional metadata can also be added to this payload using the **metadata** property as described in the table below. Once the intial text frame containing the metadata has been sent, the remote side should expect to receive only binary frames, containing audio. The remote side is not expected to send any data back over the websocket.
@@ -41,6 +39,44 @@ You can use the following options in the `listen` action:
| wsAuth.username | HTTP basic auth username to use on websocket connection | no |
| wsAuth.password | HTTP basic auth password to use on websocket connection | no |
<h4 id="#birectional_audio">Bidirectional audio</h4>
Audio can also be sent back over the websocket to jambonz. This audio, if supplied, will be played out to the caller. (Note: Bidirectional audio is not supported when the `listen` is nested in the context of a `dial` verb).
The far-end websocket server supplies bidirectional audio by sending a JSON text frame over the websocket connection:
```json
{
"type": "playAudio",
"data": {
"audioContent": "base64-encoded content..",
"audioContentType": "raw",
"sampleRate": "16000"
}
}
```
In the example above, raw (headerless) audio is sent. The audio must be 16-bit pcm encoded audio, with a configurable sample rate of either 8000, 16000, 24000, 32000, 48000, or 64000 khz. Alternatively, a wave file format can be supplied by using type "wav" (or "wave"), and in this case no `sampleRate` property is needed. In all cases, the audio must be base64 encoded when sent over the socket.
If multiple playAudio commands are sent before the first has finished playing they will be queued and played in order. You may have up to 10 queued playAudio commands at any time.
Once a `playAudio` command has finished playing out the audio, a `playDone` json text frame will be sent over the websocket connection:
```json
{
"type": "playDone"
}
```
A `killAudio` command can also be sent by the websocket server to stop the playout of audio that was started via a previous `playAudio` command:
```json
{
"type": "killAudio"
}
```
And finally, if the websocket connection wishes to end the `listen`, it can send a `disconnect` command:
```json
{
"type": "disconnect"
}
```
<p class="flex">
<a href="/docs/webhooks/lex">Prev: lex</a>
<a href="/docs/webhooks/message">Next: message</a>

2
markdown/docs/webhooks/rasa.md
View File

@@ -1,5 +1,5 @@
# rasa
> New in v0.6.6
> Added in v0.6.6
The `rasa` verb is used to connect a call to a [Rasa](https://rasa.com/) assistant.
```json

2
markdown/docs/webhooks/say.md
View File

@@ -18,7 +18,7 @@ You can use the following options in the `say` action:
| option | description | required |
| ------------- |-------------| -----|
| text | text to speak; may contain SSML tags | yes |
| synthesizer.vendor | speech vendor to use: Google or aws (polly is also an alias for aws)| no |
| synthesizer.vendor | speech vendor to use: <br>- 'google', <br>- 'aws', <br>- 'microsoft' (coming in v0.6.7)| no |
| synthesizer.language | language code to use. | no |
| synthesizer.gender | (Google only) MALE, FEMALE, or NEUTRAL. | no |
| synthesizer.voice | voice to use. Note that the voice list differs whether you are using aws or Google. Defaults to application setting, if provided. | no |

2
markdown/docs/webhooks/sip-decline.md
View File

@@ -27,5 +27,5 @@ You can use the following options in the `sip:decline` action:
<p class="flex">
<a href="/docs/webhooks/say">Prev: say</a>
<a href="/docs/webhooks/tag">Next: tag</a>
<a href="/docs/webhooks/sip-refer">Next: sip:refer</a>
</p>

46
markdown/docs/webhooks/sip-refer.md Normal file
View File

@@ -0,0 +1,46 @@
# sip:refer
> Coming in v0.6.7
The sip:refer action is used to blind transfer a call. It will send a sip REFER to the far end carrier or sip phone, which must support the REFER in order for the transfer to work. After the sip:refer completes successfully, the call leg will have left the jambonz platform.
```json
{
"verb": "sip:refer",
"referTo": +15083084809,
"actionHook": "/action"
}
```
You can use the following options in the `sip:refer` action:
| option | description | required |
| ------------- |-------------| -----|
| referTo | a sip uri or a phone number / user identifier | yes |
| referredBy | a sip uri or a phone number / user identifier; if not provided it will default to the identity of the party being transferred | no |
| actionHook | a webhook to call when the transfer has completed | no |
| eventHook | a webhook to call when NOTIFY messages of follow-on call status are received | no |
| headers | additional SIP headers to include in the response | no
The sip:refer verb completes when one of these conditions are met:
- a failure response is received to the REFER
- a 202 Accepted is received in response to the REFER, and a NOTIFY of the follow-on call status with a final call status is received.
The sip:refer has an action hook that will provide details of the final result, as well as an event hook that is called for every NOTIFY received after a successful REFER.
The *actionHook* webhook will contain the following additional parameters:
- `referStatus`: the sip status response to the REFER request
- `final_referred_call_status` - the final sip status of the subsequent call to the transferee. This is only provided in the case where the REFER is accepted and NOTIFY requests are received from the far end.
The *eventHook* webhook will contain two parameters: `event` and `call_status`. The `event` parameter will always be `transfer-status` and the `call-status` will contain a sip status received in a NOTIFY after a successful REFER; e.g.
```json
{
"event": "transfer-status",
"call_status": "180"
}
```
<p class="flex">
<a href="/docs/webhooks/sip-decline">Prev: sip:decline</a>
<a href="/docs/webhooks/tag">Next: tag</a>
</p>