You're on the right path - but there are a couple of things you should be aware of. First, for MO (Mobile Orignated) MMS - it's quite straight forward: The Mobile Device sends an HTTP POST to the MMSC. However, there is one very important detail missing: identity management. In order for the MMSC to know "who" you are (aka who is posting the MMS Message), it relies on what has been traditionally known as a "WAP Gateway". In the WAP2 Context, this is an HTTP Proxy (WAP1 has its own stack for communication between the mobile and the WAPGW). Usually, when you create a PDP Context, the GGSN will send a RADIUS Accounting message to the WAP Gateway. This gives the WAP Gateway you Mobile IP Address and your Phone Number. When you do the HTTP POST to the MMSC, the MMSC relies on the WAP Gateway appending your Phone Number (MSISDN) as an HTTP Request header. For security reasons, the MMSC is never directly accessible by the Mobile - only via the WAP Gateway. So in order to support MO Originated MMS the following need to happen: 1) OpenGGSN needs to send RADIUS 2) An HTTP Proxy that appends the MSISDN as an HTTP Request Header needs to be had Second, for MT (Mobile Terminated) MMS - you need everything for MO plus you need a Push Proxy Gateway. That is, once an MMS is placed on your MMS it needs to alert the subscriber that they have an MMS waiting. This is done by Posting an MMS Encapsulated MMS Notification to the PPG - with the subscriber's MSISDN as the recipient. The PPG will then encapsulate the message, and send it as one or more specially crafted SMS's (typically via SMPP). Once the mobile receives the MMS notification, it'll retrieve the MMS Content Location from the Notification. It then sends an HTTP GET via the WAPGW to the MMS Location (this is a unique url like http://mmsc.carrier.com/fklvu348f9gervrfd). The WAPGW will append the MSISDN as a request header, and the MMSC will validate that the requester (based on MSISDN in request header) is the owner of the message. If so, the response to the HTTP request will be the actual MMS Message. So in addition to the requirements for MO Originated MMS, MT MMS also requires: 1) A Push Proxy Gateway There are opensource PPGs available (See: Kannel). Where the challenge is, is that OpenBSC does not have an SMPP Interface today (at least not osmo-nitb). I believe there's also an opensource MMSC available today. Additionally, I have written my own PPG and MMSC and could assist if you have questions on these. The biggest challenge, I think is the SMPP Interface to OpenBSC. Hacking RADIUS into openggsn, and hacking squid to support radius request headers (it may already support it?) seem very simple by comparison. Thanks, Gus On Mon, Aug 15, 2011 at 2:33 AM, Simon Barnett <n6vale(a)googlemail.com>wrote;wrote: