Before submitting a message via EAIF, a VASP (Value Added Service Provider) account must be defined to the Now SMS & MMS Gateway. This account is defined on the “MMSC VASP” configuration dialog.

To post to the Now SMS & MMS Gateway via EAIF, you must connect to the HTTP port configured for the MMSC on the “MMSC” 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 account name and password of the VASP account, you must either include an “Authorization:” header for Basic authentication using the account name and password configured for the VASP account, or the account name and password can be specified on the request URI (e.g., /eaif/account=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 beta releases of the v5.0 Now SMS & MMS Gateway, 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 have been corrected prior to the v5.0 release.)