2-way MMS application | Search |
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through February 20, 2004 ⬆ |
◄ ► |
Author | Message | |||
Matt Allie New member Username: Matt Post Number: 1 Registered: 02-2004 |
Hello, We are about to get a licence for both SMS/MMS Gataway and WAP gateway. I would like to have your inputs regarding a concern I have for our customer application: A Nokia PT-2 GPRS phone(acting as an observation camera) will sends VGA snaphots over MMS at regular interval and/or upon SMS requests. Those MMS should then be somehow retrieved on a central server for viewing/security purposes. So most of those MMS are actually not meant to be delivered to another MS (some may though). So I was hoping to use the 2-way MMS feature: each MMS received by any of the PT-2 observation camera phone would be processed at the MMSC which would parse the MMS content and copy the attachment (a jpeg VGA picture in our case) into a local directory. I think the MMS also has the capability now to sent the attachment to an email recipient via SMTP, so this could be used as well. But I think for the 2-way MMS feature to work, the MMS has to be received by a third party MMSC or via a SMS notification, i.e the nowSMS has to act as a gateway only, is that correct? In our application, the whole network is local and MMSC, WAP, SMSC are on the same LAN. nowSMS will act as a pure MMSC...can we still use the 2-way MMS feature? If not, do you see any alternative? Also the other concern it that all the MMS sent by the PT-2 will not be actually delivered/retrived by other MS, so it might lead to some congestion on the MMSC unless we can autonatically clean those MMS on a timer basis... Thanks a lot! Matthieu | |||
Matt Allie New member Username: Matt Post Number: 2 Registered: 02-2004 |
Also, I'm not too familiar with WAP gateway: I got your price list and there are 2 type of WAP gateways: WTLS and non-WTLS. Could you briefly tell me the difference and which one would be needed for my applicaion? (the cheapest would be the best... thanks! Matthieu | |||
Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1842 Registered: 10-2002 |
Matthieu, I'm glad you asked this question, because it lets me explain one of the more unusual aspects of the product. For situations like this, we allow an MM1 device (a standard MMS client) to connect as a VASP (Value Added Service Provider) instead of a standard user account. The idea behind this is that we allow more flexibility in the routing of messages that are submitted by a VASP. When you define a VASP on the "MMSC VASP" page of the NowSMS configuration, you can specify different routing options for messages that are received from that particular VASP account. The default setting is "Standard MMS Delivery", which means that the message is routed as if it had been sent in by a regular user account. But there are also other options ... "Receive to MMS-IN Directory" - In this case, the MMS message is parsed into text format, and individual components of the message are extracted into separate files. A ".hdr" file is written to the MMS-IN directory which contains a text version of the MMS header. This header file includes "X-NowMMS-Content-Location:" headers that point to the different file components that are included in the MMS message (text, images, etc.). These additional file components are stored in a subdirectory, and the location specified in the header is relative to the MMS-IN directory. The format of these ".hdr" files is consistent with the format used by the MMSCOMP utility. "Route via MM7" - MM7 is an XML/SOAP interface that is defined by the 3GPP as a format for applications to send/receive MMS messages. When this type of routing is defined for received MMS messages, NowSMS reformats the MMS message into MM7 format, and performs an HTTP POST of the content to the specified MM7 connection. You must first define an MM7 connection on the "MMSC Routing" page of the configuration dialog before you will be able to select this option for routing a received MMS message. "Forward to E-Mail Address" - The MMS message is converted into an e-mail message (with components of the MMS message converted to attachments) and sent to a specified e-mail address. (Note: This option requires that a valid "SMTP Relay Host" be configured on the "MMSC" page of the configuration dialog. NowSMS will connect to the SMTP server specified as this relay host in order to send the message.) So it's up to you how you want to process it. If you just want to receive it to a directory, then the file will remain there until it is deleted by some other application. The following thread has some detailed information on this format: http://support.nowsms.com/discus/messages/485/2135.html Oh ... I did leave out one important detail. If you want to have an MM1 client submit MMS messages via a VASP account instead of a standard URL account, configure the MMS client on the device to use an MMSC URL of http://server.ip.address:port/mm1/username=password (username and password are the account name and password for the account defined in the "MMSC VASP" dialog). Regarding WTLS, WTLS is an encryption layer that can be used in WAP communications. -bn | |||
Matt Allie New member Username: Matt Post Number: 3 Registered: 02-2004 |
Thanks for ur prompt and efficient reply! So, if I understand well, the PT-2 phone will send the MMS as a VASP. In which case, I would not even need to create a MMSC user for the MS, just a VASP account, right? Also, I dont need to configure or enable the 2-way SMS/MMS tab, right? What will happen to the actual MMS? Since again, the PT-2 phone will send MMS just for the purpose of being able to retrive the picture from a MMSC user defined directory: the actuall MS recipient does not matter. So I guess the MMSC will try to deliver the MMS via SMS notification and since no MS may ever retrieve it, it will finally be purged from the MMSC? Is that correct? How/where can we set this king or purge? Last, if a MMS user wants to send message to an SMTP recipeint, what should it send it to? To a specific nb that? where is the email address specified? In the text body of the MMS? Sorry for all those questions: ur support is really helpful. -Matthieu | |||
Matt Allie New member Username: Matt Post Number: 4 Registered: 02-2004 |
I think I just got the response from one of my question by reading more of ur online doc: if I select "Receive to MMS-IN Directory" in the VASP profile, then that's it: MMS content will be parsed in the dir. and not delivered at all to actuall MS recipient: so the recipient can be any "dummy" MISDN, correct? thanks again | |||
Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1873 Registered: 10-2002 |
Matthieu, Right, you define the account on the MMSC as a VASP instead of a user. And you have to configure the MMSC URL in the client slightly different for this (/mm1/username=password instead of just /username=password). And if you specify "Receive to MMS-IN Directory", then the recipient address is effectively ignored. It can be any dummy MSISDN or e-mail address. An example of the type of files that you will see created in the MMS-IN directory is shown here: http://support.nowsms.com/discus/messages/485/2135.html You would probably want to write a little program to scan the directory and clean up older files, as otherwise they would just build up. -bn | |||
Matt Allie New member Username: Matt Post Number: 5 Registered: 02-2004 |
OK, everything is clear now, thanks. Last question regarding MMS to email: how does the MS user specify the recipient's email address. Usually recipient is an MSIDN... shall the email address be included in the first line of the MMS text? Then, does the MSIDN matter? | |||
Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1877 Registered: 10-2002 |
For that, you just specify an e-mail address as the recipient. There's nothing special. (The client usually determines automatically whether the recipient address is a phone number or e-mail address. If a phone number, the client is supposed to add /TYPE=PLMN to the recipient address, while an e-mail address is sent as is.) | |||
Matt Allie New member Username: Matt Post Number: 6 Registered: 02-2004 |
I just set up my config and everything is working fine! I created a VASP account and can send MMS from the phone to the MMSC which then stores it into the MMS-IN directory. I have one small issue: it seems that the web interface does not work: whenever I try to send a text SMS, nothing happens! SMPP link to the SMSC is up and I see the SMPP_enquire_link going back and forth on the sniffer but I dont see any SMPP_submit! I have used it before against the same SMSC and this was working fine (WAP OTA, test SMS, binary SMS...): i must be missing something. any clue? thanks | |||
Matt Allie New member Username: Matt Post Number: 7 Registered: 02-2004 |
actually, if I send MMS from mobile to mobile (VASP account modified to "Standard Delivery"), the MO MMS is succesfuly sent, but I dont get any SMS notification and dont see any SMPP traffic going thru besides the enquire_link. thanks | |||
Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1881 Registered: 10-2002 |
Matt, Check the "Q" subdirectory of NowSMS. Are there *.req files in that directory? If so, then the most likely problem is that in the properties for the SMSC connection that you have defined, you need to place a checkmark by "Support any outbound message traffic". -bn | |||
Matt Allie New member Username: Matt Post Number: 8 Registered: 02-2004 |
I enable Debug=Yes in the smsgw.ini file. Below are the SMPPDEUBG.LOG and SMSDEBUG.LOG file. The SMS GW seems to be sending the smpp msg, but again, i dont see anything on the sniffer but enquire_link... SMSDEBUG.LOG: 10:23:15:207 [0] main: Now SMS/MMS Gateway Web server started on port number 8800 10:23:17:270 [0] main: 58 Days remaining in trial version 10:23:37:258 [5] ThreadProcessConnection: Processing connection from 172.16.87.120... 10:23:37:258 [5] ThreadProcessConnection: Processing request /Send%20Text%20Message.htm?PhoneNumber=6503142565&Text=hello+World%21&InfoCharCo unter=&PID=&Submit=Submit 10:23:37:258 [5] Debug: 1 recipient entries 10:23:37:258 [5] Debug: 6503142565 SMPPDEBUG.LOG: 10:19:48:239 ConnectToServer: Connected to 10.176.99.103 (10.176.99.103:16920) 10:19:50:252 DumpPacket: 37 byte packet 10:19:50:252 DumpPacket: 00 00 00 25 00 00 00 02 00 00 00 00 00 00 00 01 % 10:19:50:252 DumpPacket: 53 4D 45 5F 53 4E 44 00 53 4D 45 5F 53 4E 44 00 SME_SND SME_SND 10:19:50:252 DumpPacket: 00 34 00 00 00 4 10:19:50:252 DumpPacket: 22 byte packet 10:19:50:252 DumpPacket: 00 00 00 16 80 00 00 02 00 00 00 00 00 00 00 01 10:19:50:252 DumpPacket: 00 02 10 00 01 34 4 10:19:50:252 SMPPBind: Got an SMPP response 10:19:50:252 DumpPacket: 16 byte packet 10:19:50:252 DumpPacket: 00 00 00 10 00 00 00 06 00 00 00 00 00 00 00 02 10:19:50:252 DumpPacket: 16 byte packet 10:19:50:252 DumpPacket: 00 00 00 10 80 00 00 06 00 00 00 00 00 00 00 02 10:19:50:252 SMPPUnbind: Got an SMPP response 10:19:57:602 ConnectToServer: Connected to 10.176.99.103 (10.176.99.103:16920) 10:19:57:602 DumpPacket: 37 byte packet 10:19:57:602 DumpPacket: 00 00 00 25 00 00 00 02 00 00 00 00 00 00 00 03 % 10:19:57:602 DumpPacket: 53 4D 45 5F 53 4E 44 00 53 4D 45 5F 53 4E 44 00 SME_SND SME_SND 10:19:57:602 DumpPacket: 00 34 00 00 00 4 10:19:57:602 DumpPacket: 22 byte packet 10:19:57:602 DumpPacket: 00 00 00 16 80 00 00 02 00 00 00 00 00 00 00 03 10:19:57:602 DumpPacket: 00 02 10 00 01 34 4 10:19:57:602 SMPPBind: Got an SMPP response 10:19:57:602 DumpPacket: 16 byte packet 10:19:57:602 DumpPacket: 00 00 00 10 00 00 00 06 00 00 00 00 00 00 00 04 10:19:57:602 DumpPacket: 16 byte packet 10:19:57:602 DumpPacket: 00 00 00 10 80 00 00 06 00 00 00 00 00 00 00 04 10:19:57:612 SMPPUnbind: Got an SMPP response 10:21:30:125 ConnectToServer: Connected to 10.176.99.103 (10.176.99.103:16920) 10:21:32:128 DumpPacket: 37 byte packet 10:21:32:128 DumpPacket: 00 00 00 25 00 00 00 02 00 00 00 00 00 00 00 01 % 10:21:32:128 DumpPacket: 53 4D 45 5F 53 4E 44 00 53 4D 45 5F 53 4E 44 00 SME_SND SME_SND 10:21:32:128 DumpPacket: 00 34 00 00 00 4 10:21:32:128 DumpPacket: 22 byte packet 10:21:32:128 DumpPacket: 00 00 00 16 80 00 00 02 00 00 00 00 00 00 00 01 10:21:32:128 DumpPacket: 00 02 10 00 01 34 4 10:21:32:128 SMPPBind: Got an SMPP response 10:22:31:434 SMPPEnquireLink: Sending enquire_link 10:22:31:434 SMPPEnquireLink: Response received for enquire_link 10:23:11:411 DumpPacket: 16 byte packet 10:23:11:411 DumpPacket: 00 00 00 10 00 00 00 06 00 00 00 00 00 00 00 03 10:23:11:411 DumpPacket: 16 byte packet 10:23:11:411 DumpPacket: 00 00 00 10 80 00 00 06 00 00 00 00 00 00 00 03 10:23:11:411 SMPPUnbind: Got an SMPP response 10:23:17:219 ConnectToServer: Connected to 10.176.99.103 (10.176.99.103:16920) 10:23:19:222 DumpPacket: 37 byte packet 10:23:19:222 DumpPacket: 00 00 00 25 00 00 00 02 00 00 00 00 00 00 00 01 % 10:23:19:222 DumpPacket: 53 4D 45 5F 53 4E 44 00 53 4D 45 5F 53 4E 44 00 SME_SND SME_SND 10:23:19:222 DumpPacket: 00 34 00 00 00 4 10:23:19:232 DumpPacket: 22 byte packet 10:23:19:232 DumpPacket: 00 00 00 16 80 00 00 02 00 00 00 00 00 00 00 01 10:23:19:232 DumpPacket: 00 02 10 00 01 34 4 10:23:19:232 SMPPBind: Got an SMPP response 10:24:18:037 SMPPEnquireLink: Sending enquire_link 10:24:18:037 SMPPEnquireLink: Response received for enquire_link 10:25:17:783 SMPPEnquireLink: Sending enquire_link 10:25:17:793 SMPPEnquireLink: Response received for enquire_link | |||
Matt Allie New member Username: Matt Post Number: 9 Registered: 02-2004 |
Bryce, It is my mistake! In the first place, "Support any outbound message traffic" was not set...I then set it but it still would not work... I finally realized that all the changes I was doing would not take effect: I would not hit "Apply". However, I would restart the SMS GW/MMSC servives but that did not help. So it looks like "Apply" does more than just restarting the service. Everything works fine now. Sorry for the confusion. thanks Matt | |||
Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1909 Registered: 10-2002 |
Matt, Glad to hear that was sorted. Apply saves the changes (as should "OK"). So that can definitely be an issue. -bn |