Назад | Перейти на главную страницу

Конечная точка sip принимает прямые sip-вызовы, но не получает перенаправления от регистратора

У меня есть конечная точка SIP, которую я написал, которая принимает приглашения sip, обрабатывает их, отвечает и просто настраивает сеанс rtp при прямом контакте.

т.е.

sip: user @ [фактический IP-адрес конечной точки]

Однако, если я попытаюсь пройти через регистратора, он никогда не ответит. Если он отвечает, он отвечает неверным запросом. Я просмотрел запрос, все в порядке, поэтому он не искажен (по крайней мере, когда он отправлен).

Тем не менее, если рассматриваемая конечная точка инициирует вызов, все работает идеально.

Я тестирую с помощью ekiga, просто чтобы убрать мой код хотя бы из половины уравнения.

Вот просьба:

INVITE sip:1001@192.168.0.200 SIP/2.0
Date: Mon, 21 May 2012 15:42:26 GMT
CSeq: 1 INVITE
Via: SIP/2.0/UDP 192.168.0.22:5060;branch=z9hG4bK21b00fb7-1707-1910-92f3-0025b360b492;rport
User-Agent: Ekiga/3.2.7
From: "Jonathan" <sip:jonathan@192.168.0.200>;tag=c9ad0fb7-1707-1910-92f1-0025b360b492
Call-ID: c9ad0fb7-1707-1910-92f2-0025b360b492@HOWIE
To: <sip:1001@192.168.0.200>
Contact: <sip:jonathan@192.168.0.22>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING
Content-Type: application/sdp
Content-Length: 566
Max-Forwards: 70

v=0
o=- 1337614946 1 IN IP4 192.168.0.22
s=Opal SIP Session
c=IN IP4 192.168.0.22
t=0 0
m=audio 5084 RTP/AVP 0 8 101
a=sendrecv
a=rtpmap:0 PCMU/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,32,36
m=video 5086 RTP/AVP 109 108 34
b=AS:4096
b=TIAS:4096000
a=sendrecv
a=rtpmap:109 h264/90000
a=fmtp:109 packetization-mode=1;profile-level-id=42C01E
a=rtpmap:108 h263-1998/90000
a=fmtp:108 D=1;F=1;I=1;J=1;CIF=1;CIF4=1;QCIF=1;CUSTOM=320,240,1;CUSTOM=640,480,1
a=rtpmap:34 h263/90000
a=fmtp:34 F=1;CIF=1;CIF4=1;QCIF=1

Конечная точка регистрируется нормально, как я могу судить по регистратору как зарегистрированную.

Кроме того, программное обеспечение для конечной точки работает, потому что оно работает и на моем рабочем столе, и все работает так, как я ожидал.

кроме того, netstat -lvuwp показывает, что мое приложение прослушивает порт 5060 должным образом.

Обновить Я только что заметил, что регистратор не переводит запрос на финальную часть пути. Я вижу, что он получает запрос в wirehark, скажем, 192.168.0.22 -> 192.168.0.200 (адрес регистратора), но я никогда не вижу 192.168.0.200 -> 192.168.2.5 (рассматриваемая конечная точка), как на других конечных точках.

Вот попытка пересылки от регистратора к конечной точке

INVITE sip:1001@192.168.2.5;q=1, <sip SIP/2.0
Via: SIP/2.0/UDP 192.168.0.200:5060;branch=z9hG4bK-5bbc7711b807109;rport
Via: SIP/2.0/UDP 192.168.0.22:5060;branch=z9hG4bK5bb8b0c7-1707-1910-9366-0025b360b492;received=192.168.0.22;rport=5060
Date: Mon, 21 May 2012 16:28:56 GMT
CSeq: 1 INVITE
From: "Jonathan" <sip:jonathan@192.168.0.200>;tag=03b6b0c7-1707-1910-9364-0025b360b492
Call-ID: 03b6b0c7-1707-1910-9365-0025b360b492@HOWIE
To: <sip:1001@192.168.0.200>
Contact: <sip:jonathan@192.168.0.22>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING
Max-Forwards: 69
Record-Route: <sip:192.168.0.200;lr>
User-Agent: Ekiga/3.2.7
Content-Type: application/sdp
Content-Length: 566

v=0
o=- 1337617736 1 IN IP4 192.168.0.22
s=Opal SIP Session
c=IN IP4 192.168.0.22
t=0 0
m=audio 5066 RTP/AVP 0 8 101
a=sendrecv
a=rtpmap:0 PCMU/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,32,36
m=video 5068 RTP/AVP 109 108 34
b=AS:4096
b=TIAS:4096000
a=sendrecv
a=rtpmap:109 h264/90000
a=fmtp:109 packetization-mode=1;profile-level-id=42C01E
a=rtpmap:108 h263-1998/90000
a=fmtp:108 D=1;F=1;I=1;J=1;CIF=1;CIF4=1;QCIF=1;CUSTOM=320,240,1;CUSTOM=640,480,1
a=rtpmap:34 h263/90000
a=fmtp:34 F=1;CIF=1;CIF4=1;QCIF=1

кто-нибудь видит проблему? Я подозреваю, что проблема в ;q1, <sip это не похоже, что оно принадлежит.

Обновить

Я заметил эту строчку

[Contact] = <sip:vs005@192.168.2.5:5060>;q=1, <sip:vs005@[fe80::230:18ff:feab:100e]:5060>;q=0.500

из РЕГИСТРАТОРА для моей конечной точки ;q=1, <sip текст заставил меня подумать, что у sip-сервера проблемы с парсингом ipv6. Итак, я отключил ipv6 на конечной точке и вуаля! все хорошо.