Искажение Request URI в обработчике MyLocationServer

[alx]

Получаем такое сообщение:

INVITE sip:test66@192.168.1.67:5060;line=127 SIP/2.0

В MyLocationServer::process() видим такой запрос:

INVITE sip:192.168.1.67:5060 SIP/2.0

В результате в таком виде сообщение и форвардится в шлюз, который ожидаемо отвечает "404 Not Found".

Такой эффект наблюдается, когда FreeSwitch отправляет запрос по TCP, так как решил, что он слишком большой для отправки по UDP.

[alx]

Сообщение, вызывающее проблему:

INVITE sip:test66@192.168.1.67:5060;line=127;transport=tcp SIP/2.0
Via: SIP/2.0/TCP [2a02:2698:27:9e51:100::9787];branch=z9hG4bK7FBvXcBmXp25r
Route: <sip:[2a02:2698:27:9e51:100::67]:5060>;transport=tcp;lr;drr
Route: <sip:192.168.1.67:5060>;transport=udp;lr;drr
Max-Forwards: 70
From: "" <sip:0000000000@[2a02:2698:27:9e51:100::9787]>;tag=BDZN4eH8pSDFm
To: <sip:test66@192.168.1.67:5060;line=127;transport=tcp>
Call-ID: e8aee941-af00-1234-9696-902b3433882b
CSeq: 92738401 INVITE
Contact: <sip:mod_sofia@[2a02:2698:27:9e51:100::9787]:5060;transport=tcp>
User-Agent: FreeSWITCH-mod_sofia/1.6.7+git~20160401T013613Z~d38d065f51~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, pre
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 291
X-FS-Support: update_display,send_info
Remote-Party-ID: <sip:0000000000@[2a02:2698:27:9e51:100::9787]>;party=calling;screen=yes;privacy=off

v=0
o=FreeSWITCH 1466121506 1466121507 IN IP6 2a02:2698:27:9e51:100::9787
s=FreeSWITCH
c=IN IP6 2a02:2698:27:9e51:100::9787
t=0 0
m=audio 27424 RTP/AVP 0 8 18 9 3
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:9 G722/8000
a=rtpmap:3 GSM/8000'.Q.......g.-.....9
a=ptime:20

[alx]

Сценарий SIPP, воспроизводящий баг

[alx]

Как показала проверка, проблемы вызывает строчка
Route: <sip:192.168.1.67:5060>;transport=udp;lr;drr.
При ее удалении вызов принимается.

[alx]

В данном случае, предположительно, виноват шлюз. Он не проверяет наличие поля Route в заголовке, а оно там есть, и содержит реальный Request-URI:

        INVITE sip:192.168.1.67:5060 SIP/2.0
        Via: SIP/2.0/UDP 192.168.1.67:5060;branch=z9hG4bK-524287-1---6720f0766dbd0e3a;rport
        Via: SIP/2.0/TCP [2a02:2698:25:264b:100::82e4];branch=z9hG4bK-39025-1-0
        Max-Forwards: 69
        Route: <sip:test55@192.168.1.67:5060;transport=tcp;line=127>
        Record-Route: <sip:192.168.1.67:5060;transport=udp;lr;drr>
        Record-Route: <sip:[2a02:2698:25:264b:100::67]:5060;transport=tcp;lr;drr>
        Contact: <sip:mod_sofia@[2a02:2698:25:264b:100::82e4]:5060;transport=tcp>
        To: <sip:test55@192.168.1.67:5060;line=127;transport=tcp>
        From: "" <sip:0000000000@[2a02:2698:25:264b:100::82e4]>;tag=39025SIPpTag001
        Call-ID: 1-39025@2a02:2698:25:264b:100::82e4
        CSeq: 92738401 INVITE
        Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
        Content-Disposition: session
        Content-Type: application/sdp
        Supported: timer, path, replaces
        User-Agent: FreeSWITCH-mod_sofia/1.6.7+git~20160401T013613Z~d38d065f51~64bit
        Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description
        Remote-Party-ID: <sip:0000000000@[2a02:2698:25:264b:100::82e4]>;party=calling;screen=yes;privacy=off
        X-FS-Support: update_display,send_info
        Content-Length: 272

        v=0
        o=FreeSWITCH 1466121506 1466121507 IN IP6 local_ip
        s=FreeSWITCH
        c=IN IP6 2a02:2698:25:264b:100::82e4
        t=0 0
        m=audio 27424 RTP/AVP 0 8 18 9 3
        a=rtpmap:0 PCMU/8000
        a=rtpmap:8 PCMA/8000
        a=rtpmap:18 G729/8000
        a=rtpmap:9 G722/8000
        a=rtpmap:3 GSM/8000
        a=ptime:20

Отдельный вопрос, почему прокси переписал Request-URI, если все элементы исходного маршрута имели параметр lr...

[alx]

Проблема оказалась в том, как в сообщении указан параметр lr: если вместо
Route: <sip:192.168.1.67:5060>;transport=udp;lr;drr
указывать
Route: <sip:192.168.1.67:5060;lr;drr>;transport=udp
то все работает правильно - Request URI не переписывается.

Похоже, FreeSwitch неправильно добавляет lr в Route. Однако, чтобы правильно работать с тем, что встречается в реальном мире, надо анализировать Route в шлюзе.

[alx]

Окончательно принято решение, что баг не у нас. Наш код исправлять не будем.