- 出荷済み
- 2026年4月26日 22:30 UTC
- プロフィール
- kamo
- コンテンツ
- 31f3f84
インバウンド・コール・パスの3つの調整された修正: 1. 受け入れている間視覚フィードバック。 両方のボタンを左に応答をクリック レスポンシブに見えるが、非応答性 — SDP 交渉は 1-3 秒かかります 呼び出しがライブされる前に、UI は何も表示しませんでした イベント SoftphoneState に isAccepting ステートを追加(セットイン) 回答()、********************セッションでクリア イベント incoming-call オーバーレイ 受け入れながら、今のモルファス: - 拒絶ボタンは収縮し、消えます - 回答ボタンが中央にスライドし、green→blueを交換し、ドロップします そのハンドセットアイコン、回転進行リングを獲得 - 応答ボタン停止のパルスリング - "Connecting..." ラベルは下でフェード ボタンも無効になっていて、ポインタが落ちるので 二重かちりと言う音は受諾飛行の間に拒絶することができません。 2. 接続の後で可聴周波無し。 WebRTC はリモート・オーディオの前に解決を受け入れます ピア接続にトラックが取り付けられているため、remoteAudio() を添付 トラックが存在しなかった瞬間にgetReceivers()をスキャンしました。 によって トラックが到着した時刻(~1-3 秒後)、ユーザージェスチャーウィンドウが app.play() は、自動再生ポリシーによって黙って拒否されました。 2つの修正: - SipJsSession.accept() がプライマリRemoteAudio() を呼び出すようになりました。 回答 クリックのジェスチャーコンテキスト (a play() 空の MediaStream は ブラウザがユーザー活性化として要素をフラグを立てるのに十分です。 - addRemoteAudio() 追加のホック pc.ontrack そのトラックを追跡する 設立後、到着時にオーディオ要素に追加されます。 設立時刻のスナップショットだけではありません。 3。 構成された着信音は、インバウンドコールのために再生しません。 着メロ 要素はSoftphoneProviderの台紙で作成されましたが、最初の play() コールは、インバウンドインビテットにありました - 一般的には、直前/時間後に ユーザジェスチャーなので、自動再生ポリシーがブロックされます。 ワンタイムを追加 最初のクリック/キーダウン/タッチスタートを聴くオーディオアンロックヘルパー ドキュメントでは、着信要素とSIPリモートの両方を優先します。 ミュートされた play→pause サイクルを経由してオーディオ要素は、それ自体を削除します。 アフター つまり、両方の要素は、ページの残りの部分にユーザアクティブ化されます 生涯とインバウンド リング + 音声再生をすぐに呼び出します.