Posts tagged protocol
asterisk SIP unregister not working
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
registrar.
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.
Comments
peers-0.4 small is beautiful!
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.
Comments
Send audio and video to X-Lite using ffmpeg
Send Video
I've been struggling for long to find a way to send video to X-Lite. Now I can, using sipp and ffmpeg. I'm using a custom sipp script based on uas scenario. I've just added video media in uas script, in 200 OK SDP, using H263-1998 media description (and attributes) proposed in X-Lite SDP offer. This media contains size options (QCIF, CIF, etc.). Then I send INVITE to sipp from X-Lite using an account that does not need registration. I look at traces to find the port on which X-Lite is willing to receive video RTP packets, and I send a video to X-Lite using the following command:
ffmpeg -re -i file.flv -f rtp -an -vcodec h263 -s 176x144 rtp://1.2.3.4:5678
file.flv is a video retrieved from youtube using any youtube grabber website.
But don't try this using ffmpeg as is, because ffmpeg always send RTP packets using payload type 96, which is a dynamic payload type. To make it work, you have to apply the following patch on ffmpeg, to use a payload type proposed by X-Lite, here 115:
index 5df101e..3c15a8b 100644
--- a/libavformat/rtpenc.c
+++ b/libavformat/rtpenc.c
@@ -78,7 +78,7 @@ static int rtp_write_header(AVFormatContext *s1)
s->payload_type = ff_rtp_get_payload_type(st->codec);
if (s->payload_type < 0)
- s->payload_type = RTP_PT_PRIVATE + (st->codec->codec_type == AVMEDIA_TY
+ s->payload_type = 115;
s->base_timestamp = ff_random_get_seed();
s->timestamp = s->base_timestamp;
If I understand correctly, for the moment, it's not possible to manually set the payload type of RTP packets sent from ffmpeg. A long thread on ffmpeg mailing list seems to show that it's not possible yet.
This patch is (of course) not for production use, but at least, it works. Let's hope that ffmpeg will make this parameter configurable...
Send audio
To send audio, it's quite "easy", the following command should work out of the box :
ffmpeg -re -i file.flv -vn -acodec pcm_mulaw -ar 8000 -ac 1 -f rtp rtp://1.2.3.4:5678?pkt_size=172
Here, the trick is to force ffmpeg to use 172 UDP packets, because X-Lite only accept RTP packets which payload size is exactly 160. RTP (standard) header size is 12 bytes, thus pkt_size must be 172.
Comments
Peers resurrection!
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...
Comments
Peers 0.3 is out!
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:
- X-Lite, the legacy one...
- OpenWengo, Neuf's one, based on Aymeric Moizard sip stack
- LinPhone, the reliable one, and
- Ekiga, the example
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.
Comments
Ecouter de la musique celtique gratuitement
Etant apprenti sonneur (joueur de cornemuse), je suis amateur de musique celtique. Or celle-ci se fait plutôt rare sur le web... légalement tout du moins.
En effet, en parcourant le site allcelticmusic.com, je me suis rendu compte que ce n'était peut-être pas si difficile que ça d'entendre ses artistes préférés... En parcourant le site je me suis rendu compte qu'il était possible d'écouter en entier les chansons de certains albums. Si un lecteur flash peut lire cette musique, alors il doit être possible de la lire autrement ! Mon premier réflexe a été de faire une capture de ce qui circulait sur le réseau avec wireshark. Mais rien de très inspirant à priori... un player flash est retourné dans une page s'appelant player.html...
J'ai donc téléchargé à la main l'applet flash permettant d'écouter la musique. L'utilitaire file de linux m'a appris que ce fichier correspondait à :
Macromedia Flash compressed data, version 7.Rien de surprenant, donc. Cependant, il est rare qu'une donnée compressée soit absoluement impossible à décompresser... Une recherche sur google m'a donc emmené vers un exécutable windows en version d'évaluation permettant de décompresser les fichiers .swf compressés. Le nom de cet exécutable est asvdemo, contenu dans une archive : asvdemo.zip.
Pour lancer cet exécutable windows sous linux, il suffit donc simplement de "l'enrouler" avec wine :
wine avsdemo.exe
Cet utilitaire une fois lancé, permet d'explorer le contenu du fichier .swf, c'est-à-dire de l'Action Script, intéressant. Il est également possible d'exporter le contenu de ce qui a pu être décompressé vers un simple fichier texte, c'est donc ce que j'ai fait, l'environement fourni par wine n'étant pas ce qu'il y a de plus ergonomique...
Un petit coup d'oeil sur ce fichier, et là ô miracle, une variable s'appelle fileUrl :
var fileUrl = "w47bc/";
Dans le fichier player.html retourné précédemment, il y avait tout de même une variable nommée file=297.mp3 dans une url ou dans les paramètres passés à l"objet flash"
C'est ce qui m'a mis sur la voie d'un wget bien inspiré :
wget http://www.allcelticmusic.com/w47bc/297.mp3
Le fichier téléchargé, je pouvais écouter à ma guise l'air que je cherchais de Robert Mathieson, un grand soliste de cornemuse écossaise ; ce sans lecteur flash et sans perte de qualité (un simple enregistrement du mixeur de mon système d'exploitation aurait permis l'enregistrement, mais avec une conversion numérique => analogique supplémentaire).
Malheureusement, dès aujourd'hui (manipulation réalisée hier, le 9 décembre 2007), le site a changé de présentation et le player flash n'est plus accessible, il n'est de plus plus possible d'écouter des titres en ligne... La supercherie aurait-elle été démasquée ? Aucune idée, cependant on ne pourra pas m'accuser de piratage, vu que cette astuce ne fonctionne plus désormais.
Cela dit, le principe de "décrypter" du flash pour retrouver des urls vers des fichiers multimédia reste valable et probablement applicable à d'autres sites. Il suffit de les chercher...
Comments
Ecouter des extraits sur le site de la FNAC sous debian
Comme le titre de cet article le laisse supposer, ce n'est pas immédiat sous debian de lire des extraits musicaux d'albums sur le site de la fnac. Cela dit, à coeur vaillant rien d'impossible, il est donc possible de lire ces flux mutlimedia d'une façon (un peu) détournée.
Prenons un exemple, je vais sur l'album de Peter Cincotti : East of Angel Town. Je clique sur Goodbye Philadelphia, et je choisis ouvrir, avec un éditeur de texte, gedit fera très bien l'affaire. Là, je vois que ce fichier contient simplement une URI :
pnm://multimedia.fnac.com/audio/3/9/7/0093624991793A02.ra
Première observation, je ne connais pas le préfixe de cette URI, en revanche l'extension du fichier ne semble pas totalement inconnue : .ra extension des fichiers Real Player. Après une petite recherche sur google, j'apprends que ce protocole est le nouveau nom du protocole PNA, dont j'ignore la signification. En investigant légèrement plus je découvre que ce protocole est assez proche du RTSP, intéressant... Autre point intéressant à noter, le port part défaut de ce protocole est le port 7070.
Je décide donc de tenter ma chance avec mplayer, car bien que mplayer ne supporte ce procole PNM, il supporte le procole RTSP. Je lance donc la commande suivante dans mon terminal préféré :
mplayer rtsp://multimedia.fnac.com:7070/audio/3/9/7/0093624991793A02.ra
et là, ô surprise, après un léger temps de mise en mémoire tampon, la lecture du début de la chanson commence !
Le "hasard" faisant plutôt bien les choses, si vous voulez écouter plusieurs chansons, elles sont dans l'ordre, la prochaine chanson, Be Careful, peut s'écouter avec l'URI suivante :
rtsp://multimedia.fnac.com:7070/audio/3/9/7/0093624991793A03.ra
Comments
Peers : nouveau softphone SIP
Bonjour,
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:192.168.0.1
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.
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.