| Control of destination on MMS-IN request |  Search
|
|
NowSMS Support Forums ⬆ NowSMS NextGen Support ⬆ |
◄ ► |
| Author | Message | |||
| marc bazimon Frequent Contributor Username: Marc_orange Post Number: 150 Registered: 01-2007 |
Hi Nowsms support , we have some loop on our MM4 interface due to mis-using of portability from our MMS HUB carrier. let me explain exactly what happen, let s take an example, a subscriber from Orange Reunion( a number ) send a MMS to a number of our competitor ( B number ) who did a portability from Orange to the competitor. So B Number has got a MSISDN that was initially belonging to Orange but now belong to our competitor. SO when A send a mms to b , MMSC will send the MMS through MM4 to an HUB that is supposed to route the MMS to our competitor.Unfortunatly , the HUB doesn't manage portability correctly and do the routing only with the number range. as the number is initially from Orange , they send back the MMS to us. MMSC take this MMS and resend it back to HUB as B number is not bleonging to our network anymore. and this occurs every 3 mns Is there any control on MM4 interface that check the b Number , and control that the b number is well belonging to our network , and if not the MMS is not resending back but deleted ? if not , it could be a good thing to add trhis to the next version, because we have the OUTBOUND MMS queue that increase and this is add some delay in the delivery. currently we have 211 messages in the queue, and we can see that the 211 messages is generated every 3 mns. another board effect from that is that we pay for each mms going through the HUB , even if we know that the fault is on hub side and not the mmsc. Hope it is clear , Thanks beforehand for your feedback , Br Marc | |||
| marc bazimon Frequent Contributor Username: Marc_orange Post Number: 151 Registered: 01-2007 |
It could be also , a check on the OUTBOUND MMS queue that the A number should be belonging to orange reunion before sending. | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8600 Registered: 10-2002 |
Hi Marc, There are some controls to detect this type of looping, where the message should be rejected with an error about "circular routing". Is it possible for you to capture the raw SMTP incoming and outgoing transactions so that we can better determine why a case of circular routing is not detected? There are actually 2 different checks. Is the MM4 Ack route for the.inbound MM4 set to the name of the outbound MM4 route? That should signal a circular routing condition, but I'm having difficulty validating this is what happens when a routing callback returns the route/ As I think this through, I realize that there is one more control available that is typically used for an MM4 interconnect. On the inbound side of the connection,if you change the "MMSC Routing for Received Messages" to "Local MMS Recipients Only", the MMSC will reject any inbound message that cannot be routed to a local account, so that you can. avoid having a situation like you describe. Regards, Bryce | |||
| marc bazimon Frequent Contributor Username: Marc_orange Post Number: 152 Registered: 01-2007 |
Hi Bryce , You are right the control was already set. i finally find the issue. this is due to MMSC User table. as we can not deleting the user that has gone to another competitor ( with the script that was using on windows version ), the MMSC believe that the user is local. even if he left our operator. if i do it manually ( removing the user from db ) , the message is reject so the loop is broken , with this REJECTED-550 Recipient unknown or not local So my plan will be to remove subscriber manually but this will be tough , as the number of subscriber is quite huge. this make outbound queue growing to 300 messages and this produce delay in the mms sending ( 5 minutes approximatly ). is there any way to request the db to delete subscriber with a script ? or don't forget to write this on your todo list for the next version ^^ have a nice day , Br Marc | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8601 Registered: 10-2002 |
Hi Marc, We have been unable to recreate the problem scenario that you describe, while simultaneously recreating other possibly more concerning problem scenarios. When we attempt to recreate your problem scenario, which I’d summarize the key attributes below: - Local MMSC user account exists - ForceRoutingCallback=Yes and callback returning external routing for said local account - "Local MMS Recipients Only” set on inbound MM4 connection Our test results show this scenario resulting in the following error response to the SMTP RCPT TO: command: "551 Unsupported non-local recipient” Somewhat problematically, this error and the associated transaction attempt does not appear to be logged anywhere. Our theory for why you are seeing different results is because in your case, the transaction is not being identified as associated with the particular MM4 inbound account. In your logs, is there a VASP: account named in the User column for the messages in question. I expect there is not, which is why the "Local MMS Recipients Only” setting is not being applied, because the inbound connection id not identified. This, of course, presents other concerns. There are slightly different ways that an inbound connection is authenticated by IP address in the Windows vs. Linux versions of the MMSC. In the Windows version, the IP address must be the name of the connection, and a separate connection must be defined for each originating IP address used by the partner system. In the Linux version, the connection name should not be an IP address, and instead an IP address or a comma delimited list of IP addresses should be configured in the “IP Address Restrictions” and the “Password” must be blank. This presents a concern that the MMSC, with default settings, is processing MM4 requests that it cannot identify the source of. This is not necessarily a security concern as it is expected that firewalls and such are used to limit connectivity to authorized systems, but it is concerning operationally. There is an MMSC.INI setting to require some type of authentication for all SMTP/MM4 requests, under the [MMSC] header, add SMTPRequireAuth=Yes. If you choose to implement that setting, I would first recommend verifying in your logs that the inbound MM4 connection is appearing as a VASP: in the user column. When the SMTPRequireAuth=Yes setting is enabled, expect to see "REJECTED-550 Sender not authorised, authentication required” in the logs for any unidentified requests. Regards, Bryce | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8602 Registered: 10-2002 |
P.S. - Regarding the 5 minute delay. Increasing the "Max Connections" for the MM4 Outbound Connection may improve performance. | |||
| marc bazimon Frequent Contributor Username: Marc_orange Post Number: 153 Registered: 01-2007 |
Hi Bryce Thanks for the feedback , I did set the maximum connecctions up to 10 , and the queue is decreasing now , regarding our trouble , you are right and the behaviour is what we expect , but due to the cleaning that we have to do on our user database to delete the subscriber who had left our network , we will have to do it manually so it is tough ^^ it was the board effect of why we had some loop , but setting the "Local MMS Recipients Only” was the clue. again a way to do batch for deleting subscriber could be a good things for the next version of nextgen. have a nice day , Br Marc | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8603 Registered: 10-2002 |
Hi Marc, We are working on porting the mmsuser utility (specifically the -export and -import options) to Linux. That will make it easier to batch delete subscribers. I would caution that for the "Local MMS Recipients Only" setting to function properly, the MMSC needs to be able to associate the inbound MM4 request with a defined MM4 Inbound Connection with the connection's MM4 Ack Route pointing to an associated MM4 outbound connection. If an inbound message on that connection would result in routing to the "MM4 Ack Route", the message will be rejected for circular routing. | |||
