Benny Prijono wrote: > On Thu, Aug 14, 2008 at 11:51 AM, Pedro Gon?alves > <pedro.pandre at gmail.com <mailto:pedro.pandre at gmail.com>> wrote: > > > 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 <http://192.168.1.91> > m=audio 5134 RTP/AVP 0 101 > a=rtcp:5135 IN IP4 192.168.1.91 <http://192.168.1.91> > > > Like I said, that's not the point. ICE negotiation fails, and that's > it. Fix the server. > > > > This way, IMHO, caller should be able to send RTP packets to > 192.168.1.91:5134 <http://192.168.1.91:5134> and RTCP packets to > 192.168.1.91:5135 <http://192.168.1.91:5135>. > Why doesn't he do that? > > > If connectivity check succeeds to that destination, then packets will > be sent to that address. But it failed, so it doesn't send it to > there. That's what ICE is supposed to do. > > > > If I disable ICE, the above works. > > > This is exactly what frustrates me. You're building a B2BUA, which > modifies the SDP and ICE, it somehow breaks ICE connectivity checks, > and now you're complaining that the client needs to be fixed. This is > frustrating for me. > > > > > > > > > 192.168.1.91 <http://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. > > > If it's working, then why there's no connectivity checks received by > caller? Nor connectivity check response for that matter. > > > 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. > > > > > Well that's the problem. If you're building an ICE aware B2BUA, then > you must know how ICE works and how to make it to play friendly with > any ICE clients (i.e. how to not break ICE). I can't tell you how, and > there's no IETF drafts to explain this yet, so you must work this out > yourself from reading ICE protocol. > > > 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. > > > I have not tried that myself, but I've tried with four other TURN > servers (can't name them here for confidentiality reason) and the TURN > client in pjnath works fine. So as long as that project follows the > latest TURN draft I wouldn't expect any problems with it. > If you can't name the servers you used, could you tell us about a free TURN server implementation? I am trying TurnServer, and I already managed to install and run it. I am using PJSUA to test it, but PJSUA is complaing about its responses: 18:53:28.397 stun_msg.c Error parsing STUN attribute XOR-MAPPED-ADDRESS: Invalid STUN attribute length (PJNATH_ESTUNINATTRLEN) 18:53:28.397 udprel01FCA278 STUN msg_decode() error: Invalid STUN attribute length (PJNATH_ESTUNINATTRLEN) I attached the log and the capture I made. What is your opinion about this? Is it a problem in TurnServer? Cheers Pedro Gon?alves -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: log.log Url: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080814/4fa65937/attachment-0001.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: turn_error.pcap Type: application/octet-stream Size: 13447 bytes Desc: not available Url : http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080814/4fa65937/attachment-0001.obj
