Yohann Martineau, blog

Posts from 2009-09

Peers resurrection!

2009-09-29 23:25:59

After many months of silence, peers is back...

Even if its GUI did not change, real improvements have been performed. The most significant feature added is reINVITE management. This feature implies that peers accepts incoming INVITEs within dialogs. But it also implies that RTP media sending is updated with new remote IP address and port. As only one codec is supported by peers (G711), codec does not need to be updated. If several codecs were supported, codec should also be updated correctly. Actually, reINVITE support was necessary to achieve asterisk interoperability. This is the reason why it has been implemented. It seems that many students are trying peers against asterisk IPBX. And re-INVITE management is also a requirement of SIP specification RFC3261.

The second important step was challenge (authentication) management on INVITEs. For the moment, 401 and 407 status codes (challenge responses) were only supported on REGISTER method. But now, INVITEs can also receive 401 or 407 and a new call is performed 1,5 seconds after challenge reception (I should shorten this interval when I'll find the time...). This implementation was also a requirement for asterisk. Most deployed sip proxy/registrars use authentication on INVITEs, thus it seems reasonable to implement it in peers.

Another critical update has been done on sound quality. Microphone sound was captured correctly, RTP packets were also correctly sent, but there was an issue (ergh... a long standing issue...) on g711 encoder. Apparently the previous encoder performance was weak. I'm now using mobicents media server g711 encoder which works very well and is simple to use. Another issue remains on media capture: javasound TargetDataLine is not always available with the following parameters: 16 bits, 8kHz, little-endian, signed, mono-channel. Actually, it seems that lines are frequently available but at least one parameter will vary. Thus I should implement a way to translate from one frequency to another (resampling), from one sample size to another, etc. For the moment, this is not done.

So what next? For the moment, configuration is done in a very simple xml file. But it would be much better to do it in a window. It would probably broaden peers users community and enlarge users scope. Another critical update is on transport layer. For the moment, a naive transport is implemented: one udp packet = one sip packet. And no TCP management is performed. But it would be much better to support TCP and packet fragmentation. The target is to remove RTP stack dependency on jrtp and implement peers' own rtp stack. Another point is: "no dependency", xerces and jaxen dependency should be removed (xpath is not this useful... and dom is reliable).

Thus, you can now test peers on local networks or enterprise area. But it has not been tested on internet with NAT traversal. Another thing to do...

Permanent link
protocol, peers, english

Comments