Like I said: This part has worked since the beginning, so the problem is not in Mbuni. Some phones are a little picky about notifications: I see that the sender in your case is an IP address. This can cause problems. Also try the Mbuni optimize-notification flag (set to true) and see if your mileage improves On Nov 19, 2009, at 12:15, Nikos Balkanas wrote:
> Sure. Here are my log excerpts: > > ****** mbuni.log ***** > > 2009-11-18 21:01:51 [17508] [8] INFO: Preparing to notify client to fetch > message at URL: http://localhost/n-qf605.1.x508...@2/wx96 > Note: I don't have DNS setup yet, so I am not trying to retrieve the MMS. I > am only concerned about the failed notification part: > > 2009-11-18 21:01:51 [17508] [8] DEBUG: Sending notification: "2009-11-18 > 21:01:51 [17508] [8] INFO: mms2mobile.startpush: notification to 306979230022 > > 2009-11-18 21:01:51 [17508] [8] INFO: Sent Mobile Queue MMS Send Notify: > From=94.143.177.172/TYPE=IPv4, to=306979230022/TYPE=PLMN, msgsize=853, reason= > 2009-11-18 21:01:51 [17508] [15] DEBUG: Queue contains 0 pending requests. > 2009-11-18 21:01:51 [17508] [15] DEBUG: Parsing URL > `http://localhost:15010/cgi-bin/sendsms?dlr-mask=63&_dummy=x&username=xxxx&password=xxxxx&text=%03%06%03%BE%AF%84%8C%82%98localhost-n-qf605.1.x508.91%00%8D%90%89%1A%8094.143.177.172%2FTYPE%3DIPv4%00%96%7F%CE%B3%00%8A%80%8E%02%03U%88%05%81%03%05%7D%0A%83http%3A%2F%2Flocalhost%2Fn-qf605.1.x508.91%402%2Fwx96%00&to=306979230022&udh=%06%05%04%0B%84%23%F0': > > ***** bearerbox access log ********* > > 2009-11-18 21:01:51 Sent SMS [SMSC:smpp_cla] [SVC:simple] [ACT:] [BINF:] > [FID:12508ac13715d9e4e043a66456a47adf] [META:] [from:AMD] [to:306979230022] > [flags:-1:1:-1:-1:63] > [msg:128:030603BEAF848C82986C6F63616C686F73742D6E2D71663630352E312E783530382E3931008D90891A8039342E3134332E3137372E3137322F545950453D4950763400967FCEB3008A808E02035588058103057D0A83687474703A2F2F6C6F63616C686F73742F6E2D71663630352E312E783530382E393140322F7778393600] > [udh:7:0605040B8423F0] > 2009-11-18 21:01:51 Receive DLR [SMSC:smpp_cla] [SVC:simple] [ACT:] [BINF:] > [FID:12508ac13715d9e4e043a66456a47adf] [META:] [from:AMD] [to:306979230022] > [flags:-1:-1:-1:-1:8] [msg:4:ACK/] [udh:0:] > 2009-11-18 21:01:58 Receive DLR [SMSC:smpp_cla] [SVC:simple] [ACT:AMD2_gw140] > [BINF:] [FID:12508abffe25d9e4e043a66456a47967] [META:?smpp?dlr_err=000&] > [from:AMD] [to:306979230022] [flags:-1:-1:-1:-1:1] > [msg:144:id:12508abffe25d9e4e043a66456a47967 sub:001 dlvrd:001 submit > date:0911182001 done date:0911182002 stat:DELIVRD err:000 text: > ] [udh:0:] > Notification never shows in my mobile. I ran a test with wapbox and the ppg > came fine in the same phone (same DLRs). So it is not a phone problem. From > the ppg: > > 2009-11-18 20:33:48 Sent SMS [SMSC:smpp_cla] [SVC:ppg] [ACT:] [BINF:] [FID:] > [META:] [from:Nikos] [to:+306979230022] [flags:-1:1:-1:-1:0] > [msg:117:00060DAEA9677720312E35008DE5C39302056A0045C60D0374726176656C3263616E616461008503706963732F686964652F646565722E6A70670011033140776972616C2E636F6D00080AC3072009103010231510C3042010123001034578616D706C65205050472028616B61204D4D5329000101] > [udh:7:0605040B8423F0] > UDH is the same in both cases. Text, of course, is different. >From my > experience a lot of mobiles won't display ppg if they receive corrupted > wbxml. There is a difference in the dlr-mask, but it is not important. > mbuni's notification is not received whether dlr-mask is set to 0 or 63. > > BTW: Why the _dummy=x variable that mbuni inserts in the URL? > > Thanx, > Nikos > ----- Original Message ----- > From: Paul Bagyenda > To: users@mbuni.org > Sent: Thursday, November 19, 2009 5:35 AM > Subject: Re: [Users] MMS Sending Problem > > This part of Mbuni has worked for the last six years, so it is unlikely that > there is a bug. What is the URL from the logs? > On Nov 18, 2009, at 22:37, Nikos Balkanas wrote: > >> I dunno. It seems to be an mmsrelay problem. I am in the middle of something >> similar now, seems that mbuni (mmsrelay) might be generating bad wbxml. In >> my phone I never see the notification, despite receiving it (verified by >> DLR). Tomorrow i will look more into it. >> >> BR, >> Nikos >> >> [...snip...]
_______________________________________________ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users