Yohann Martineau, blog

Posts tagged peers

asterisk SIP unregister not working

2013-08-03 15:40:17

For any reason, asterisk 11 requires a new SIP Call-ID to unregister a SIP account whereas RFC3261 SIP specification says that all REGISTERs should use the same Call-ID:

      Call-ID: All registrations from a UAC SHOULD use the same Call-ID
           header field value for registrations sent to a particular

           If the same client were to use different Call-ID values, a
           registrar could not detect whether a delayed REGISTER request
           might have arrived out of order.

Here is the paragraph in rfc3261 that proves that asterisk behavior is incorrect:

      6. The registrar checks whether the request contains the Contact
         header field.  If not, it skips to the last step.  If the
         Contact header field is present, the registrar checks if there
         is one Contact field value that contains the special value "*"
         and an Expires field.  If the request has additional Contact
         fields or an expiration time other than zero, the request is
         invalid, and the server MUST return a 400 (Invalid Request) and
         skip the remaining steps.  If not, the registrar checks whether
         the Call-ID agrees with the value stored for each binding.  If
         not, it MUST remove the binding.  If it does agree, it MUST
         remove the binding only if the CSeq in the request is higher
         than the value stored for that binding.  Otherwise, the update
         MUST be aborted and the request fails.

In my case, Call-ID is the same between register and unregister and unregister CSeq is higher than register CSeq.

If the same Call-ID is used between register and unregister, asterisk keeps returning 401 with a new challenge.

Nevertheless, apparently, asterisk accepts the same Call-ID for register-refreshes.

Opensips seems to accept different Call-ID between register and unregister, so let's go with that modification.

Peers updated accordingly.

Permanent link
telecom, protocol, peers, development, english


peers-0.4 small is beautiful!

2010-12-15 15:24:37

After more than one year of irregular development, bug fixing and refactoring, thinking, improving, thinking again and some short nights, a new release of peers is available!

In this release, you will find a brand new GUI, still based on swing, but using native look and feel.

javasound is still employed for microphone capture and contact's voice playback.

No more external library is employed in this release. Jrtp has been replaced with a new home made RTP stack. This RTP stack has been developed with the same keep it stupid simple philosophy as peers SIP stack.

As more and more people are using peers, interoperability tests have been performed against more IPBXs, gateways, hardphones and softphones. I don't have a complete list of compatible SIP elements, but this list is growing.

Amongst new features, the ability to configure your SIP account using Edit > Accout in menu bar will probably be the most important one. It implies that peers users no longer have to modify an xml file manually before peers startup.

If you are a voip customer and your internet service provider can give you a SIP account, you can try peers now to call from your PC. Depending on your internet service provider servers configuration, you may also receive calls on your PC using peers. Some service providers also enable you to place calls from anywhere in the world using your sip account and local rates towards fixed line phones.

Permanent link
english, development, internet service provider, java, peers, protocol


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


Peers 0.3 is out!

2009-03-31 22:03:42
Date originale : 2008-06-02

The latest peers release is out!

I've been working hard on this release for nights... it includes new features, such as REGISTER management. Of course this implies register-refresh and unregister management. But a register implementation would probably be useless without digest support. That's the reason why MD5 algorithm and challenges have been added in peers, as specified in RFC2617. This registration implementation has been tested against openser: the reference proxy/registrar implementation. For the moment Proxy-authenticate header has not been implemented but it should not be too complicated as it is exactly the same principle as www-authenticate header.

This release has been tested against more softphones than the previous release:

Many issues have been fixed in this release, and a new test framework has been used: TestNG. This framework is very impressive and very useful to test and track thread concurrency issues. It relies on java annotations and offers an impressive list of features. This is really a great tool.

Permanent link
protocol, peers, java, english


Peers : nouveau softphone SIP

2009-03-31 22:00:52
Date originale : 2 décembre 2007


Après plusieurs mois de développement, la première version de Peers est sortie ! Peers est un softphone SIP minimaliste écrit en java. Peers est donc un logiciel permettant de téléphoner d'un ordinateur à un autre sur un réseau local. Pour appeler une personne, il suffit de taper : sip: avec la bonne adresse. L'ordinateur appelé décroche automatiquement et l'appel est établi. Ensuite, l'appelé ou l'appelant peuvent raccrocher avec le bouton "hang up".

Pourquoi ?

En effet, il existe déjà d'autres piles SIP écrites en java, alors pourquoi se lancer dans cette implémentation ? Pour deux raisons. Premièrement, il n'existe à ma connaissance pas plus de deux implémentations open source en java d'une pile SIP :

  • Jain-sip, implémentée par NIST, un institut de recherche américain,
  • MjSip, implémentée par l'université de Parme.
Dans les deux cas, ces implémentations sont des implémentations complètes de la spécification de SIP : la RFC 3261, c'est-à-dire qu'il est possible de créér tous les éléments d'un réseau SIP grâce à ces implémentations : User-Agent, Proxy, Registrar, etc. Or, réaliser l'abstraction entre ces différents rôles ajoute une complexité importante aux implémentations. De plus, les ressources nécessaires dans la vie de tous les jours pour implémenter ces rôles sont très différentes. Je m'explique, un User-Agent est un softphone, c'est donc un logiciel qui va se lancer sur l'ordinateur d'un utilisateur. Cet utilisateur utilisera des fonctions éventuellement avancées au niveau media mais pas au niveau contrôle de session. SIP intervient au niveau du contrôle de sessions. Le User-Agent est en gros un logiciel client. Pour les autres rôles (Registrar, Proxy, ...) il s'agit d'implémenter des serveurs n'ayant aucune interface utilisateur et étant optimisés au maximum pour gérer un maximum de sessions en parallèle ou un maximum de messages, etc.

Pour en revenir aux autres implémentations, elles permettent donc de réaliser tous les éléments d'un réseau SIP, mais ce n'est pas le but de Peers. Le but de Peers est d'écrire un logiciel permettant le maximum d'interactions possibles avec les autres utilisateurs, et que ces fonctionnalités soient facilement évolutives. L'implémentation de Peers se veut simple. Malgré ses 10 000 lignes de code (environ), l'implémentation de peers se veut minimaliste et évolutive. C'est son évolutivité qui lui donne se volume. Le but de Peers n'est pas de devenir un serveur, mais bel et bien d'être lancé sur un poste utilisateur.

La deuxième raison est la possibilité d'apprendre par la pratique. Rien n'est plus formateur que de comparer son implémentation avec les plus réputées pour voir d'où viennent les problèmes, et ceci tout en lisant plusieurs fois les RFCs pour bien comprendre les concepts et ne pas tomber dans une implémentation uniquement empirique. SIP est pour moi un protocol nouveau, il y a un an, je ne connaissais rien à SIP.

Pour plus d'informations, vous pouvez me contacter par mail, voir ma page contact.

Permanent link
protocol, peers, multimedia, java, internet, development, français