**** BEGIN LOGGING AT Fri Jul 22 02:59:57 2011
Jul 22 14:32:44 <vmlemon_> Hi
Jul 22 14:36:12 <vmlemon_> Out of interest, is anyone here working on the SIM/ISO 7816 Wireshark dissector?
Jul 22 14:42:44 <denkenz> nope
Jul 22 14:43:27 <vmlemon_> Oops, wrong channel
Jul 22 14:43:29 <vmlemon_> Sorry
Jul 22 14:44:09 <fdanis> denkenz: I do oFono HFP AG vs HFP HF test, this is really great :)
Jul 22 14:44:09 <fdanis> but when in phonesim I change network registration to roaming I got a crash in set_network_operator_name() of src/network.c, which is indirectly called by cops_cb() of hfpmodem/network-registration.c
Jul 22 14:44:17 <fdanis> it seems that opd->netreg was not filled (still NULL), but I do not know if it should be filled and who should do it
Jul 22 14:46:11 <denkenz> fdanis: line #?
Jul 22 14:46:36 <fdanis> 446
Jul 22 14:47:31 <fdanis> set_network_operator_name() at /home/fdanis/src/ofono/src/network.c:446
Jul 22 14:47:31 <fdanis> current_operator_callback() at /home/fdanis/src/ofono/src/network.c:1 248
Jul 22 14:47:31 <fdanis> cops_cb() at /home/fdanis/src/ofono/drivers/hfpmodem/network-registration.c:96
Jul 22 14:47:31 <fdanis> ...
Jul 22 14:50:44 <denkenz> So hfp netreg is a bit of a hack, what we do is that we report mcc and mnc as empty strings
Jul 22 14:51:11 <denkenz> so the logic probably doesn't work for this case
Jul 22 14:52:39 <denkenz> Probably need to return earlier from that function
Jul 22 14:59:57 <fdanis> adding return in case of netreg==NULL at line 445 should be ok ?
Jul 22 15:02:01 <denkenz> I don't think so, we do need to emit the new name
Jul 22 15:05:09 <denkenz> -               }
Jul 22 15:05:10 <denkenz> +               } else
Jul 22 15:05:10 <denkenz> +                       opd->netreg = netreg;
Jul 22 15:05:39 <denkenz> try this patch in current_operator_callback, line 1266
Jul 22 15:06:34 <fdanis> ok
Jul 22 15:12:18 <fdanis> no more crash
Jul 22 15:16:57 <denkenz> cool
Jul 22 15:19:41 <denkenz> Please test some more, I expect we still have some bugs hiding
Jul 22 15:20:06 <denkenz> Especially since hfp_client code has not been touched in a while and probably might have some bit rot here and there
Jul 22 15:21:52 <fdanis> currently, I do not found other crash, the only other bug I found is related to callswap and intermediate callheld=2
Jul 22 15:22:22 <denkenz> nod, I figured that one
Jul 22 15:23:06 <fdanis> is it normal that after calling DBus method CreateMultiparty emulator continuously receives AT+CLCC ?
Jul 22 15:24:09 <denkenz> yes, the reason being that we don't know when one of the parties drops
Jul 22 15:24:17 <fdanis> ok
Jul 22 15:24:33 <denkenz> unless you find some clever way of handling that case
Jul 22 15:26:19 <fdanis> that is what I thought
Jul 22 15:26:19 <fdanis> do you want I send a patch for current_operator_callback(), or you do it ?
Jul 22 15:28:05 <denkenz> fix pushed
Jul 22 15:28:19 <fdanis> ok, thanks
Jul 22 15:30:45 <denkenz> once you're comfortable that hfp emulator is working nicely go ahead and submit a patch marking the task done on the TODO list
Jul 22 15:31:10 <denkenz> Put in a new task for vgm/vgs integration with bluez/pulse audio
Jul 22 16:40:43 <fdanis> denkenz: holtmann: I thought that the next step will be to move bluetooth part to BlueZ, in the same way than for hfp_hf
Jul 22 16:41:09 <denkenz> it is
Jul 22 16:42:02 <fdanis> so, we will need a new tasks in both oFono and Bluez
Jul 22 16:42:45 <denkenz> yep, closing big tasks and opening small tasks was always the intent
Jul 22 16:43:30 <fdanis> ok
Jul 22 16:51:11 <denkenz> fdanis: I don't think that callheld fix is right, what happens if the active call is dropped by remote ?
Jul 22 16:53:22 <fdanis> good question, here is the trace I got:
Jul 22 16:53:22 <fdanis> ofonod[3212]: Server: < AT+CHLD=2\r
Jul 22 16:53:22 <fdanis> ofonod[3212]: Server: > \r\nOK\r\n
Jul 22 16:53:22 <fdanis> ofonod[3212]: src/voicecall.c:ofono_voicecall_notify() Got a voicecall event, status: 0, id: 1, number: 123 called_number: , called_name 
Jul 22 16:53:22 <fdanis> ofonod[3212]: src/voicecall.c:ofono_voicecall_notify() Found call with id: 1
Jul 22 16:53:22 <fdanis> ofonod[3212]: src/voicecall.c:ofono_voicecall_notify() Got a voicecall event, status: 1, id: 2, number: 456 called_number: , called_name 
Jul 22 16:53:23 <fdanis> ofonod[3212]: src/voicecall.c:ofono_voicecall_notify() Found call with id: 2
Jul 22 16:53:23 <fdanis> ofonod[3212]: Server: > \r\n+CIEV: 4,2\r\n\r\n+CIEV: 4,1\r\n
Jul 22 16:53:24 <fdanis> ofonod[3212]: src/voicecall.c:ofono_voicecall_disconnected() Got disconnection event for id: 2, reason: 2
Jul 22 16:53:24 <fdanis> ofonod[3212]: Call Ended on modem: 0x893b768
Jul 22 16:53:25 <fdanis> ofonod[3212]: Voice Call, Incoming
Jul 22 16:53:25 <fdanis> ofonod[3212]: From: 456
Jul 22 16:53:26 <fdanis> ofonod[3212]: StartTime: 2011-07-22T14:44:28+0200
Jul 22 16:53:26 <fdanis> ofonod[3212]: EndTime: 2011-07-22T14:44:59+0200
Jul 22 16:53:27 <fdanis> ofonod[3212]: Server: < AT+CLCC\r
Jul 22 16:53:27 <fdanis> ofonod[3212]: Server: > \r\n+CLCC: 1,1,0,0,0,"123",129\r\n+CLCC: 2,1,1,0,0,"456",129\r\n\r\nOK\r\n
Jul 22 16:54:53 <denkenz> so that's for a swap which is wrong
Jul 22 16:55:21 <fdanis> yes
Jul 22 16:55:51 <fdanis> but how can we know that this is related to a swap ?
Jul 22 16:56:01 <denkenz> we don't ;)
Jul 22 16:56:27 <denkenz> If you want to be semi smart you can schedule a CLCC x milliseconds in the future
Jul 22 16:56:35 <denkenz> and cancel the CLCC if a callheld=1 arrives in the meantime
Jul 22 16:57:05 <denkenz> however, callheld=2 can happen by itself in a three way call if the remote hangs up
Jul 22 16:57:30 <fdanis> in case of an active call dropped by remote, the last CLCC will only show one call, no ?
Jul 22 16:58:02 <denkenz> yep
Jul 22 16:58:57 <denkenz> Its safe to poll twice, just that you send a CLCC unnecessarily once in the case of a swap
Jul 22 16:59:48 <denkenz> The entire protocol is screwed up.  Considering voice calls are the killer app on GSM, 3GPP really truly dropped the ball on this one, and so did Bluetooth SIG
**** ENDING LOGGING AT Sat Jul 23 02:59:57 2011