feat(api): support backend-mediated Realtime WebRTC calls - #531
Conversation
Castiron-Internal-PR: openai/openai-ruby-internal#51 Castiron-Source-SHA: 26fe28916a996d3d868b7df6f722b3531d5a52ce Castiron-Public-Base-SHA: d638c57
Castiron custom code✅ No new custom-code files detected. 47 mixed files remain; 0 existing customizations changed; 1 generated baselines changed. Compared
46 existing customizations unchanged
6 more in the full report. A changed generated baseline means this report cannot reliably identify which handwritten lines changed. Inspect the custom-code diffDownload the exact patch produced by this run (requires repository access): gh run download 32890165452 --repo openai/openai-ruby \
--name castiron-custom-code-32890165452-1 --dir /tmp/castiron-custom-code-32890165452-1
git apply --stat /tmp/castiron-custom-code-32890165452-1/custom-code.patch
cat /tmp/castiron-custom-code-32890165452-1/custom-code.patchOr reproduce it from an SDK checkout containing the vendored reporter: git fetch --no-tags origin d638c57853bcd2d1afb44fdf5fc1f79e891c138e 8b75df6837258fd9471e11fdfa42c2f65b36fdd1
python3 scripts/castiron/custom_code_report.py report \
--base d638c57853bcd2d1afb44fdf5fc1f79e891c138e \
--head 8b75df6837258fd9471e11fdfa42c2f65b36fdd1 --fetch --require-head-hash --public \
--out /tmp/castiron-custom-code-8b75df683725
cat /tmp/castiron-custom-code-8b75df683725/custom-code.patchThis is the current full custom patch for mixed files, not an attribution of only the handwritten lines changed by this PR. |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8b75df6837
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ) | ||
| end | ||
|
|
||
| @client.request( |
There was a problem hiding this comment.
When a backend needs to monitor or terminate the newly created WebRTC call, the API supplies its call ID in the Location response header, but this request returns only the decoded StringIO; BaseClient#parse_response attaches response metadata only to BaseModel instances, and there is no raw-response accessor for this value. Consequently, after a successful create, callers cannot obtain the identifier required by hangup or monitoring endpoints. Return a response type or wrapper that retains the headers, and cover that behavior in the focused endpoint test.
AGENTS.md reference: AGENTS.md:L48-L52
Useful? React with 👍 / 👎.
jbeckwith-oai
left a comment
jbeckwith-oai
left a comment
There was a problem hiding this comment.
Requesting changes for the existing P1 discussion at lib/openai/resources/realtime/calls.rb:50. The new create method returns only a decoded StringIO, while the client attaches response metadata only to BaseModel values. The call identifier is returned in the Location response header, so a successful caller cannot recover the ID required to monitor or hang up its Realtime call. Return a raw-response/header-preserving wrapper or equivalent accessible response metadata and add a Location/call-ID regression. Existing inline discussion already captures this blocker.
2 participants
Summary
Add
realtime.calls.createso server-side applications can exchange an SDP offer and optional session configuration for an SDP answer.This makes WebRTC signaling available through the SDK instead of requiring a handwritten HTTP request. The new operation sends the API’s typed multipart parts and exposes the SDP answer as a
StringIO.