Thanks paul for help :) Regards, Hafez
On Wed, Oct 22, 2008 at 2:08 PM, P. A. Bagyenda <[EMAIL PROTECTED]>wrote: > Thanks for the full log. > Now I'm usually polite about other people's software, but really your MMSC > provider is peddling untruths about the conformance of their implementation. > (Because I assume they've told you the problem is not on their side.) > > Basically their HTTP response is in the MM7/SOAP transaction is broken. > Evidence: > ---- > 2008-10-22 11:52:13 [1169] [16] DEBUG: Octet string dump ends. > 2008-10-22 11:52:23 [1169] [16] DEBUG: HTTP: Status line: <HTTP/1.1 200 OK> > 2008-10-22 11:52:23 [1169] [16] DEBUG: HTTP: Received response: > 2008-10-22 11:52:23 [1169] [16] DEBUG: Octet string at 0x8164b50: > 2008-10-22 11:52:23 [1169] [16] DEBUG: len: 918 > 2008-10-22 11:52:23 [1169] [16] DEBUG: size: 1024 > 2008-10-22 11:52:23 [1169] [16] DEBUG: immutable: 0 > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 44 61 74 65 3a 20 57 65 64 > 2c 20 32 32 20 4f 63 Date: Wed, 22 Oc > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 74 20 32 30 30 38 20 30 38 > 3a 33 32 3a 32 30 20 t 2008 08:32:20 > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 47 4d 54 0d 0a 53 65 72 76 > 65 72 3a 20 41 70 61 GMT..Server: Apa > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 63 68 65 2f 31 2e 33 2e 32 > 32 20 28 55 6e 69 78 che/1.3.22 (Unix > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 29 20 20 28 52 65 64 2d 48 > 61 74 2f 4c 69 6e 75 ) (Red-Hat/Linu > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 78 29 20 6d 6f 64 5f 66 61 > 73 74 63 67 69 2f 32 x) mod_fastcgi/2 > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 2e 32 2e 31 32 20 6d 6f 64 > 5f 70 79 74 68 6f 6e .2.12 mod_python > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 2f 32 2e 37 2e 38 20 50 79 > 74 68 6f 6e 2f 31 2e /2.7.8 Python/1. > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 35 2e 32 20 6d 6f 64 5f 73 > 73 6c 2f 32 2e 38 2e 5.2 mod_ssl/2.8. > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 35 20 4f 70 65 6e 53 53 4c > 2f 30 2e 39 2e 36 62 5 OpenSSL/0.9.6b > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 20 44 41 56 2f 31 2e 30 2e > 32 20 50 48 50 2f 34 DAV/1.0.2 PHP/4 > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 2e 32 2e 31 20 6d 6f 64 5f > 70 65 72 6c 2f 31 2e .2.1 mod_perl/1. > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 32 36 20 6d 6f 64 5f 74 68 > 72 6f 74 74 6c 65 2f 26 mod_throttle/ > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 33 2e 31 2e 32 0d 0a 43 6f > 6e 6e 65 63 74 69 6f 3.1.2..Connectio > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 6e 3a 20 63 6c 6f 73 65 0d > 0a 54 72 61 6e 73 66 n: close..Transf > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 65 72 2d 45 6e 63 6f 64 69 > 6e 67 3a 20 63 68 75 er-Encoding: chu > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 6e 6b 65 64 0d 0a 43 6f 6e > 74 65 6e 74 2d 54 79 nked..Content-Ty > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 70 65 3a 20 74 65 78 74 2f > 78 6d 6c 0d 0a 0d 0a pe: text/xml.... > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 43 6f 6e 74 65 6e 74 2d 4c > 65 6e 67 74 68 3a 20 Content-Length: > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 35 38 33 0d 0a 43 6f 6e 74 > 65 6e 74 2d 54 79 70 583..Content-Typ > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 65 3a 20 74 65 78 74 2f 78 > 6d 6c 0d 0a 0d 0a 3c e: text/xml....< > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 3f 78 6d 6c 20 76 65 72 73 > 69 6f 6e 3d 22 31 2e ?xml version="1. > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 30 22 20 65 6e 63 6f 64 69 > 6e 67 3d 22 55 54 46 0" encoding="UTF > 2008-10-22 11:52:23 [1169] [16] DEBUG: data: 2d 38 22 3f 3e 3c 65 6e 76 > 3a 45 6e 76 65 6c 6f -8"?><env:Envelo > ---- > > The Content-Type header appears twice, first time it is followed by two > CRLF, which should ordinarily mark the end of the HTTP headers. Mbuni is > doing the right thing. Their software isn't. > > P. > > On Oct 22, 2008, at 12:09, hafez ahmad wrote: > > Thanks Paul, you are always helpful , please find the attached full log. > > Regards, > Hafez > > On Wed, Oct 22, 2008 at 10:40 AM, P. A. Bagyenda <[EMAIL PROTECTED]>wrote: > >> Set maximum-send-attempts to 1. Should do the trick, but is obviously a >> kludge. Suggest you send full log so that we can try and make better sense >> of this error. >> >> On Oct 22, 2008, at 10:32, hafez ahmad wrote: >> >> Dears, >> >> I found the related error, like Paul says it is the XML response: >> >> *<?xml version="1.0" encoding="UTF-8"?><env:Envelope xmlns:env=" >> http://schemas.xmlsoap.org/soap/envelope/";><env:Header><TransactionID >> xmlns=" >> http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0"; >> env:mustUnderstand="1">[EMAIL >> PROTECTED]</TransactionID></env:Header><env:Body><SubmitRsp >> xmlns=" >> http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 >> "><MM7Version>5.3.0</MM7Version><MessageID>0000000018101075</MessageID><Status><StatusCode>1000</StatusCode><StatusText>Success</StatusText></Status></SubmitRsp></env:Body></env:Envelope>! >> Entity: line 1: parser error : Start tag expected, '<' not found >> Content-Length: 581 >> ^ * >> >> can you please tell me where is the error here? >> I call my operator and tell him to fix the response XML and he refuse he >> says that the users get the MMS successfully, is there any way so Mbuni >> ignore the error and stop trying to send the MMS again? >> >> Regards, >> Hafez >> >> >> On Thu, Oct 16, 2008 at 5:30 PM, P. A. Bagyenda <[EMAIL PROTECTED]>wrote: >> >>> Sorry I misunderstood your error message. The problem is Mbuni does not >>> understand the response. To understand why I'd need to look at a fuller >>> log. >>> Paul. >>> >>> On Oct 15, 2008, at 01:42, hafez ahmad wrote: >>> >>> Hi P.A, >>> >>> can you please explain more, Please find the attached conf file. >>> >>> Regards, >>> Hafez >>> >>> On Tue, Oct 14, 2008 at 4:19 PM, P. A. Bagyenda <[EMAIL PROTECTED]>wrote: >>> >>>> There is clearly a problem with your MMSC URL format, not with the MM7 >>>> packet format - this error shouldn't occur. So you will need to share your >>>> *actual* conf with a trusted party for further help :) >>>> P. >>>> >>>> On Oct 13, 2008, at 18:11, hafez ahmad wrote: >>>> >>>> *Dears List, >>>> >>>> *I trying to send MMS, the user received the MMS successfully*, *but I >>>> have the following error*: >>>> >>>> 2008-10-13 17:35:54 [26658] [9] INFO: Retry later MMSBox Outgoing Queue >>>> MMS Send: From [EMAIL PROTECTED], to 967711593356/TYPE=PLMN, msgsize=25269: >>>> msgid=[(null)], err=Failed to parse MMSC[url= >>>> http://username:[EMAIL PROTECTED]:80/mm7tomms.sh, id=HouseID] >>>> response! >>>> >>>> and I catch the following XMl Response , >>>> >>>> <?xml version="1.0" encoding="UTF-8"?> >>>> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/";> >>>> <env:Header> >>>> <TransactionID xmlns=" >>>> http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0"; >>>> env:mustUnderstand="1">[EMAIL PROTECTED]</TransactionID> >>>> </env:Header> >>>> <env:Body> >>>> <SubmitRsp xmlns=" >>>> http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 >>>> "> >>>> <MM7Version>5.3.0</MM7Version> >>>> <MessageID>0000000017784199</MessageID> >>>> <Status> >>>> <StatusCode>1000</StatusCode> >>>> <StatusText>Success</StatusText> >>>> </Status> >>>> </SubmitRsp> >>>> </env:Body> >>>> </env:Envelope>* >>>> >>>> >>>> The problem that the mbuni think that the MMS faild and still trying >>>> send the MMS again and again, >>>> >>>> Please advice. >>>> >>>> Regards, >>>> Hafez >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> [email protected] >>>> http://lists.mbuni.org/mailman/listinfo/users >>>> >>>> >>>> >>> >>> >>> -- >>> Hafez A.Ahmad >>> Amman-Jordan >>> mobile:962-785259011 >>> 962-795708728 >>> http://blog.hafezadnan.com >>> <mbuni.conf> >>> >>> >>> >> >> >> -- >> Hafez A.Ahmad >> Amman-Jordan >> mobile:962-785259011 >> 962-795708728 >> http://blog.hafezadnan.com >> >> >> > > > -- > Hafez A.Ahmad > Amman-Jordan > mobile:962-785259011 > 962-795708728 > http://blog.hafezadnan.com > <mmsgw.log> > > > -- Hafez A.Ahmad Amman-Jordan mobile:962-785259011 962-795708728 http://blog.hafezadnan.com
_______________________________________________ Users mailing list [email protected] http://lists.mbuni.org/mailman/listinfo/users
