**** BEGIN LOGGING AT Tue Sep 21 02:59:57 2010 Sep 21 03:11:24 hi there, I've got the idea that may be I could integrate ofono with FreeSWITCH (www.freeswitch.org) using the hands free profile, though I am still unsure about how many concurrent cell phones can bluez/ofono handle, any orientation would be appreciated :) Sep 21 03:33:20 In terms of pure signaling oFono can handle unlimited number of modems Sep 21 03:33:36 In case of bluetooth links / audio links it becomes much smaller Sep 21 04:01:24 denkenz: thx for the answer, so talking about audio links, what is going to draw the limit line? bandwidth? Sep 21 04:01:55 if you're talking HFP it is the number of SCO links supported Sep 21 04:02:19 I'm no longer up to date on Bluetooth stuff, but pretty sure the practical limit was 3 / adapter Sep 21 04:02:28 supported by whom? bluez or the standard per se? Sep 21 04:02:39 The standard Sep 21 04:02:46 But holtmann knows more Sep 21 04:04:45 oh I see, found this "The master device can support up to three SCO links, this might be to the same slave or to different slaves.", I guess that is what you're talking about Sep 21 04:05:55 From the standard. Two SCO links per one ACL. Meaning between two device (src + dst) you can have to max 3 SCO links. Sep 21 04:06:08 However in practice this is 1 SCO link per ACL. Sep 21 04:06:40 Wasn't there some other limit on a per device basis? Sep 21 04:06:42 You can have 7 links per piconet, but only up to 3 SCO link per piconet. No more bandwith is available. Sep 21 04:07:19 BlueZ also imposes 1 SCO link per 1 ACL link in the kernel. Since everything else has to relevance anyway. Sep 21 04:07:44 So effectively you can do 3 headsets per 1 Bluetooth adapter Sep 21 04:07:54 with audio Sep 21 04:08:21 What's the limit on adapters, is it 16 or 32? Sep 21 04:09:56 Either way, oFono's not the bottleneck ;) Sep 21 04:12:17 I see :) .... before finding ofono I tried "no hands" (http://nohands.sourceforge.net/), it seemed to require an audio card ... may sound stupid, but, can I then with ofono get the raw audio, either SLIN16, ulaw, alaw or whatever format comes from the cell? and also send raw audio? Sep 21 04:12:54 the audio in this case would come and go from FreeSWITCH (which at the other end can have SIP, IAX, or even a PSTN line with FXO/FXS or T1/E1) Sep 21 04:12:55 that is effectively what the sco socket is, raw audio Sep 21 04:13:22 denkenz: do you know the format? Sep 21 04:13:31 and sampling rate? Sep 21 04:13:52 sampling rate can vary, but it is fixed in Linux AFAIK Sep 21 04:15:01 Otherwise I think it is 8Khz Mono Sep 21 04:15:30 However, its been about 3 years since I last looked at SCO Sep 21 04:18:26 is there any sample code or any other places where I should start to look at this? other than plugins/hfp.c ? Sep 21 04:18:43 For SCO everything can be found in BlueZ git Sep 21 04:19:02 oFono does not deal with Audio, just the RFCOMM signaling layer Sep 21 04:19:41 ooh, I see ... so audio would be some kind of socket or /dev/xxx that I open and read/write from/to? Sep 21 04:20:05 more or less yes Sep 21 04:27:59 gotta go, thann denkenz and holtmann for your time, I'll surely be bugging you with more questions as I go, ttyl Sep 21 04:28:35 s/thann/thanks Sep 21 08:12:13 holtmann: a question comes across when I reading ofono/src/log.c Sep 21 08:12:19 holtmann: we have extern struct ofono_debug_desc __start___debug[]; at log.c line 153. but I cann't find the define place of this variable. Sep 21 08:12:41 holtmann: any clues? thanks. Sep 21 08:15:32 zhenhua: Yes, I do. Sep 21 08:15:49 It is linker magic actually. Sep 21 08:16:14 __attribute__((used, section("__debug"), aligned(8))) Sep 21 08:16:57 That create a special section in the binary. The start and end symbols are present with __start_ and __end_ prefixing. Sep 21 08:17:07 s/__end_/__stop_/ Sep 21 08:21:16 holtmann: i do see the DBG macro in log.h. Sep 21 08:21:31 but where is __start and __end? Sep 21 08:21:47 As I said, the linker creates these automatically for you. Sep 21 08:21:58 oh... i see Sep 21 08:22:01 thanks Sep 21 08:22:26 * zhenhua will try some nm and objdump Sep 21 08:22:58 Are you trying to understand how that works. It is really magic ;) Sep 21 08:23:19 yeah, sure, i am so interested about it. ;-) Sep 21 08:23:40 you only have a __attribute__((used, section("__debug"), aligned(8))) Sep 21 08:23:50 and how do u know this way? Sep 21 08:26:56 holtmann: objdump -d --section=__debug src/ofonod |less Sep 21 08:27:06 yes, i can see lots of data there now Sep 21 08:27:38 Yep. That are all DBG() statements and you can switch them on and off dynamically at any time. Sep 21 08:27:47 Even at runtime if you really wanted to. Sep 21 08:27:48 if i can convert those hex data converts to ascii, that will be better Sep 21 08:28:02 nice! Sep 21 08:28:54 You need a bit more magic than that. The strings are actually in different locations. Sep 21 08:29:39 i see Sep 21 08:29:58 yes, string should be in data section Sep 21 08:30:50 one comments, we could turn it off in release version to reduce code size Sep 21 08:31:00 add some #ifdef Sep 21 08:34:55 If we really wanted to, we could. Sep 21 08:35:16 I just never bothered since in the end it is more useful to have it than to remove it. Sep 21 08:41:28 understand, thanks Sep 21 17:14:22 denkenz: any idea how to support phone numbers longer than 20 digits? Sep 21 17:51:58 pessi: we can tweak the number size define Sep 21 17:52:17 However, for practical purposes you also need EFext support Sep 21 18:31:40 bump OFONO_MAX_PHONE_NUMBER_LENGTH to 80? Sep 21 18:43:06 pessi: Just doing that is not enough Sep 21 18:43:29 pessi: Too much logic assumes it is a max of 20, you need to actually go through and do this properly Sep 22 00:20:45 static const char *stke_prefix[] = { "%STKE:", NULL }; Sep 22 00:20:52 Inside drivers/mbmmodem/stk.c Sep 22 00:20:59 Is the %STKE a bug and should be actuall *STKE ? Sep 22 00:34:16 andrew would know Sep 22 00:34:20 I assume its no typo Sep 22 00:39:59 balrog-k1n: ping Sep 22 00:40:24 balrog-k1n: Is %STKE a typo for MBM or is it really like this. If so, please put a comment in the code. Sep 22 00:42:59 is OFFLINE mode same as airplane mode where modem is active, but not supposed to be registered? Sep 22 01:46:08 altroute: yes Sep 22 02:08:39 holtmann: it's a typo, good catch Sep 22 02:08:55 balrog-k1n: Please send a patch for it. Sep 22 02:09:00 ok Sep 22 02:19:27 Have fun with the new Message API, it still needs to handle status reports / expiration Sep 22 02:19:30 Comments welcome Sep 22 02:34:23 Should SendMessage not return a message object now? Sep 22 02:35:20 it should, forgot to change the api Sep 22 02:36:28 I also fixed a typo where you used call instead of message ;) Sep 22 02:37:57 Yeah, was boilerplate towards the end Sep 22 02:38:54 ok fixed Sep 22 02:40:12 So I think just cancel and maybe resent operations are needed. Sep 22 02:41:35 Resend is a bit tricky Sep 22 02:41:58 Something like try again in case of network failures etc. Sep 22 02:42:09 We already do back-off retries Sep 22 02:42:19 So Resend is actually not necessary Sep 22 02:42:30 How many? Sep 22 02:42:45 Are we sure we wanna not give the user to try some time later. Or is that up to the UI. Sep 22 02:43:14 I'm not against Resend per se, but the problem is we need to make the UI dismiss the objects it is no longer interested in Sep 22 02:43:30 Which honestly is too complicated Sep 22 02:43:39 I'd rather have the UI do resends Sep 22 02:43:54 And we perform 3 retries, with an increasing timeout between Sep 22 02:44:28 Okay. Leave it like that for now, but you do have to document that in the API description. Sep 22 02:44:45 Document what? Retries? Sep 22 02:45:31 Yes, that SendMessage retries. And that it is up to the UI to resend if that fails. Sep 22 02:47:59 fair enough, didn't really think documenting retries was needed Sep 22 02:54:44 Just so that our UI guys know what is going on. **** ENDING LOGGING AT Wed Sep 22 02:59:57 2010