@babelforce/babelconnect-sdk 0.11.0 → 0.13.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +5 -0
- package/dist/client.d.ts +46 -1
- package/dist/client.js +86 -2
- package/dist/embed/iife-entry.d.ts +32 -0
- package/dist/embed/iife-entry.js +28 -0
- package/dist/embed/index.d.ts +44 -4
- package/dist/embed/index.js +68 -16
- package/dist/gen/babelconnect/v1/babelconnect_connect.d.ts +58 -23
- package/dist/gen/babelconnect/v1/babelconnect_connect.js +77 -37
- package/dist/gen/babelconnect/v1/babelconnect_pb.d.ts +655 -4
- package/dist/gen/babelconnect/v1/babelconnect_pb.js +864 -4
- package/dist/version.d.ts +1 -1
- package/dist/version.js +1 -1
- package/dist/web/babelconnect-embed.iife.js +1 -0
- package/package.json +4 -2
- package/CHANGELOG.md +0 -18
|
@@ -3,31 +3,36 @@
|
|
|
3
3
|
/* eslint-disable */
|
|
4
4
|
// @ts-nocheck
|
|
5
5
|
// Package babelconnect.v1 is the control protocol between a babelconnect client
|
|
6
|
-
// (the SDK, via Go/Dart/gRPC-web) and babelconnect-server. It carries
|
|
7
|
-
// ONLY — media is WebRTC on a separate plane; the server terminates the
|
|
8
|
-
// WebRTC leg.
|
|
6
|
+
// (the SDK, via Go/Dart/gRPC-web/Connect) and babelconnect-server. It carries
|
|
7
|
+
// CONTROL ONLY — media is WebRTC on a separate plane; the server terminates the
|
|
8
|
+
// client's WebRTC leg.
|
|
9
9
|
//
|
|
10
10
|
// State lives on the SERVER, not the client. babelconnect-server holds the
|
|
11
11
|
// canonical per-agent AgentView and pushes an initial snapshot + entity-level
|
|
12
|
-
// patches over the
|
|
12
|
+
// patches over the Subscribe stream; clients are DUMB RENDERERS — they apply
|
|
13
13
|
// patches mechanically and send Command intents, with no domain logic.
|
|
14
14
|
//
|
|
15
|
-
//
|
|
15
|
+
// Three entry points:
|
|
16
16
|
// - Authenticate: unary handshake → the agent's identity.
|
|
17
|
-
// -
|
|
18
|
-
//
|
|
19
|
-
//
|
|
20
|
-
//
|
|
21
|
-
//
|
|
22
|
-
//
|
|
17
|
+
// - Subscribe: the server→client half — StateUpdate (snapshot then
|
|
18
|
+
// patches). The WebRTC offer rides on CallState (when
|
|
19
|
+
// RINGING); the client answers via the AnswerCall intent —
|
|
20
|
+
// signaling fits the state model, no separate event channel.
|
|
21
|
+
// - Send: the client→server half — one Command intent per call
|
|
22
|
+
// (register/place/answer/hangup/mute/...). Together with
|
|
23
|
+
// Subscribe this is the one blessed shape for every client
|
|
24
|
+
// (RPC-A4 retired the earlier bidi `Session` RPC once all
|
|
25
|
+
// clients had moved onto this split over the Connect
|
|
26
|
+
// protocol).
|
|
23
27
|
//
|
|
24
28
|
// The bearer token travels in gRPC metadata ("authorization: Bearer <token>")
|
|
25
29
|
// on every call; Authenticate additionally returns the resolved identity.
|
|
26
30
|
//
|
|
27
|
-
// In addition to gRPC/gRPC-web, the unary RPCs are exposed as a
|
|
28
|
-
// via grpc-gateway (the google.api.http annotations below)
|
|
29
|
-
// — one proto source of truth, two wire surfaces.
|
|
30
|
-
|
|
31
|
+
// In addition to gRPC/gRPC-web/Connect, the unary RPCs are exposed as a
|
|
32
|
+
// REST+JSON surface via grpc-gateway (the google.api.http annotations below)
|
|
33
|
+
// with an OpenAPI v2 spec — one proto source of truth, two wire surfaces.
|
|
34
|
+
// Streaming stays gRPC/gRPC-web/Connect.
|
|
35
|
+
import { Ack, AgentView, AuthenticateRequest, Command, GetStateRequest, HistoryRequest, HistoryResponse, Identity, ListCampaignsRequest, ListCampaignsResponse, ListDispositionsRequest, ListDispositionsResponse, PhonebookRequest, PhonebookResponse, SendSmsRequest, SmsConversation, SmsThreadRequest, SmsThreadResponse, StateUpdate, SubscribeRequest, TransferTargetsRequest, TransferTargetsResponse } from "./babelconnect_pb.js";
|
|
31
36
|
import { MethodKind } from "@bufbuild/protobuf";
|
|
32
37
|
/**
|
|
33
38
|
* @generated from service babelconnect.v1.Agent
|
|
@@ -48,28 +53,15 @@ export const Agent = {
|
|
|
48
53
|
kind: MethodKind.Unary,
|
|
49
54
|
},
|
|
50
55
|
/**
|
|
51
|
-
*
|
|
52
|
-
*
|
|
53
|
-
*
|
|
54
|
-
*
|
|
55
|
-
*
|
|
56
|
-
*
|
|
57
|
-
*
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
name: "Session",
|
|
61
|
-
I: Command,
|
|
62
|
-
O: StateUpdate,
|
|
63
|
-
kind: MethodKind.BiDiStreaming,
|
|
64
|
-
},
|
|
65
|
-
/**
|
|
66
|
-
* Subscribe + Send are the browser-friendly split of Session: a browser speaks
|
|
67
|
-
* gRPC-web, which cannot client-stream, so the bidi Session is impossible there.
|
|
68
|
-
* Subscribe is the server→client half (the StateUpdate stream); Send is the
|
|
69
|
-
* client→server half (one Command per unary call). Together they are equivalent
|
|
70
|
-
* to Session for a single agent — the server keys both to the agent's one state
|
|
71
|
-
* store. Command rejections still arrive as an Error on the Subscribe stream
|
|
72
|
-
* (never on Send's reply), exactly as on Session.
|
|
56
|
+
* Subscribe + Send are the control stream, split into its server→client and
|
|
57
|
+
* client→server halves — the one shape every client uses (RPC-A4 retired the
|
|
58
|
+
* earlier bidi `Session` RPC, which needed HTTP/2 end-to-end and couldn't
|
|
59
|
+
* ride gRPC-web or a plain HTTP/1.1 ingress). Subscribe is the server→client
|
|
60
|
+
* half (StateUpdate: one snapshot on open, then entity-level patches; UI =
|
|
61
|
+
* f(AgentView)). Send is the client→server half (one Command per unary
|
|
62
|
+
* call). Together they key to the agent's one state store. Command
|
|
63
|
+
* rejections arrive as an Error on the Subscribe stream, never on Send's
|
|
64
|
+
* reply.
|
|
73
65
|
*
|
|
74
66
|
* @generated from rpc babelconnect.v1.Agent.Subscribe
|
|
75
67
|
*/
|
|
@@ -130,6 +122,24 @@ export const Agent = {
|
|
|
130
122
|
O: PhonebookResponse,
|
|
131
123
|
kind: MethodKind.Unary,
|
|
132
124
|
},
|
|
125
|
+
/**
|
|
126
|
+
* GetTransferTargets autocompletes blind-transfer / add-member targets as the
|
|
127
|
+
* agent types — agents, raw numbers, and IVR applications (GET
|
|
128
|
+
* /agent/calls/transfer/targets?query=, bc-standalone-2
|
|
129
|
+
* src/components/Common/NumberListSelect.vue:59). `query` filters server-side
|
|
130
|
+
* (substring across name/email/number for agents, name for applications); the
|
|
131
|
+
* backend has no call-context param, so eligibility by call direction is a
|
|
132
|
+
* separate, already-server-computed flag the client applies itself
|
|
133
|
+
* (CallState.can_transfer_to_application hides APPLICATION results — CALL-I3).
|
|
134
|
+
*
|
|
135
|
+
* @generated from rpc babelconnect.v1.Agent.GetTransferTargets
|
|
136
|
+
*/
|
|
137
|
+
getTransferTargets: {
|
|
138
|
+
name: "GetTransferTargets",
|
|
139
|
+
I: TransferTargetsRequest,
|
|
140
|
+
O: TransferTargetsResponse,
|
|
141
|
+
kind: MethodKind.Unary,
|
|
142
|
+
},
|
|
133
143
|
/**
|
|
134
144
|
* GetState returns the agent's current AgentView as a single unary call — the
|
|
135
145
|
* REST/web "get current state" (the Subscribe stream is the realtime twin). When
|
|
@@ -157,5 +167,35 @@ export const Agent = {
|
|
|
157
167
|
O: SmsConversation,
|
|
158
168
|
kind: MethodKind.Unary,
|
|
159
169
|
},
|
|
170
|
+
/**
|
|
171
|
+
* ListCampaigns lists the outbound-dialer campaigns the agent may join (the
|
|
172
|
+
* Outbound tab's campaign picker, OBDA1) — on-demand reference data like
|
|
173
|
+
* GetPhonebook/GetTransferTargets, backed by GET /api/v2/agent/outbound/
|
|
174
|
+
* campaigns?active=true (sbf/services ObdController#listCampaigns).
|
|
175
|
+
*
|
|
176
|
+
* @generated from rpc babelconnect.v1.Agent.ListCampaigns
|
|
177
|
+
*/
|
|
178
|
+
listCampaigns: {
|
|
179
|
+
name: "ListCampaigns",
|
|
180
|
+
I: ListCampaignsRequest,
|
|
181
|
+
O: ListCampaignsResponse,
|
|
182
|
+
kind: MethodKind.Unary,
|
|
183
|
+
},
|
|
184
|
+
/**
|
|
185
|
+
* ListDispositions lists the available call-outcome codes for the disposition
|
|
186
|
+
* picker (OBDC1) — on-demand reference data like ListCampaigns, backed by GET
|
|
187
|
+
* /api/v2/agent/outbound/campaigns/{id}/dispositions (sbf/services
|
|
188
|
+
* ObdController#listDispositions). Grounded: the `{id}` path segment is never
|
|
189
|
+
* read server-side — the list is a static global, not campaign-scoped — so the
|
|
190
|
+
* request carries no campaign id either.
|
|
191
|
+
*
|
|
192
|
+
* @generated from rpc babelconnect.v1.Agent.ListDispositions
|
|
193
|
+
*/
|
|
194
|
+
listDispositions: {
|
|
195
|
+
name: "ListDispositions",
|
|
196
|
+
I: ListDispositionsRequest,
|
|
197
|
+
O: ListDispositionsResponse,
|
|
198
|
+
kind: MethodKind.Unary,
|
|
199
|
+
},
|
|
160
200
|
}
|
|
161
201
|
};
|