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>
_______________________________________________
Users mailing list
[email protected]
http://lists.mbuni.org/mailman/listinfo/users
