| MMSC transactions from multiple PGW (Mobile Operator MMSC) |  Search
|
|
NowSMS Support Forums ⬆ NowSMS NextGen Support ⬆ |
◄ ► |
| Author | Message | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8426 Registered: 10-2002 |
I thought it was worth sharing an interesting support query from one of our customers configuring NowSMS NextGen in an operator MMSC configuration:
| |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8427 Registered: 10-2002 |
The short answer: NowSMS NextGen version 2021.03.11 and later have been updated to support the MSISDNICAPServer setting as a comma delimited list of addresses, such as: MSISDNICAPServer=1.1.1.1:1344,2.2.2.2:1344 The MMSC will loop through the servers until it finds one that can identify the subscriber. --- The customer was happy with this answer, because it resolved the problem. But I thought this question was worth sharing as a starting point for updating some of our documentation with regard to MMSC user authentication/identification. To be continued ... | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8428 Registered: 10-2002 |
The longer explanation ... The MMS protocol does not define user authentication/identification. So, there are a series of settings described in https://nowsms.com/doc/mmsc-messaging-server/operator-mmsc-considerations that allow our MMSC to integrate into a mobile operator environment. The MMSC receives all requests as HTTP requests submitted over TCP/IP. The "From" header when a client submits a message can contain the device phone number (or a token that asks the MMSC to insert the MSISDN), but it would be a serious security risk for an MMSC to accept a message sender without validation. There are different ways that the MMSC can authenticate users but all of these techniques involve other network components inserting an HTTP header that contains the MSISDN. This HTTP header is usually X-MSISDN. This header can be inserted by the PGW, GGSN, SGSN, or other proxies or gateways. Historically, MMSC transactions were routed to a WAP gateway or proxy (such as NowWAP). The GGSN would send a RADIUS accounting feed to these gateways, and the gateway would insert the HTTP header as part of the process of proxying the transaction. In modern environments, WAP gateways and proxies are infrequently used. For proxy-less configurations, in 2015, we implemented the ICAP protocol in our MMSC. (More explanation here: https://nowsms.com/operator-mmsc-without-a-wap-gateway-icap) The MMSC can use the ICAP protocol to query a network component for the MSISDN. Network equipment vendors, including Yate, have begun implementing ICAP in the PGW to facilitate this requirement. And in this configuration, it may be necessary for the MMSC to query more than one PGW via ICAP. | |||
