| Using nowsms for MMS application software testing |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through February 20, 2004 ⬆ |
◄ ► |
| Author | Message | |||
| Eric Unregistered guest |
Greetings, I work for an MMS software application developer. In lab environment I plan to test my MMS applications against nowsms GW/MMSC to verify it works. I do not have a network (GPRS/GSM) for that purpose. Can I use nowsms product to communicate with my application (with WAP) using UDP for ewxample to test my application? How can I test my applicaiton against industry standard products if I do not have a network? Your valued comments are welcome. Regards, Eric | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1698 Registered: 10-2002 |
Hi Eric, If you're going to be communicating over UDP, then this sounds like you are planning to use the WAP protocols (which is normal for a real world MMS client). You can't connect directly to an MMSC over UDP. The UDP requests are sent to a WAP proxy (same terminology as WAP gateway), which proxies the requests to the MMSC over HTTP. You can use a WAP Proxy (see www.nowwap.com) in conjunction with the NowSMS MMSC for a more complete environment. However, without a live network, it is difficult to simulate the entire MMS process. Allow me to explain why ... When a mobile phone sends an MMS message, what it is doing is logically performing an HTTP POST of the MM1 m-send.req PDU. (Operating over the WAP stack, the client performs a WSP CONNECT to the WAP gateway, and then issues a WSP POST to the MMSC via the WAP Gateway, followed by a WSP DISCONNECT.) However, when a mobile phone receives an MMS message, what it is actually receiving is an MMS notification message which it receives over SMS. This MMS notification message contains header information about the MMS message, and a URL pointer that the recipient must fetch in order to retrieve the content of the MMS message. The problem in a simulated environment such as yours is how to get this MMS notification message into the client. NowSMS expects to deliver that MMS notification over SMS (and that is typically how your client would receive it). We do have some customers who look at our outbound SMS queue (*.req files in Q subdir of NowSMS), and then cut & paste the data from these notification messages into a simulator that can feed the messages into their client. That is the low-tech approach. A slightly higher tech approach is that NowSMS supports different types of SMSC connections. One of the types is a configurable HTTP based connection. Here you can define a script which NowSMS will call when it wants to send an SMS message. If you can supply a script that feeds the SMS message into your simulated environment automatically, then you are making progess. For even higher tech approaches, companies like Anite Telecoms (www.anitetelecoms.com) can provide equipment to simulate a GSM/GPRS network. -bn | |||
| Eric Unregistered guest |
Dear Bryce, Thank you for your prompt informative reply. It was educational to me. However I still do have a question to ask, if you do not mind. WAP and SMS/MMS runs over GPRS/GSM. WE have layered protocols. Regarding WAP it really does not matter the underline layers. What if we use UDP or IP to replace the bearer layer? BTW, I will also follow up on anite Tel. Thanks, Eric | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1713 Registered: 10-2002 |
Eric, We have rather limited support for sending the MMS notification via WAP Push IP/UDP instead of SMS. Currently, it is possible using our web interface to specify an IP address instead of a phone number as the destination address for an MMS (or a WAP push). However, we don't support an IP address as the recipient address for phone-to-phone MMS. This is something that we could probably add quite easily, but we've been somewhat reluctant. The issue is that for a connection-less WAP push, UDP is not a very reliable transport, while SMS is far more reliable. (Supporting the notification over UDP would in a general case would require more sophisticated retry scheduling.) -bn | |||
