Benny Prijono wrote: Hi Benny, > Miika, > > first of all sorry for the late reply. Comments below. > > On Wed, May 6, 2009 at 9:11 AM, Miika Komu <miika.komu at hiit.fi > <mailto:miika.komu at hiit.fi>> wrote: > > Hi, > > PJNATH complies to ice-19 according to the documentation: > > http://www.pjsip.org/pjnath/docs/html/index.htm > > "The implementation in PJNATH complies to > draft-ietf-mmusic-ice-19.txt draft" > > However, PJNATH doesn't include username in STUN responses as > instructed in the ICE specification: > > http://tools.ietf.org/html/draft-ietf-mmusic-ice-19#section-7.1.1.3 > > "A connectivity check from L to R (and its response of course) > utilize the username RFRAG:LFRAG and a password of RPASS. A > connectivity check from R to L (and its response) utilize the > username LFRAG:RFRAG and a password of LPASS." > > > I think that particular statement is not precise indeed, but I still > think that my interpretation is correct. > > First of all, STUN (RFC 5389) says: > http://tools.ietf.org/html/rfc5389#section-10.1.2 > > " If these checks pass, the agent continues to process the request or > indication. Any response generated by a server MUST include the > MESSAGE-INTEGRITY attribute, computed using the password utilized to > authenticate the request. The response MUST NOT contain the USERNAME > attribute. > " > > That is a very strong statement (the "MUST NOT") to not include USERNAME > in the response, and if any STUN usages (e.g. ICE) decide to violate > this (which I don't think is possible anyway), at least it must state it > in a equally strong statement and reasoning. I don't see anything like > this in ICE, so lacking this I see ICE uses the standard STUN > authentication mechanism. > > So the way I interpret that (ICE) statement, especially the word > "utilize", is ICE uses the combination of username LFRAG:RFRAG and > password LPASS when computing the MESSAGE-INTEGRITY. > > More over, it puts the word "username" there in lowercase. Normally one > would say USERNAME (in capital) to indicate STUN attribute. > > So in conclusion, I don't think the statement that you quoted above says > that we should include USERNAME in the STUN response. you're right. > We encountered also some other problems. For example, we are not > convinced that the pjnath prioritization algorithm works correctly > (at least in 0.8 version), or, maybe we are just using ICE wrong. > > > I'd like to hear more about this. It would be good if you could also > test the latest version, since there are quite few modifications and > fixes since 0.8 (0.8 is a year and half old!). I'll give you more feedback later when are using the latest version. The problem we had that ICE was testing the addresses (almost) in the wrong order until we changed the priorities to (UINT32_MAX - peer_priority). Otherwise, we were ending up with the TURN address even though a direct was available (due to wrong prioritization and aggressive mode).
