HRESULT 0x80EE000F (RTC_E_SIP_AUTH_HEADER

Код состояния / ошибки:		Категория:

Имя константы:
Источник:		Операционная система:
Описание: Заголовок авторизации уже был отправлен в предыдущем запросе.

Предыдущий	Следующий
RTC_E_SIP_INVITE_TRANSACTION_PENDING	RTC_E_SIP_AUTH_TYPE_NOT_SUPPORTED

RTC_E_SIP_AUTH_HEADER_SENT

Интерпретация результата

RTC_E_SIP_AUTH_HEADER_SENT (0X80EE000F) означает: Authorization/Proxy-Authorization уже был отправлен для текущего challenge и transaction. Для диагностики важен первый возврат кода в конкретной transaction или object generation, а не наиболее заметная ошибка в UI.

Английский маркер для сопоставления с исходной документацией: the RTC authentication state already sent authorization for this challenge path and will not repeat it blindly. Используйте его как поисковый ключ вместе с timestamp и transaction/session ID.

Что сохранить

SIP method, Request-URI domain, Call-ID/CSeq и dialog tags.
Via/Route/Contact и transport (UDP/TCP/TLS) с responding hop.
transaction state, relevant header/SDP hash и первый RTC event/HRESULT.

Код-специфическая проверка

Сохраните challenge nonce/realm и CSeq, для которого Authorization уже был сформирован. Повторная вставка того же auth header в одну transaction может нарушить state machine; новый credential attempt должен быть связан с новым challenge или корректно увеличенным CSeq.

Сохраните raw start-line и относящиеся к ошибке headers до нормализации RTC; Call-ID/CSeq и responding Via связывают локальный callback с конкретной SIP transaction.

Разделите transport security, authentication challenge и authorization policy. Сохраните realm/scheme, certificate validation result и policy source; пароль, token и private key в журнал не записывайте.

Практический сценарий из EN-описания: A proxy repeats the same Digest challenge after the client has already answered it.. В воспроизведении меняйте только параметр или state, который отличает этот сценарий от рабочего.

Восстановление

Меняйте credential, certificate chain, transport или policy только на том уровне, который вернул отказ; повтор с теми же security inputs не считается исправлением.

После изменения повторите тот же вызов и сравните первый HRESULT, достигнутую фазу и побочные эффекты. Исправление подтверждено только если прежнее условие «Authorization/Proxy-Authorization уже был отправлен для текущего challenge и transaction» больше не возникает на сопоставимом входе.

Технические ссылки

Нужно найти другой код? Найти другой код состояния или ошибки.