No RTP sent after successful ICE negotiation when using PJSIP 1.5

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

 



Hi Benny,

Thanks for the swift reply!

On 26 Jan 2010, at 17:13, Benny Prijono wrote:

> On Tue, Jan 26, 2010 at 3:47 PM, Ruud Klaver <r.klaver at sping.nl> wrote:
>> Hi all,
>> 
>> We have built an application based on PJSIP and have recently upgraded from using version 1.0.3 to version 1.5. This is running quite well and the operation went relatively smoothly. However, we ran into a situation where no RTP is sent to the remote host by PJSIP when establishing a session using ICE.
>> 
>> The scenario is the following: Two sip endpoints are behind the same NAT. Both endpoints are using exactly the same software, using PJSIP 1.5. PJSUA is configured to use a STUN server, but not a TURN server. The logs and SIP trace show that the SDP negotiation was successful and the internal IP candidate was selected for both endpoints. However, for some reason neither endpoint starts sending RTP.
>> 
> 
> Did you see (in the log) whether ICE negotiation has been successful?
> No RTP packets can be exchanged before ICE negotiation is successful.

Yes, it specifically mentions this in the logs. Also, it's sending an UPDATE request reflecting the result of the negotiation (I gather this is a new feature in 1.5).

> 
>> The only strange thing that I can find in the logs is that two stream objects are created for the one session, but I am not sure if this is somehow related.
>> 
> 
> Now that's weird, and I don't think we support two steram objects in
> one call! That could explain the whole thing.

One seems to be created when the INVITE is received (I only looked at the callee in this case) and one is created when a 200 OK to the received UPDATE is sent.

Would it help if I included the logs?

> 
>> Has anyone used ICE successfully with version 1.5 (specifically with two endpoints behind the same NAT)? Does this problem sound familiar to anyone?
>> 
> 
> I think I must have at least made one successful call with this scenario. ;-)
> 
> But we are now in 1.5.5 of course, and considering that 1.5.5 was
> released specificly to fix bugs, things may behave differently in 1.5.
> 
> Best regards,
> 
> Benny

I did consider that, however I did not see any bugfixes that seemed to be relevant to this issue. I could still give it a try.

Best regards,
Ruud Klaver


[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