ICE: Media not starting in caller

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Benny Prijono wrote:
> On Thu, Aug 14, 2008 at 11:05 AM, Pedro Gon?alves 
> <pedro.pandre at gmail.com <mailto:pedro.pandre at gmail.com>> wrote:
>
>     >  15:44:37.328 ICEVoiceTransp  ICE negotiation failed after 8s:422:
>     > Unknown error 370082
>     >
>     Hummm...
>     So basically, PJSIP won't send RTP packets until a STUN response is
>     received?
>     If so, why?!
>
>
> Because we don't know yet where to send the RTP packets to. And this 
> is not the problem anyway. The problem is ICE negotiation has failed, 
> and you can't expect RTP traffic to flow on this situation.
Yes we do know where to send packets to!
In 200 OK's SDP, the following lines give us all the info we need:
c=IN IP4 192.168.1.91
m=audio 5134 RTP/AVP 0 101
a=rtcp:5135 IN IP4 192.168.1.91

Here is the full SDP:
v=0
o=- 3427644972 3427644973 IN IP4 192.168.100.100
s=pjmedia
c=IN IP4 192.168.1.91
t=0 0
m=audio 5134 RTP/AVP 0 101
a=rtcp:5135 IN IP4 192.168.1.91
a=rtpmap:0 PCMU/8000
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ice-ufrag:301c0bdb
a=ice-pwd:56ae0732
a=candidate:S 1 UDP 31 172.18.0.211 1134 typ srflx raddr 192.168.100.100 
rport 2396
a=candidate:H 1 UDP 23 192.168.100.100 2396 typ host
a=candidate:H 1 UDP 23 169.254.127.178 2396 typ host
a=candidate:S 2 UDP 30 172.18.0.211 1135 typ srflx raddr 192.168.100.100 
rport 2397
a=candidate:H 2 UDP 22 192.168.100.100 2397 typ host
a=candidate:H 2 UDP 22 169.254.127.178 2397 typ host
a=candidate:Rac1200d4 1 UDP 0 192.168.1.91 5134 typ relay raddr 
192.168.100.100 4000
a=candidate:Rac1200d4 2 UDP 0 192.168.1.91 5135 typ relay raddr 
192.168.100.100 4001

This way, IMHO, caller should be able to send RTP packets to 
192.168.1.91:5134 and RTCP packets to 192.168.1.91:5135.
Why doesn't he do that?
If I disable ICE, the above works.

>  
>
>     192.168.1.91 <http://192.168.1.91> is a relay server (not a
>     standard TURN, unfortunately), and
>     the initial INVITE and the initial 200 OK INVITE should be enough to
>     establish connectivity between the two clients.
>     At that moment, they should be exchanging RTP / RTCP using that relay
>     server (at least that's what I wanted them to do).
>
>
> Obviously the relay server is not working (i.e. it doesn't seem to 
> forward STUN packets).
The relay server is indeed working.
The problem is that it doesn't understand STUN (as it is just a relay 
server) so it simply relays the STUN request to the answerer, which 
receives it in the rtp media stream, causing a decode error.
>  
>
>     So ICE simply fails and because of so no RTP data is sent?
>
>
> Yep. If ICE connectivity checks fails, then there's no point in 
> sending RTP since it will not reach the destination anyway. The media 
> transport gives you a callback to notify the application about ICE 
> negotiation status, and in PJSUA we disconnect the call if ICE 
> negotiation fails. That's probably what you should do too.
>
>
So, as my relay server is not turn and it already has some hacks 
(actually, it introduces relay candidates that correspond to its relay 
addresses and ports), do you have some suggestion?

I am starting to look to this recent TurnServer project: 
https://sourceforge.net/projects/turnserver/
Has anyone ever tried it?
I will try to install it and use it with PJSIP.

Best Regards
Pedro Gon?alves



[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux