| VASP |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through December 09, 2003 ⬆ |
◄ ► |
| Author | Message | |||
| Anonymous |
Hello! Has anyone tried to use NowSMS/MMS as MMSC for VASP meaning: 1. sending from 3rd party application MM7_submit, MM7_deliver etc. commands to MMSC? 2. Any other development for example from PHP trying to use NowSMS/MMS as MMSC sending/receiving MMS to/from user? | |||
| Bryce Norwood - NowSMS Support |
The VASP functions are new to the v5.0 release (which is still in beta, but is quite stable). There are some discussions in the discussion forum area that is setup specifically for v5.0 ... one message that might help you out is this one below which talks about MM7, and in particular, this user needed some help understanding the configuration so that delivery reports would get forwarded back via MM7. http://support.nowsms.com/discus/messages/485/521.html | |||
| Anonymous |
Ok, thanks. I added my questions there.. Antti | |||
| Anonymous |
when i try to send MMS message but it got a error Error: Unable to fetch URL: http://www.nowsms.com:81/20030909/10/3F5D4DCEa.MMS can you tell me the way to fix this problem. Thanks alot! | |||
| Anonymous |
I has more question: I want to build a app to send a picture (MMS_message)to simulator mobile. Can I do this, if can tell me more what i must do | |||
| Bryce Norwood - NowSMS Support |
Regarding:
You have configured your system indicating that the "Local Host Name or IP Address" for the PC that is running your Now SMS/MMS Gateway as being "www.nowsms.com", which is incorrect. This setting should be the "local host name or IP address" of your PC that is running the Now SMS/MMS Gateway software. Note that this ip address or host name needs to be accessible over the internet so that mobiles can connect back to this host to retrieve the content of MMS messages. -bn | |||
| Bryce Norwood - NowSMS Support |
On the simulator issue, I don't expect you to get far with a simulator. Please see the following thread: http://support.nowsms.com/discus/messages/1/662.html | |||
| arunj |
Hi all I have an doubt regarding the generation/assignment of Transaction ID. UA's MM1_submit.REQ (with VAS CODE) deliverd to VASP by MMS R/S as MM7_deliver.REQ and VASP sends MM7_deliver.RES. both MM7_deliver.??? message uses Transaction ID who generates (assaign) this ID? In rfc 23.140 V5.7.0 in 8.7.2.3 clause it mentioned as "Transaction Identification: The VASP shall provide an unambiguous transaction identification within a request. The response shall unambiguously refer to the corresponding request using the same transaction identification" Please clarify in case of MM7_deliver.REQ/RES who will generate the TID, either MMS R/S or VASP thanks } | |||
| Bryce Norwood - NowSMS Support |
This would probably be better posted on the "MMS Technical Issues" forum. I suspect you might be expecting too much out of the "Transaction ID". Let me explain ... From an MM1 perspective, keep in mind that a transaction id has a very limited life span. The MM1 M-send.req requires that the submitting client supply a "transaction id". But this "transaction id" does not apply to the entire life span of the submitted message. It applies only to this "send" transaction. The M-send.conf response back from the MMSC sends back the transaction id ... and at that point, the transaction is done, and the life span of the transaction id has ended. Now, as other subsequent transactions in the life span of the MMS message also involve transaction ids, some MMSCs might carry the original transaction id through to other transactions, but based upon my reading of the specification you should *NOT* expect such behaviour. Instead, you should rely on the "Message id" returned in the "M-Send.conf" response from the MMSC, as an ID that will have a longer life span (although there can be issues with this message id changing if a message gets routed between different MMSCs ... hopefully any inter-MMSC-link would properly remap message-ids in any delivery confirmation messages). Note, however, that the "message id" is optional in the "M-Send.conf" response, and the MMSC does not have to return a "message id". In fact, I have observed some operator MMSCs that do not return this id. Anyway, that is my interpretation of how the "Transaction ID" is specified in the MM1 spec from the OMA. If we then look at these same issues on the MM7 side, I have the same interpretation. A transaction ID is used to identify a particular request/response transaction, not the message itself. The submitting agent should generate the transaction id ... but keep in mind that this id really exists only to be matched up with the transaction ID in a response. The idea here is that an agent might have multiple requests outstanding, and this allows responses to be matched up with the originating request. Again, this is just my interpretation of the specifications. -bn | |||
