Записать маршрут, игнорируемый при отправке подтверждения

У меня странная проблема, когда pjsip игнорирует информацию о маршруте записи при отправке подтверждения. Ниже приведен поток sip-сообщений из журналов:

INVITE sip:[email protected];transport=tls SIP/2.0
Via: SIP/2.0/TLS ipv4.addr:38890;rport;branch=z9hG4bKPjdYP6TZrj4w7v8kicC3cBgABBNb47QHH2;alias
Max-Forwards: 70
From: "+558" <sip:[email protected]>;tag=qfc3TEYcpfIBQHVXMOmh.7pyvqgmVdMh
To: sip:[email protected]
Contact: "+558" <sip:[email protected]>
Call-ID: 7FdLGhQ1L5BjAQsUrCPEOB3WbXipRfs1
CSeq: 18162 INVITE
Route: <sip:xxx.com:5061;transport=tls;lr>
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
User-Agent: SecuVOICE BB10 CSE 2.14.0.1 on Z10 10.3.1.2243
Authorization: Digest xxxx
Content-Type: application/x-x509-user-cert
Content-Length:

SIP/2.0 200 OK
Max-Forwards: 10
Via: SIP/2.0/TLS ipv4.addr:38890;rport=38890;received=ipv4.addr;branch=z9hG4bKPjdYP6TZrj4w7v8kicC3cBgABBNb47QHH2;alias
Record-Route:<sip:xxx.com:5061;transport=tls;lr;ftag=qfc3TEYcpfIBQHVXMOmh.7pyvqgmVdMh;cookie_=e43.052768f7>
Call-ID: 7FdLGhQ1L5BjAQsUrCPEOB3WbXipRfs1
From: "+558" <sip:[email protected]>;tag=qfc3TEYcpfIBQHVXMOmh.7pyvqgmVdMh
To: <sip:[email protected]>;tag=RuDb.RX-9YD0V.BKh0rpj61-SK-ORE5B
CSeq: 18162 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Contact: "+110" <sip:[email protected]:25365>
Supported: replaces, 100rel, timer, norefersub
Content-Type: multipart/mixed;boundary=SBC1hJLGTAfp3t2j3HYWIvvgUBsC1RpJ
Content-Length: 27

ACK sip:[email protected]:25365 SIP/2.0 
"+110" <sip:[email protected]:25365>
Via: SIP/2.0/TLS ipv4.addr:38890;rport;branch=z9hG4bKPjkp-dUZmmgpXNWrZHe2ykqvrr9CgRvlm2;alias
Max-Forwards: 70
From: "+558" <sip:[email protected]>;tag=qfc3TEYcpfIBQHVXMOmh.7pyvqgmVdMh
To: sip:[email protected];tag=RuDb.RX-9YD0V.BKh0rpj61-SK-ORE5B
Call-ID: 7FdLGhQ1L5BjAQsUrCPEOB3WbXipRfs1
CSeq: 18162 ACK
Route: <sip:xxx.com:5061;transport=tls;lr;ftag=qfc3TEYcpfIBQHVXMOmh.7pyvqgmVdMh;cookie_=e43.052768f7>
Content-Type: application/sdp
Content-Length:   709

Глядя на маршрут записи из 200 OK, я ожидал, что ACK будет выглядеть как ACK sip:[email protected]:25365;transport=tls;lr SIP/2.0

Почему pjsip игнорирует параметр транспорта uri?


pjsip sip
person BTR Naidu    schedule 14.04.2015    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Полученная запись-маршрут копируется как маршрут в новый исходящий запрос в диалоговом окне.

Исключение составляет случай, когда URI Record-Route не содержит параметр «;lr». Это обратно совместимое поведение с RFC 2543.

URI запроса исходящего запроса устанавливается равным полученному заголовку Contact.

См. RFC 3261, раздел 12.2.1.1.

UAC использует удаленную цель и набор маршрутов для создания поля Request-URI и заголовка Route запроса.

Если набор маршрутов пуст, UAC ДОЛЖЕН поместить удаленный целевой URI в Request-URI. UAC НЕ ДОЛЖЕН добавлять поле заголовка Route в
запрос.

Если набор маршрутов не пуст, а первый URI в наборе маршрутов
содержит параметр lr (см. Раздел 19.1.1), UAC ДОЛЖЕН поместить
удаленный целевой URI в Request-URI и ДОЛЖЕН включить поле заголовка Route
, содержащее значения набора маршрутов по порядку, включая все параметры
.

Если набор маршрутов не пуст и его первый URI не содержит параметр lr, UAC ДОЛЖЕН поместить первый URI из набора маршрутов в Request-URI, удалив любые параметры, которые не разрешены в Request-URI. UAC ДОЛЖЕН добавить поле заголовка Route, содержащее остальные значения набора маршрутов по порядку, включая все параметры. Затем UAC ДОЛЖЕН поместить удаленный целевой URI в поле заголовка Route в качестве последнего значения.

Набор маршрутов либо предварительно сконфигурирован, либо изучен через Record-Route.

Целевой URI обновляется при получении заголовка Contact от другой стороны.

person jsantander    schedule 14.04.2015
comment
Что можно сделать, чтобы ACK также добавил transport=tls? - person BTR Naidu; 14.04.2015
comment
Добавьте его в URI контакта в 200 OK.... но я не уверен, что это будет иметь значение, так как сообщение будет отправлено на основе первого URI маршрута (свободный маршрутизатор). - person jsantander; 14.04.2015
comment
Поможет ли удаление ;lr из начального INVITE? - person BTR Naidu; 14.04.2015
comment
@BTRNaidu, не уверен, что это вызовет желаемый эффект. Конечно, это будет означать, что вы ожидаете инфраструктуру RFC2543 вместо RFC3261. И это, вероятно, приведет к тому, что запрос будет обрабатываться по-другому или не будет обрабатываться вообще. - person jsantander; 14.04.2015
comment
@BTRNaidu, в любом случае, я не уверен, какое неожиданное поведение вы испытываете. Как я уже сказал, несмотря на то, что Request-URI не содержит параметр транспорта, поскольку у вас есть свободный заголовок маршрута, запрос должен быть отправлен на первый URI заголовка маршрута, который содержит параметр транспорта. URI запроса не имеет значения при наличии свободного маршрутизатора. - person jsantander; 14.04.2015