MMS retrival with a simulator

MMS retrival with a simulator SearchSearch
Author Message
Xavier Berger
New member
Username: Xberger

Post Number: 2
Registered: 10-2006
Posted on Thursday, October 26, 2006 - 04:45 pm:   

Hi Bryce,

I will soon perform an integration of your solution for one of my customers. Before going in production I will have to test my configuration. I will not have handset to perform these tests. I would like to retrieve MMS using a simple GET (with linux wget for instance).

When I try to perform this test I always have MSISDN error.

Can you help me to fix the problem ?

---------------------------------

Here is my MMSC.ini

[MMSC]
WebPort=80
SMTPPort=25
RelayHost=
HostName=localhost
DomainName=
AdminUser=
AdminPassword=
SMTPRequireAuth=No
EnableDeliveryNotification=Yes
ConvertImages=Yes
ConvertEMailWAVAMR=Yes
ConvertEMailBMPJPG=Yes
ConvertScaleToScreen=Yes
SMSEMail=No
SMSDomainName=
SMSPerEMail=1
MSISDNHeader=msisdn
MSISDNHeaderAutoProvision=Yes
MSISDNHeaderDefaultCountryCode=33
MSISDNHeaderLocalPrefix=0

Debug=Yes

---------------------------------

Here is what I catch with ethereal of the frame I send with wget

GET /20061026/15/9F41F9B0.MMS HTTP/1.0
User-Agent: Wget/1.10.2
Accept: */*
Host: 10.10.10.147
Connection: Keep-Alive
msisdn: +33618710581
X-MSISDN: 0618710581

HTTP/1.0 404 Not Found
Content-Length: 0
Connection: close

---------------------------------

Here is a part of MMSCDEBUG.LOG

17:19:01:472 [9] ThreadProcessConnection: Processing connection from 10.10.10.71...
17:19:01:472 [9] ThreadProcessConnection: Packet Length is 168 bytes
17:19:01:472 [9] ThreadProcessConnection: 47 45 54 20 2F 32 30 30 36 31 30 32 36 2F 31 35 GET /20061026/15
17:19:01:472 [9] ThreadProcessConnection: 2F 39 46 34 31 46 39 42 30 2E 4D 4D 53 20 48 54 /9F41F9B0.MMS HT
17:19:01:472 [9] ThreadProcessConnection: 54 50 2F 31 2E 30 0D 0A 55 73 65 72 2D 41 67 65 TP/1.0 User-Age
17:19:01:472 [9] ThreadProcessConnection: 6E 74 3A 20 57 67 65 74 2F 31 2E 31 30 2E 32 0D nt: Wget/1.10.2
17:19:01:472 [9] ThreadProcessConnection: 0A 41 63 63 65 70 74 3A 20 2A 2F 2A 0D 0A 48 6F Accept: */* Ho
17:19:01:472 [9] ThreadProcessConnection: 73 74 3A 20 31 30 2E 31 30 2E 31 30 2E 31 34 37 st: 10.10.10.147
17:19:01:472 [9] ThreadProcessConnection: 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 4B 65 Connection: Ke
17:19:01:472 [9] ThreadProcessConnection: 65 70 2D 41 6C 69 76 65 0D 0A 6D 73 69 73 64 6E ep-Alive msisdn
17:19:01:472 [9] ThreadProcessConnection: 3A 20 2B 33 33 36 31 38 37 31 30 35 38 31 0D 0A : +33618710581
17:19:01:472 [9] ThreadProcessConnection: 58 2D 4D 53 49 53 44 4E 3A 20 30 36 31 38 37 31 X-MSISDN: 061871
17:19:01:472 [9] ThreadProcessConnection: 30 35 38 31 0D 0A 0D 0A 0581
17:19:01:472 [9] ThreadProcessConnection: C:\PROGRA~1\NowSMS\MMSCDATA\20061026/15/9F41F9B0.INI
17:19:01:472 [9] ThreadProcessConnection: MSISDN does not match message recipient
17:19:06:479 [9] ThreadProcessConnection: HTTP/1.0 404 Not Found
Content-Length: 0
Connection: close


17:19:06:479 [9] ThreadProcessConnection: Processing Complete
17:19:06:479 [9] InternalProcessConnection: Thread ended

---------------------------------

Here is the INI file where nowMMS look at the MSISDN:

[Message]
Sender=+33618710581
Subject=Read: E to E
DeliveryNotification=No
OriginalMessageID=20061026/15/9F41F9B0@localhost
[Recipient Status]
+33618710581=Pending
[Recipient MMS Version]
+33618710581=1.0
[NotifyPDU]
+33618710581=7506226170706C69636174696F6E2F766E642E7761702E6D6D732D6D65737361676 500AF848C82983946343146394230008D908918802B33333631383731303538312F545950453D504 C4D4E0096526561643A204520746F2045008A838E01E088058103093A8083687474703A2F2F6C6F6 3616C686F73742F32303036313032362F31352F39463431463942302E4D4D533F69643D253262333 336313837313035383100
[NotifyID]
+33618710581=117

---------------------------------

Thanks for your help,

Xavier
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 6772
Registered: 10-2002
Posted on Wednesday, November 01, 2006 - 06:43 pm:   

Hi Xavier,

The actual MMS notification that is sent out includes the recipient phone number in the URL.

So when the MMS retrieval request comes back, we expect to see the recipient phone number in the URL, not just the filename.

This is done to address the possibility of a malicious user "guessing" URLs to try to retrieve someone else's messages.

If you append "?id=phonenumber" to the URL request, where phonenumber is one of the recipients, then you will be ok. (Remember that "+" must be URL escaped, so it becomes %2B.)

You can also disable this check by adding MSISDNMatchRequiredForReceive=No under the [MMSC] header of MMSC.INI. (But aside from getting you past this test, I can't think of any good reasons to do this.)

While we're discussing this issue, it might be worth mentioning another related MMSC.INI parameter.

As discussed above, you will note that it is still technically possible to retrieve a message for which you are not the recipient if you know the notification URL (complete with recipient phone number). It is possible to configure the MMSC to also require the MSISDN (X-MSISDN) header of the recipient before allowing the message retrieval. This check is disabled by default, but can be enabled with the MMSC.INI, [MMSC] section setting: MSISDNHeaderRequiredForReceive=Yes.

-bn