| Can NowSMS MMSC continue sending notification message to MMS client... |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through February 20, 2004 ⬆ |
◄ ► |
| Author | Message | |||
| Scottie tu New member Username: Guanhua Post Number: 1 Registered: 11-2003 |
Hi, Does the MMSC keep sending the notification message to the MMS client until it receives the M-NotifyResp.ind message? Thanks. | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1294 Registered: 10-2002 |
At present, no it does not. It assumes reliable SMS delivery by the SMSC connection(s). The reason we chose to implement things this way is because otherwise most phones cannot recognise that they have received duplicate copies of the same notification ... which can happen if the notification retry schedule is too aggressive. If you have a specific requirement where you believe we would us to implement a retry schedule for the notification, we can discuss this (probably better to do that via e-mail to nowsms@now.co.uk). -bn | |||
| Scottie tu New member Username: Guanhua Post Number: 2 Registered: 11-2003 |
Dear Bryce, According OMA MMS specs, the MMS client must return M-NotifyResp.ind message to server, after receiving the mms notification message. If the MMS client doesn't follow this rule. Do any errors coour? Thanks | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1317 Registered: 10-2002 |
Scottie, If you are designing an MMS client, you do want to implement this. If you do not, then there are some MMSCs that will retry the notification on a very aggressive schedule, and you will keep receiving the MMS notification. The problem is that this M-NotifyResp.ind message is sent to the URL for the MMSC that has been configured in the phone, which does not have any relationship to the URL of the retrieved MMS message. So it assumes a single MMSC environment (which is one of the reasons that we do not currently perform the retry, as we are frequently used as a secondary MMSC). | |||
| Scottie tu New member Username: Guanhua Post Number: 3 Registered: 11-2003 |
Dear Bryce, Thanks. I have another question ^_^. When the user wants to get a mms msg from the MMSC, he can issus a WSP or Http request (GET). Then, the mms message is carried in the WSP or Http response (M-Retrieve.conf). If the transactio id is included in this msg, it means that the MMS client has to response M-Acknowledge.ind to MMSC. If the user doesn't send the M-Acknowledge.ind message to the MMSC. What happens? Does the MMSC do something? Thank you. | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1340 Registered: 10-2002 |
If the MMSC does not receive an M-NotifyResp.ind or M-Acknowledge.ind, then many MMSCs will retry the notification. If you perform immediate download of the MMS message, it is possible to only send the M-NotifyResp.ind with X-Mms-Status = Retrieved. M-Acknowledge.ind is used when you defer the initial retrieval. See Section 5 of the OMA's MMS Client Transactions specification for a flow diagram. -bn | |||
| Anonymous |
when mmsc_send_conf is sent by wap or by sms | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1468 Registered: 10-2002 |
M-Send.req is transmitted over HTTP/WSP POST ... and the M-Send.conf PDU is the HTTP/WSP response to that POST. When you issue an HTTP/WSP GET or POST, a response is always expected ... | |||
