| VASP Configuration |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through February 20, 2004 ⬆ |
◄ ► |
| Author | Message | |||
| Anonymous |
Hello! I am testing version 5 of your gateway. I am interested in using it for VASP meaning I would like to use it as MMS GW for my external MMS services. Simple questions really: 1. I added new VASP. To which port should I post the MMS now, if I know the IP of the MMS GW? 2. Which formats of MMS are supported? MM7 - yes? Binary - yes? 3. Any guides on the subjects or coming? | |||
| Bryce Norwood - NowSMS Support |
We are still working on completing the documentation of these features, so it can be a little difficult to determine how they work in the beta release. VASP (Value Added Service Provider) accounts that can post MMS messages through the gateway are, of course, defined on the "MMSC VASP" page of the configuration dialog. A VASP can use MM7, MM4, MM1 or EAIF to post a message to the gateway. The VASP Account settings specify which of these protocols a VASP is allowed to use. Below I'll try to provide some information on how each of these protocols would be used to submit a message to the Now SMS/MMS Gateway. MM7 To post to the Now SMS/MMS Gateway via MM7, you must connect to the HTTP port configured for the MMSC on the "MMSC" page of the configuration dialog. And you must perform an HTTP POST of the MM7 content to a URI of "/mm7", which is how the gateway knows that the VASP intends to submit in the MM7 format. The HTTP headers of your POST must include a "Content-length:" header, and it needs to either include an "Authorization:" header for Basic authentication using the username and password configured for the account, or it must originate from an IP address that matches the name configured for the VASP account. (If your software cannot generate an "Authorization:" header, it is possible to configure the account name for the VASP as an IP address, and in this case, the MMSC will recognise any connections from that IP address as being for this VASP account.) The "Content-type:" header in the POST should be one of the "multipart" types (usually "multipart/related"), and should include a "boundary=" parameter that delimits the different parts of the message. The first part of the multipart message is expected to be the XML for the MM7 request, and we're going to expect to see a <Recipients> section with at least one <To>, <Cc> or <Bcc> recipient specified. The second part of the multipart message is expected to be the content for the MMS message, and this in turn will usually be another MIME multipart structure. The following example is from the official MM7 specification that is included in the 3GPP TS 23.140 specification: Note that our MMSC currently does not support the displayOnly="TRUE" attribute for a recipient, so you should avoid using that at this time (NowSMS will try to send to a recipient that is specified as displayOnly). Other than that, this is a good example. Of course, as part of the MMS content, you would probably want to include a SMIL file (application/smil), which this example does not include. And a VASP would be sending MMS messages to phone numbers (<Number>) rather than e-mail addresses (<RFC2822Address>). Also note that the MM7 XML portion of the document (the first part of the main multipart content) should not use any Content-Transfer-Encoding, it should always be expressed without any encoding. For the portion of the document that includes the MMS content itself, you can use Content-Transfer-Encoding of either quoted-printable or base64, or no encoding can be specified in which case it is assumed that the binary data is to be included as is. And one more note that comes to mind, for the NowSMS MMSC, you must POST to /mm7, which is, of course, different from the following example. And still one more note. While it is legal to have space characters within a MIME boundary, I personally don't think it's a good idea, so I've changed the example to use "-" characters whereas the original example in the specification had spaces. POST /mms-rs/mm7 HTTP/1.1 Host: mms.omms.com Content-Type: multipart/related; boundary="NextPart_000_0028_01C19839.84698430"; type=text/xml; start="</tnn-200102/mm7-submit>" Content-Length: nnnn SOAPAction: "" --NextPart_000_0028_01C19839.84698430 Content-Type:text/xml; charset="utf-8" Content-ID: </tnn-200102/mm7-submit> <?xml version="1.0" ?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header> <mm7:TransactionID xmlns:mm7="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-M M7-1-3" env:mustUnderstand="1"> vas00001-sub </mm7:TransactionID> </env:Header> <env:Body> <SubmitReq xmlns="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1 -3"> <MM7Version>5.6.0</MM7Version> <SenderIdentification> <VASPID>TNN</VASPID> <VASID>News</VASID> </SenderIdentification> <Recipients> <To> <Number>7255441234</Number> <RFC2822Address displayOnly="true">7255442222@OMMS.com</RFC2822Address> </To> <Cc> <Number>7255443333</Number> </Cc> <Bcc> <RFC2822Address>7255444444@OMMS.com</RFC2822Address> </Bcc> </Recipients> <ServiceCode>gold-sp33-im42</ServiceCode> <LinkedID>mms00016666</LinkedID> <MessageClass>Informational</MessageClass> <TimeStamp>2002-01-02T09:30:47-05:00</TimeStamp> <EarliestDeliveryTime>2002-01-02T09:30:47-05:00</EarliestDeliveryTime> <ExpiryDate>P90D</ExpiryDate> <DeliveryReport>true</DeliveryReport> <Priority>Normal</Priority> <Subject>News for today</Subject> <ChargedParty>Sender</ChargedParty> <DistributionIndicator>true</DistributionIndicator> <Content href="cid:SaturnPics-01020930@news.tnn.com" allowAdaptations="true"/> </SubmitReq> </env:Body> </env:Envelope> --NextPart_000_0028_01C19839.84698430 Content-Type: multipart/mixed; boundary="StoryParts-74526-8432-2002-77645" Content-ID:<SaturnPics-01020930@news.tnn.com> --StoryParts-74526-8432-2002-77645 Content-Type: text/plain; charset="us-ascii" Science news, new Saturn pictures... --StoryParts-74526-8432-2002-77645 Content-Type: image/gif Content-ID:<saturn.gif> Content-Transfer-Encoding: base64 R0lGODdhZAAwAOMAAAAAAIGJjGltcDE0OOfWo6Ochbi1n1pmcbGojpKbnP/lpW54fBMTE1RYXEFO ... --StoryParts 74526-8432-2002-77645-- --NextPart_000_0028_01C19839.84698430-- ----- MM4 To post to the NowSMS MMSC via MM4, you are basically making an SMTP connection, and you would connect to the "SMTP Port Number" that is configured on the "MMSC" page of the configuration dialog. To submit a message via MM4, the VASP must authenticate via SMTP using the "AUTH LOGIN" approach, or similar to the way it works for MM7, the VASP account can be created with an IP address as the "Account Name", and in that case any connection from that IP will be accepted as being a connection from that VASP account. "AUTH LOGIN" is rather simple. Basically, as part of the SMTP dialog, after the initial HELO or EHLO command, the SMTP client needs to issue the command AUTH LOGIN. The SMTP server responds with a "300" series code and prompts for the account name (the prompt after the code is a BASE64 encoded string). The client sends the account name as a BASE64 encoded string. The SMTP server responds with another "300" series code prompting for the password, and the client responsds with the password as a BASE64 encoded string. A "200" series response indicates that the authentication was accepted, a "500" series response indicates that it was not. The SMTP dialog then continues as normal, generally with a "MAIL FROM:" command from the client indicating the sending address of the message, followed by one or more "RCPT TO:" commands to indicate the recipients for the message. Note that NowSMS expects the "RCPT TO:" addresses to be in a format of phonenumber@domain.name or phonenumber/TYPE=PLMN@domain.name, where "domain.name" is the "Domain Name for MMS E-Mail" configured on the "MMSC" page of the configuration dialog. (The "Local Host Name or IP Address" value is also acceptable here.) If the domain name is not present, the MMSC will reject the recipient. As special support for Multimedia WAP Push, the following address formats are also supported to specify Multimedia WAP Push to be used for sending to the phone number: phonenumber.wappush@domain.name or phonenumber/TYPE=WAPP@domain.name. The actual MMS message is then transmitted via the "DATA" command. Normally an MMS message would be a multipart MIME message with multiple content parts, although NowSMS will also accept a message that includes only a single part. The MM4/SMTP dialog looks something like this: The dialog looks something like this (IN means from server, OUT means from client): IN: 220 SMTP Ready OUT: HELO client.name (or EHLO client.name) IN: 250 OK (or a multiline response if EHLO was used) OUT: AUTH LOGIN IN: 334 VXNlcm5hbWU6 ("Username:" BASE64 encoded) OUT: dGVzdA== ("test" BASE64 encoded) IN: 334 UGFzc3dvcmQ6 ("Password:" BASE64 encoded) OUT: dGVzdA== ("test" BASE64 encoded) IN: 235 Ok OUT: MAIL FROM: <username@domain.com> IN: 250 Ok OUT: RCPT TO: <+447778889999/TYPE=PLMN@mms.domain.com> IN: 250 Ok OUT: DATA IN: 354 Ok, end with "." on a new line... OUT: (Transmit MIME encoded message, then end with a line with only the . character) IN: 250 Message Accepted OUT: QUIT Using the example data from the MM7 message above, the MIME encoded message would look something like this: To: +447778889999/TYPE=PLMN@mms.domain.com From: username@domain.com Subject: News for today Content-Type: multipart/mixed; boundary="StoryParts-74526-8432-2002-77645" Content-ID:<SaturnPics-01020930@news.tnn.com> --StoryParts-74526-8432-2002-77645 Content-Type: text/plain; charset="us-ascii" Science news, new Saturn pictures... --StoryParts-74526-8432-2002-77645 Content-Type: image/gif Content-ID:<saturn.gif> Content-Transfer-Encoding: base64 R0lGODdhZAAwAOMAAAAAAIGJjGltcDE0OOfWo6Ochbi1n1pmcbGojpKbnP/lpW54fBMTE1RYXEFO ... --StoryParts-74526-8432-2002-77645-- --------- MM1 To post to the Now SMS/MMS Gateway via MM1, you must connect to the HTTP port configured for the MMSC on the "MMSC" page of the configuration dialog. And you must perform an HTTP POST of the MM1 content to a URI of "/mm1", which is how the gateway knows that the VASP intends to submit in the MM1 format. The HTTP headers of your POST must include a "Content-length:" header. To specify the username and password of the VASP account, you must either include an "Authorization:" header for Basic authentication using the username and password configured for the account, or the username and password can be specified on the request URI (e.g., /mm1/username=password). Alternatively, the request must originate from an IP address that matches the name configured for the VASP account. (If your software cannot generate an "Authorization:" header, it is possible to configure the account name for the VASP as an IP address, and in this case, the MMSC will recognise any connections from that IP address as being for this VASP account.) The "Content-type:" header in the POST should be "application/vnd.wap.mms.message", and the message should be a binary MMS message of the m-send-req format, formatted according to the MMS Encapsulation Specification, published by the Open Mobile Alliance. Consistent with HTTP specifications, a "400" or "500" series HTTP response would be considered an error condition. The MMSC might return a "200" series response even if an error did occur, in which case information would be included in the "X-Mms-response-status" field of the MM1 response (MIME type "application/vnd.wap.mms-message", X-Mms-Message-Type of "m-send-conf") would contain a response-status value other than Ok. ------ EAIF To post to the Now SMS/MMS Gateway via EAIF, you must connect to the HTTP port configured for the MMSC on the "MMSC" page of the configuration dialog. And you must perform an HTTP POST of the EAIF content to a URI of "/eaif", which is how the gateway knows that the VASP intends to submit in the EAIF format. The HTTP headers of your POST must include a "Content-length:" header. To specify the username and password of the VASP account, you must either include an "Authorization:" header for Basic authentication using the username and password configured for the account, or the username and password can be specified on the request URI (e.g., /eaif/username=password). Alternatively, the request must originate from an IP address that matches the name configured for the VASP account. (If your software cannot generate an "Authorization:" header, it is possible to configure the account name for the VASP as an IP address, and in this case, the MMSC will recognise any connections from that IP address as being for this VASP account.) The "Content-type:" header in the POST should be "application/vnd.wap.mms.message", and the message should be a binary MMS message of the m-send-req format, formatted according to the MMS Encapsulation Specification, published by the Open Mobile Alliance. MMS message recipients can be specified either in the MMS message content itself, or in the "X-Nokia-MMSC-To:" header. Consistent with HTTP and EAIF specifications, a "400" or "500" series HTTP response would be considered an error condition. The expected response for a valid message submission would be an HTTP "204" response that includes an "X-Nokia-MMSC-Message-Id:" header. (In current beta releases, the MMSC might return a "200" series response even if an error did occur, in which case information would be included in the "X-Mms-response-status" field of an MM1 response with the "X-Mms-Message-Type" field containing a response-status value other than Ok. We expect this to be corrected before v5.0 is released.) | |||
