Azure OpenAI Realtime SIP /refer endpoint returns 500 Internal Server Error

Question

Azure OpenAI Realtime SIP /refer endpoint returns 500 Internal Server Error

Elias 0

Hi,

we are currently testing the Azure OpenAI Realtime API via SIP and are running into a 500 error when trying to transfer an active SIP call using the documented /refer endpoint.

What works:

Incoming SIP calls reach Azure OpenAI.
We receive a realtime.call.incoming webhook.
We use event.data.call_id from the webhook.
The call can be accepted and becomes active.

What fails:

Endpoint: https://<resource>.openai.azure.com/openai/v1/realtime/calls/<call_id>/refer
When calling the documented Refer endpoint for the active call, Azure returns: HTTP 500 Internal Server Error Response body: Internal Server Error
Example request: POST https://<resource>.openai.azure.com/openai/v1/realtime/calls/<call_id>/refer
Headers: api-key: <Azure OpenAI API key> Content-Type: application/json
Body: { "target_uri": "tel:+49157572*****" }

We also tested the request from Postman. The response is consistently 500 Internal Server Error. According to the documentation, the /refer endpoint should accept a target_uri such as +14155550123 or sip:agent@example.com and return 200 OK once the REFER is relayed to the SIP provider.

Can you give us a fix or work-around? Is this a service-side issue with the Realtime SIP /refer implementation or are there additional restrictions on target_uri formats, SIP URI transfers, or TLS transport parameters that are not documented? What can I do to redirect a call from the gpt-realtime model to a human?

Best regards, Elias!

Anshika Varshney 10,325 Reputation points Microsoft External Staff Moderator

2026-04-30T11:25:37.12+00:00
Hi Elias,

Thanks for sharing the details, this is a really good scenario, and you have already validated most of the important parts correctly.

From what you described, your flow is working fine up to call acceptance, and the failure only happens when calling the /refer endpoint. That is an important clue.

If the call

is received correctly

is accepted successfully

becomes active

and only the /refer call returns 500 every time, then this usually means the request is valid, but the service is failing internally.

In your case, the endpoint format and payload look correct, and the documented formats like +number or sip:address are already supported.

A consistent 500 response for a valid request usually indicates a service side issue or limitation in the current implementation of that endpoint, not a problem in your code.

How to verify your request format

Before assuming it is a backend issue, it is still worth double checking the basics:

Make sure your endpoint follows the correct realtime API format

POST https://resource.openai.azure.com/openai/v1/realtime/calls/call_id/refer

The realtime API uses the /openai/v1 base path for all operations.

Also confirm that

call_id is from the realtime.call.incoming event

API key is valid

Content-Type is application/json

To narrow it down clearly, you can try a few quick checks:

Test 1 Try different target_uri formats

Even though both are documented, test both styles

+123456789 sip:user@example.com

If both fail with the same 500 response, then it is unlikely to be a URI format issue

Test 2 Verify call state before refer

Make sure the call is still active when you call /refer

call must be accepted

not already ended or hanging up

Because the realtime API manages call lifecycle internally, calling refer on an invalid state could fail silently

Test 3 Confirm you are using supported realtime models

SIP integration works only with realtime models and supported regions.

If you are already able to accept calls successfully, this part is most likely correct in your setup

Test 4 Compare other endpoints

You can check if these endpoints still work

accept

reject

hangup

If all of them work and only refer fails, that further confirms the issue is isolated to the refer operation

Important observation

In your case

same request works for accept

same request fails for refer

no change on your side

consistent 500 response

This combination strongly points to a backend or feature limitation in the current preview implementation of SIP refer handling, rather than a configuration issue

Also, the documentation does not mention any extra constraints for refer beyond basic target_uri usage, which supports this conclusion.

Current workaround idea

Since refer is failing, the practical workaround depends on your flow

Instead of relying on refer

you can end the AI call using hangup

then trigger a new outbound call via your SIP provider to connect the user to a human agent

This is not exactly the same as call transfer, but it can help continue your scenario until refer behavior is stable

In short:

Your request format looks correct

target_uri values you used are valid

consistent 500 error suggests service side issue

no extra documented restrictions for refer endpoint

workaround is to handle transfer logic outside refer for now

If you can share which SIP provider you are using (like Twilio or others), I can help to suggest an alternative flow that works well with that setup.

I Hope this helps. Do let me know if you have any further queries.

Thankyou!
Anshika Varshney 10,325 Reputation points Microsoft External Staff Moderator

2026-05-01T09:12:50.56+00:00

Hi Elias,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution, please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

Thankyou!
Anshika Varshney 10,325 Reputation points Microsoft External Staff Moderator

2026-05-04T03:04:32.28+00:00

Hi Elias,
Please let me know if the issue persists after these checks. If you have any remaining questions or need additional details, I’ll be glad to provide further clarification or guidance. If the above steps resolve your issue, kindly confirm.

Thankyou!