sip endpoint recebe chamadas diretas, mas não recebe redirecionamentos do registrador

2

Eu tenho um endpoint SIP, que eu escrevi, que recebe sip convida, processa, responde e configura a sessão rtp muito bem quando contatado diretamente.

i.e.

sip: user @ [endereço ip real do endpoint]

No entanto, se eu tentar encaminhar o registrador, ele nunca responderá. Se responder, responde com uma solicitação incorreta. Eu olhei para o pedido e está tudo bem, por isso não está mal formado (pelo menos quando é enviado).

No entanto, se o ponto final em questão origina a chamada, tudo funciona perfeitamente.

Estou testando com o ekiga, só para tirar meu código de pelo menos metade da equação.

Aqui está o pedido:

INVITE sip:[email protected] 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:[email protected]>;tag=c9ad0fb7-1707-1910-92f1-0025b360b492
Call-ID: c9ad0fb7-1707-1910-92f2-0025b360b492@HOWIE
To: <sip:[email protected]>
Contact: <sip:[email protected]>
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

O ponto final registra muito bem, como posso ver no registrador como registrado.

Além disso, o software para o endpoint está funcionando, porque ele também está sendo executado na minha área de trabalho e tudo funciona como esperado.

também, netstat -lvuwp mostra que meu aplicativo está escutando na porta 5060 como deveria.

atualização Acabei de notar que o registrador não está traduzindo o pedido na parte final do caminho. Eu vejo que receber o pedido em wireshark, diga 192.168.0.22 - > 192.168.0.200 (endereço do registrador), mas eu nunca vejo 192.168.0.200 - > 192.168.2.5 (o ponto final em questão) como acontece nos outros pontos finais.

Aqui está a tentativa de encaminhamento do registrador para o endpoint

INVITE sip:[email protected];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:[email protected]>;tag=03b6b0c7-1707-1910-9364-0025b360b492
Call-ID: 03b6b0c7-1707-1910-9365-0025b360b492@HOWIE
To: <sip:[email protected]>
Contact: <sip:[email protected]>
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

alguém vê o problema? Minha suspeita é que o problema é com o ;q1, <sip que não parece pertencer.

atualização

Eu notei essa linha

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

do REGISTER para meu endpoint o texto ;q=1, <sip me fez pensar que o servidor sip está tendo problemas para analisar o ipv6. Então, eu desliguei o ipv6 no endpoint e voila! está tudo bem.

    
por Jonathan Henson 21.05.2012 / 17:53

0 respostas

Tags