Re: [Users] No Service to handle message when accepted-mmscs or denied-mmscs specified

Mon, 05 May 2008 04:12:59 -0700

The validation problem is due to not setting the XMLNS to the value expected by the MMSC at the other end. There is a new option for setting that in the config (see doc in CVS).
On the routing issue, you really have to be careful how you use the accepted-mmsc/denied-mmsc and allowed-prefix/denied-prefix settings. Again, see the doc in CVS for more information. If you feel the implementation/behaviour does not conform to the documentation, pray let us know (of course quoting chapter and verse). 

P.


On May 05, 2008, at 13:58, Marco Lopes wrote:


Apart from the original problem of being unable to route the  
messages to the right services, I noticed other totally unrelated  
but odd thing I think I should report.



In the version cvs-20080326 I was unable to send messages due to a  
validation problem. I searched the mailling list and I found that  
this was a known problem that had been fixed April 2007 (thread: http://lists.mbuni.org/pipermail/users/2007-April/000030.html 
 ) The version cvs-20070508 I was using first don't have this  
problem, thus confirming the bug was fixed, but it seems to have  
returned and is now present on version cvs-20080326.



Meanwhile, as the cvs-20080326 didn't solve the original routing  
problem that would allow me to receive MMS, I got back to the  
cvs-20070508 where I could at least send.


P. A. Bagyenda wrote:

send me the config and the log file. This should work!
On Apr 16, 2008, at 12:10, Marco Lopes wrote:

Yes, currently, for testing purposes I'm using only one mmsc  
configuration, to make sure no conflicts arise, and one mmsc- 
service configuration, the service configuration has catch-all set  
to true.


P. A. Bagyenda wrote:

Yes the 'fromproxy' is the sender mmsc. The way you print it  
below would not work as it is not a char *.
This part should generally work without pain. I notice there is  
no keyword in this case. Do you have a catch-all service for when  
you have no keyword?

On Apr 14, 2008, at 14:29, Marco Lopes wrote:

Hi,


I've been browsing through the source code and I found something  
that

may help find out what's going on.

The function get_service receives an Octsring as second  
paramenter, this
parameter is called mmc_id inside the functions and is compared  
to the

list of allowed_mmscs and the list of denied_mmscs using the
gwlist_search function.

The call to this functions sends as mmc_id the variable e- 
>fromproxy

being e a structure which represents the envelope.

Is this what is supposed to happen, is the fromproxy and the  
mmsc id the

same thing?


I used the same function which is used to log the errors to log  
the

e->fromproxy value with even stranger results.
The code used was

error(0, "MYDEBUG: %s",octstr_get_cstr(octstr_format("temp: %s\n",
e->fromproxy)));

The output:

2008-04-07 09:43:39 [26582] [7] ERROR: MYDEBUG: temp: (^[^X^H


Would this help in any way?

Marco Lopes wrote:

Hi,

I've try to send a mail with the log of the full processing of  
an MMS but the mail didn't reach the ML due to the size of the  
text atachment (500K) so I'll send only the last few lines of  
the log to see if it helps. I'm using version

cvs-20080326.

2008-03-27 17:35:54 [24566] [3] DEBUG: HTTP: Destroying  
HTTPClient area 0x8163010.
2008-03-27 17:35:54 [24566] [3] DEBUG: HTTP: Destroying  
HTTPClient for `194.65.126.96'.
2008-03-27 17:35:54 [24566] [3] DEBUG:  --> leaving mm7dispatch  
interface, mresp=[ok], body=[ok], mm7_status=[1000] <--
2008-03-27 17:35:54 [24566] [3] DEBUG:  entered free_clientinfo  
0, ip=[135671016]

2008-03-27 17:35:54 [24566] [3] DEBUG:  left free_clientinfo

2008-03-27 17:35:54 [24566] [0] WARNING: mms_queueread: Mal- 
formed address [351967111284] in file ./mmsbox_incoming/p/ 
qf9353.1.x566.38! Attempting fixup.
2008-03-27 17:35:54 [24566] [0] DEBUG: Queued to thread 0 for ./ 
mmsbox_incoming/p/qf9353.1.x566.38, sendt=1206639353,  
tnow=1206639354
2008-03-27 17:35:54 [24566] [6] WARNING: Faulty address  
[351967111284] format in field From!

2008-03-27 17:35:54 [24566] [6] DEBUG: WSP: decoding headers:
2008-03-27 17:35:54 [24566] [6] DEBUG: Octet string at 0x817e2d8:
2008-03-27 17:35:54 [24566] [6] DEBUG:   len:  51
2008-03-27 17:35:54 [24566] [6] DEBUG:   size: 52
2008-03-27 17:35:54 [24566] [6] DEBUG:   immutable: 0

2008-03-27 17:35:54 [24566] [6] DEBUG:   data: 19 61 70 70 6c  
69 63 61 74 69 6f 6e 2f 73 6d 69   .application/smi
2008-03-27 17:35:54 [24566] [6] DEBUG:   data: 6c 00 81 ea 85  
41 41 41 41 00 c0 3c 41 41 41 41   l....AAAA..<AAAA
2008-03-27 17:35:54 [24566] [6] DEBUG:   data: 3e 00 4d 49 4d  
45 2d 56 65 72 73 69 6f 6e 00 31   >.MIME-Version.1
2008-03-27 17:35:54 [24566] [6] DEBUG:   data: 2e 30  
00                          .0.

2008-03-27 17:35:54 [24566] [6] DEBUG: Octet string dump ends.
2008-03-27 17:35:54 [24566] [6] DEBUG: WSP: decoded headers:

2008-03-27 17:35:54 [24566] [6] DEBUG: Content-Type:  
application/smil; charset=utf-8; name="AAAA"

2008-03-27 17:35:54 [24566] [6] DEBUG: Content-ID: <AAAA>
2008-03-27 17:35:54 [24566] [6] DEBUG: MIME-Version: 1.0

2008-03-27 17:35:54 [24566] [6] DEBUG: WSP: End of decoded  
headers.

2008-03-27 17:35:54 [24566] [6] DEBUG: WSP: decoding headers:
2008-03-27 17:35:54 [24566] [6] DEBUG: Octet string at 0x817ef30:
2008-03-27 17:35:54 [24566] [6] DEBUG:   len:  48
2008-03-27 17:35:54 [24566] [6] DEBUG:   size: 49
2008-03-27 17:35:54 [24566] [6] DEBUG:   immutable: 0

2008-03-27 17:35:54 [24566] [6] DEBUG:   data: 0a 9e 85 43 61  
74 2e 6a 70 67 00 c0 3c 43 61 74   ...Cat.jpg..<Cat
2008-03-27 17:35:54 [24566] [6] DEBUG:   data: 2e 6a 70 67 3e  
00 8e 43 61 74 2e 6a 70 67 00 4d   .jpg>..Cat.jpg.M
2008-03-27 17:35:54 [24566] [6] DEBUG:   data: 49 4d 45 2d 56  
65 72 73 69 6f 6e 00 31 2e 30 00   IME-Version.1.0.

2008-03-27 17:35:54 [24566] [6] DEBUG: Octet string dump ends.
2008-03-27 17:35:54 [24566] [6] DEBUG: WSP: decoded headers:

2008-03-27 17:35:54 [24566] [6] DEBUG: Content-Type: image/ 
jpeg; name="Cat.jpg"

2008-03-27 17:35:54 [24566] [6] DEBUG: Content-ID: <Cat.jpg>
2008-03-27 17:35:54 [24566] [6] DEBUG: Content-Location: Cat.jpg
2008-03-27 17:35:54 [24566] [6] DEBUG: MIME-Version: 1.0

2008-03-27 17:35:54 [24566] [6] DEBUG: WSP: End of decoded  
headers.

2008-03-27 17:35:54 [24566] [6] DEBUG: WSP: decoding headers:
2008-03-27 17:35:54 [24566] [6] DEBUG: Octet string at 0x81644b0:
2008-03-27 17:35:54 [24566] [6] DEBUG:   len:  50
2008-03-27 17:35:54 [24566] [6] DEBUG:   size: 51
2008-03-27 17:35:54 [24566] [6] DEBUG:   immutable: 0

2008-03-27 17:35:54 [24566] [6] DEBUG:   data: 0c 83 81 ea 85  
41 72 32 2e 74 78 74 00 c0 3c 41   .....Ar2.txt..<A
2008-03-27 17:35:54 [24566] [6] DEBUG:   data: 72 32 2e 74 78  
74 3e 00 8e 41 72 32 2e 74 78 74   r2.txt>..Ar2.txt
2008-03-27 17:35:54 [24566] [6] DEBUG:   data: 00 4d 49 4d 45  
2d 56 65 72 73 69 6f 6e 00 31 2e   .MIME-Version.1.
2008-03-27 17:35:54 [24566] [6] DEBUG:   data: 30  
00                          0.

2008-03-27 17:35:54 [24566] [6] DEBUG: Octet string dump ends.
2008-03-27 17:35:54 [24566] [6] DEBUG: WSP: decoded headers:

2008-03-27 17:35:54 [24566] [6] DEBUG: Content-Type: text/ 
plain; charset=utf-8; name="Ar2.txt"

2008-03-27 17:35:54 [24566] [6] DEBUG: Content-ID: <Ar2.txt>
2008-03-27 17:35:54 [24566] [6] DEBUG: Content-Location: Ar2.txt
2008-03-27 17:35:54 [24566] [6] DEBUG: MIME-Version: 1.0

2008-03-27 17:35:54 [24566] [6] DEBUG: WSP: End of decoded  
headers.
2008-03-27 17:35:54 [24566] [6] ERROR: MMSBox error: No Service  
to handle Mbuni-p-qf9353.1.x566.38 (keyword )!

Paul Bagyenda wrote:

Oops yes, you are right. Would you provide a log? That might  
help. From what I can see, this should work fine.



On Thu, Mar 27, 2008 at 8:14 PM, Marco Lopes <[EMAIL PROTECTED] 
 <mailto:[EMAIL PROTECTED]>> wrote:


 Thanks for your response,


 I already have the catch-all = true set. I tried now with a  
keyword (I
 used default as you sugested) but it still give the No  
Service to handle

 message error.

 Paul Bagyenda wrote:

  > You need to add a catch-all = true to the first mms- 
service as

 well, to

  > ensure it catches all messages from that mmsc, even when  
the keyword
  > does not match. Then you can set the keyword to anything  
(say

 "default")
  >
  > On Thu, Mar 27, 2008 at 7:54 PM, Marco Lopes
 <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
  > <mailto:[EMAIL PROTECTED]
 <mailto:[EMAIL PROTECTED]>>> wrote:
  >
  >     Hi,
  >
  >     I have the following configuration in my mbuni.conf
 (sensitive data
  >     changed) file:
  >
  >     group = mmsc
  >     id = geue923pos
  >     group-id = geue923pos
  >     mmsc-url = http://thirdpartyserver.example.com/
  >     incoming-port = 9696
  >     type = soap
  >
  >
  >     group = mms-service
  >     name = operator1
  >     keyword =
  >     accepted-mmscs = geue923pos
  >
  >     post-url = http://ourserver.example.com/
  >     catch-all = true
  >     http-post-parameters =
  >     image=%i&text=%t&video=%v&smil=%s&audio=%a&other=%o
  >     suppress-reply = true
  >     accept-x-mbuni-headers = true
  >
  >

  >     If I remove the accepted-mmscs the message is routed  
trough this
  >     mms-service otherwise I get a No Service to handle  
message error.

  >

  >     I need to use this to route messages coming from 3  
different

 mmscs to

  >     different services regardless of the keyword, but as  
I've not

 been able

  >     to route the messages I'm only using one mmsc and one  
service

 yet.
  >
  >     Am I doing something wrong, can someone tell me why the
 message isn't

  >     routed to the service if I specify an accepted-mmsc  
value?

  >
  >     Thanks,
  >     Marco Lopes
  >     _______________________________________________
  >     Users mailing list
  >     [email protected] <mailto:[email protected]>
 <mailto:[email protected] <mailto:[email protected]>>
  >     http://lists.mbuni.org/mailman/listinfo/users
  >
  >
 _______________________________________________
 Users mailing list
 [email protected] <mailto:[email protected]>
 http://lists.mbuni.org/mailman/listinfo/users



_______________________________________________
Users mailing list
[email protected]
http://lists.mbuni.org/mailman/listinfo/users


_______________________________________________
Users mailing list
[email protected]
http://lists.mbuni.org/mailman/listinfo/users

_______________________________________________
Users mailing list
[email protected]
http://lists.mbuni.org/mailman/listinfo/users


_______________________________________________
Users mailing list
[email protected]
http://lists.mbuni.org/mailman/listinfo/users






















					Reply via email to