On Thu, Aug 14, 2008 at 11:51 AM, Pedro Gon?alves <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 > m=audio 5134 RTP/AVP 0 101 > a=rtcp:5135 IN IP4 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 and RTCP packets to 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> 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. -benny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080814/042d6e79/attachment.html
