even if it doesn't make sense to most of us because the coding is unknown and no codec is available: is it possible to retrieve or upload voice messages from/to a sx353 phone with integrated answering machine?
i hope i _might_ be able to recognize some familiar pattern in the data and guess the framing, algorithm and parameters from that.
although it is some time since when i last studied voice codecs (more than 10 years, to be honest...)
so if some of you already managed to download a voice message from the phone, please let me have a look at the bits
kawk
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
According to the "Herkules" docs by Siemens, which were originally for the 307x but seem to cover the SX353 too, there are AT commands to transfer all kinds of messages (announcements, infos, and incoming voice messages) both from and to the base.
These are the commands AT^SABINFO, AT^SABSTART, AT^SABGET, AT^SABPUT, AT^SABDEL, AT^SABDELLST, and the corresponding messages ZABINFO and ZABDEL.
But as the data format is undocumented, we never implemented that interface in the usermode frontend tool, gigacontr.
Nevertheless, this should be possible if someone who is comfortable with reading German (as the "Herkules" docs I mentioned are in German) and C application programming (the frontend) finds the time to do it.
If you don't feel up to it yourself, post a feature request and hopefully one of the team will some day pick it up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Deutsch ist meine Muttersprache, Doku waer interessant. I'd take lib/sms.c as a reference for a lib/ab.c... However, I can't promise to have any coding finished in finite time. Is it possible to access the gigaset (via USB) with cu / minicom / whatever to try the commands manually? When I try /dev/ttyG, the driver reports "gigaset: can't write to unlocked device" or cu says "cu: /dev/ttyGU0: System not found". I guess there is an easy way to trigger emission of any (binary) voice message via tty..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Die Dokumentation des Befehlssatzes liegt im Dateibereich der Yahoo Group "Siemens-Gigaset". http://de.groups.yahoo.com/group/Siemens-Gigaset/files/ - Datei AT-Kommandos.pdf.
Wenn Du Dich nicht extra bei der Gruppe anmelden willst, kann ich sie Dir auch mailen. (knapp 1 MB)
Sending the commands through minicom or cu won't buy you much because the actual data transfer uses a proprietary block oriented transmission protocol with checksums and acknowledgements, which is also described in the "AT-Kommandos" document. It's actually the same protocol used by SMS transfers, so starting from lib/sms.c is a good idea.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The only difference (besides the initial AT commands) should be the "datatype" numbers for gigaset_blockreceive() and gigaset_blocksend(). You can find them on page 114 (9.2.2, "Blockdatenarten") of the document Tilman mentioned.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i prepared an --abdump command that allows me to download all recorded messages from my phone as binary files. My first impression is that it's probably some differential (ADPCM) coding; not as complicated as LP (linear prediction) coding but also not as simple as a-law/u-law.
OTOH, I was only looking at "high quality" recordings. Those space-saving ones might be using more complicated encoding --- and I may be completely wrong anyway ;) --- it will require some puzzling.
Now i have to postpone further experiments until weekend... If you want samples of the recordings for your own experiments, please leave me a message at +49-40-88913034 and I'll e-mail you (offer valid until 2006-jan-31). call mo...fr during daytime, otherwise I might answer the call personally...
Kolja
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I don't know anything about audio stuff, I can't do a lot with the samples (I don't know, if Tilman can use them). Thanks, anyway. But I could commit your new code (--abdump) to cvs, if you want ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Great news. I am looking forward to anything you'll find out. Perhaps we'll someday be able to play recorded messages or record new announcements on the PC, after all.
Meanwhile, I think it would be a good idea to include your code in the project, if you like. I won't attempt to "crack" the audio encoding myself, as I don't really know very much about that. But perhaps there are others who might have a go.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I uploaded some additional code in the patch section here. It seems utterly unstable and sometimes I had to use -vv to slow down things or couldn't download anything from the phone. But maybe someone with more experience regarding Siemens' interface may do that part better.
Unfortunately, uploading messages back to the phone doesn't work; it seems to expect some other data structure as it is sent when downloading messages.
And even more unfortunately, I have not yet been able to decode the data. When I first looked at a recording of mostly noisy speech, it looked like one could clearly see zeros at the beginning (==silence) and end (==more silence) and speech between.
But more experiments with very clean silence (transmitted from a CAPI client attached to another ISDN terminal) and/or 300 Hz beeps at 1s interval don't give much hope now.
It still looks similar to the noisy speech recording: There are leading and trailing lots of zeroes, but more or less "random" numbers between.
The file size per second varies; it is small if the input was clean (zero or sine) and larger if input was noisy (speech). Therefore, the bits/sample ratio probably isn't constant. But it may as well be due to silence being detected and cut off the data.
More thoughts will follow (hopefully). Maybe someone else can fix the --abput command to re-upload messages back to the phone? That would at least allow for archiving of greetings...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I hope, I can have a closer look at it this week. I committed it without any changes. Thanks, so far. Also for trying to decode the stuff; sounds kind of frustrating ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regarding the upload data structure, Siemens once offered a "phrase download tool" which advertised the ability to replace the standard announcements. (They seemed to consider the direction from PC to base "down".) Perhaps one could use that and log the USB traffic it produces with USBSnoop. Unfortunately I only downloaded it for talk&surf version 5, corresponding to firmware version 3.x, and my own base has since been upgraded to firmware 4.204, so I can't do that test myself.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In order to use the /dev/ttyG* interface, the driver must be in "Unimodem mode" as described in section 3.5 of the README file. The error message "can't write to unlocked device" appears if you try to access the driver through /dev/ttyG while it is in "isdn4linux mode". (Perhaps we should change the wording of that message.)
So for your experiments, either load the module with the parameter "startmode=0" (eg. by setting the startmode to "unimodem" in gigasetconfig if you are running SuSE), or switch to unimodem mode explicitly by giving the command:
# gigacontr --dev /dev/ttyGU0 --mode unimodem
But as I wrote earlier, you won't get very far with the voice message commands without an implementation of the block transfer protocol.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
even if it doesn't make sense to most of us because the coding is unknown and no codec is available: is it possible to retrieve or upload voice messages from/to a sx353 phone with integrated answering machine?
i hope i _might_ be able to recognize some familiar pattern in the data and guess the framing, algorithm and parameters from that.
although it is some time since when i last studied voice codecs (more than 10 years, to be honest...)
so if some of you already managed to download a voice message from the phone, please let me have a look at the bits
kawk
According to the "Herkules" docs by Siemens, which were originally for the 307x but seem to cover the SX353 too, there are AT commands to transfer all kinds of messages (announcements, infos, and incoming voice messages) both from and to the base.
These are the commands AT^SABINFO, AT^SABSTART, AT^SABGET, AT^SABPUT, AT^SABDEL, AT^SABDELLST, and the corresponding messages ZABINFO and ZABDEL.
But as the data format is undocumented, we never implemented that interface in the usermode frontend tool, gigacontr.
Nevertheless, this should be possible if someone who is comfortable with reading German (as the "Herkules" docs I mentioned are in German) and C application programming (the frontend) finds the time to do it.
If you don't feel up to it yourself, post a feature request and hopefully one of the team will some day pick it up.
Deutsch ist meine Muttersprache, Doku waer interessant. I'd take lib/sms.c as a reference for a lib/ab.c... However, I can't promise to have any coding finished in finite time. Is it possible to access the gigaset (via USB) with cu / minicom / whatever to try the commands manually? When I try /dev/ttyG, the driver reports "gigaset: can't write to unlocked device" or cu says "cu: /dev/ttyGU0: System not found". I guess there is an easy way to trigger emission of any (binary) voice message via tty..
Die Dokumentation des Befehlssatzes liegt im Dateibereich der Yahoo Group "Siemens-Gigaset". http://de.groups.yahoo.com/group/Siemens-Gigaset/files/ - Datei AT-Kommandos.pdf.
Wenn Du Dich nicht extra bei der Gruppe anmelden willst, kann ich sie Dir auch mailen. (knapp 1 MB)
Sending the commands through minicom or cu won't buy you much because the actual data transfer uses a proprietary block oriented transmission protocol with checksums and acknowledgements, which is also described in the "AT-Kommandos" document. It's actually the same protocol used by SMS transfers, so starting from lib/sms.c is a good idea.
The only difference (besides the initial AT commands) should be the "datatype" numbers for gigaset_blockreceive() and gigaset_blocksend(). You can find them on page 114 (9.2.2, "Blockdatenarten") of the document Tilman mentioned.
Okay,
i prepared an --abdump command that allows me to download all recorded messages from my phone as binary files. My first impression is that it's probably some differential (ADPCM) coding; not as complicated as LP (linear prediction) coding but also not as simple as a-law/u-law.
OTOH, I was only looking at "high quality" recordings. Those space-saving ones might be using more complicated encoding --- and I may be completely wrong anyway ;) --- it will require some puzzling.
Now i have to postpone further experiments until weekend... If you want samples of the recordings for your own experiments, please leave me a message at +49-40-88913034 and I'll e-mail you (offer valid until 2006-jan-31). call mo...fr during daytime, otherwise I might answer the call personally...
Kolja
As I don't know anything about audio stuff, I can't do a lot with the samples (I don't know, if Tilman can use them). Thanks, anyway. But I could commit your new code (--abdump) to cvs, if you want ;)
Great news. I am looking forward to anything you'll find out. Perhaps we'll someday be able to play recorded messages or record new announcements on the PC, after all.
Meanwhile, I think it would be a good idea to include your code in the project, if you like. I won't attempt to "crack" the audio encoding myself, as I don't really know very much about that. But perhaps there are others who might have a go.
I uploaded some additional code in the patch section here. It seems utterly unstable and sometimes I had to use -vv to slow down things or couldn't download anything from the phone. But maybe someone with more experience regarding Siemens' interface may do that part better.
Unfortunately, uploading messages back to the phone doesn't work; it seems to expect some other data structure as it is sent when downloading messages.
And even more unfortunately, I have not yet been able to decode the data. When I first looked at a recording of mostly noisy speech, it looked like one could clearly see zeros at the beginning (==silence) and end (==more silence) and speech between.
But more experiments with very clean silence (transmitted from a CAPI client attached to another ISDN terminal) and/or 300 Hz beeps at 1s interval don't give much hope now.
It still looks similar to the noisy speech recording: There are leading and trailing lots of zeroes, but more or less "random" numbers between.
The file size per second varies; it is small if the input was clean (zero or sine) and larger if input was noisy (speech). Therefore, the bits/sample ratio probably isn't constant. But it may as well be due to silence being detected and cut off the data.
More thoughts will follow (hopefully). Maybe someone else can fix the --abput command to re-upload messages back to the phone? That would at least allow for archiving of greetings...
I hope, I can have a closer look at it this week. I committed it without any changes. Thanks, so far. Also for trying to decode the stuff; sounds kind of frustrating ;-)
Regarding the upload data structure, Siemens once offered a "phrase download tool" which advertised the ability to replace the standard announcements. (They seemed to consider the direction from PC to base "down".) Perhaps one could use that and log the USB traffic it produces with USBSnoop. Unfortunately I only downloaded it for talk&surf version 5, corresponding to firmware version 3.x, and my own base has since been upgraded to firmware 4.204, so I can't do that test myself.
mailen waer gut (sf AT ixo.de), ich moecht' mich ungern wegen nur 1 datei bei yahoo anmelden. dank schonmal im voraus!
kolja
Ah, the cu error message actually was caused by wrong args. With correct args, I get the can't write to unlocked device driver error.
In order to use the /dev/ttyG* interface, the driver must be in "Unimodem mode" as described in section 3.5 of the README file. The error message "can't write to unlocked device" appears if you try to access the driver through /dev/ttyG while it is in "isdn4linux mode". (Perhaps we should change the wording of that message.)
So for your experiments, either load the module with the parameter "startmode=0" (eg. by setting the startmode to "unimodem" in gigasetconfig if you are running SuSE), or switch to unimodem mode explicitly by giving the command:
# gigacontr --dev /dev/ttyGU0 --mode unimodem
But as I wrote earlier, you won't get very far with the voice message commands without an implementation of the block transfer protocol.