[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06

SIPPING                                                      C. Jennings
Internet-Draft                                             Cisco Systems
Expires: January 9, 2005                                          G. Jun
                                                           Bitpass, Inc.
                                                           July 11, 2004


                        Payment for SIP Services
                     draft-jennings-sipping-pay-00

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 9, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   Communication systems require that a person receiving a call be able
   able to charge the caller when they are from different administrative
   domains.  This is necessary for making fair exchanges of service
   between two different communicating parties and is a major strategy
   for reducing the viability of SPAM.  This draft proposes an approach
   for doing this in SIP.  The approach relies on a third party to act
   as a payment service provider and is optimized for very simple, low
   value transactions.  It does not provide the full range of services



Jennings & Jun          Expires January 9, 2005                 [Page 1]


Internet-Draft                SIP Payment                      July 2004


   that are desirable in typical online trading systems.

   This draft is being discussed on the sipping@ietf.org mailing list.
   It is at a very early stage and is missing significant syntax
   details.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1   UAC Behavior . . . . . . . . . . . . . . . . . . . . . . .  5
     4.2   UAS Behavior . . . . . . . . . . . . . . . . . . . . . . .  6
     4.3   Computing costs  . . . . . . . . . . . . . . . . . . . . .  7
     4.4   Proxy Behavior . . . . . . . . . . . . . . . . . . . . . .  7
     4.5   Payment Service Provider Behavior  . . . . . . . . . . . .  7
     4.6   Customer and Merchant Enrollment and Transfer
           functions. . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.7   Account Names  . . . . . . . . . . . . . . . . . . . . . .  8
     4.8   Merchant Fetching Public Key . . . . . . . . . . . . . . .  8
   5.  SIP Extensions . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.1   Update response code 402 . . . . . . . . . . . . . . . . .  8
   6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.1   Offer  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.2   Request for Payment  . . . . . . . . . . . . . . . . . . . 10
     7.3   Receipt  . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.4   Computing Signatures . . . . . . . . . . . . . . . . . . . 11
     7.5   Verifying Signature  . . . . . . . . . . . . . . . . . . . 11
     7.6   Replay Prevention  . . . . . . . . . . . . . . . . . . . . 11
   8.  Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1   SPAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.2   Micro Billing  . . . . . . . . . . . . . . . . . . . . . . 12
   9.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 12
   10.   Security Consideration . . . . . . . . . . . . . . . . . . . 12
   11.   IANA Registration  . . . . . . . . . . . . . . . . . . . . . 12
   12.   References . . . . . . . . . . . . . . . . . . . . . . . . . 13
   12.1  Normative References . . . . . . . . . . . . . . . . . . . . 13
   12.2  Informational References . . . . . . . . . . . . . . . . . . 13
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
       Intellectual Property and Copyright Statements . . . . . . . . 15









Jennings & Jun          Expires January 9, 2005                 [Page 2]


Internet-Draft                SIP Payment                      July 2004


1.  Introduction

   The scheme is very simple and is optimized for low value
   transactions.  It involves three parties: a consumer who is the
   caller, a merchant who is the person being called, and a common third
   party to broker the transaction, which is called the payment service
   provider.

      P                          C                         M
      |                          |  1) Call                |
      |                          |------------------------>|
      |                          |                         |
      |                          |  2) 402+Offer           |
      |  3) Request for Payment  |<------------------------|
      |<-------------------------|                         |
      |                          |                         |
      |  4) Receipt              |                         |
      |------------------------->|  5) Call+Receipt        |
      |                          |------------------------>|
      |                          |                         |
      |                          |  6) 200 OK              |
      |                          |<------------------------|
      |                          |                         |

   In the figure above, the Customer or caller is labeled C, the
   Merchant or person being called is M, and the Payment Service
   Provider is P.  Initially C makes a call to M.  M determines that a
   payment is required and includes information about the payment in an
   Offer body of a 402 (Payment Required) response to C.  C looks at
   this Offer and decides to make a payment.  C instructs P to make a
   transfer from C's account to M's account and provides C with a
   Receipt for this transfer.  C resubmits the call to M but this time
   provides the Receipt for the transaction.  M determines whether it
   feels the Receipt is valid or not and allows the call.

   The Offer includes the third parties, P, that are acceptable to M,
   the amount of transaction, the account identifier for M at P, and
   specific transaction data determined by M to make it easier for M to
   avoid replay attacks.  C includes this information when making the
   Request for Payment to P; adds its own account information and
   authorization password; and sends this to P, which produces a Receipt
   for the transaction if it is successful.  This transfer from C to P
   is made across an encrypted, integrity protected channel.  The
   Receipt includes a time when P made the transaction and a signature
   of the critical information in the Receipt made with P's public key.
   C resubmits the call to M with the Receipt from P.  M can check for
   replay attacks using the date and opaque data it provided in the
   offer.  M can then check the signature is valid using P's public key.



Jennings & Jun          Expires January 9, 2005                 [Page 3]


Internet-Draft                SIP Payment                      July 2004


   HTTPS is used for the communications between P and C, while SIP is
   used for the communications between C and M.

   This scheme does not provide for the tightest of security.  There is
   no guarantee or recourse if M does not provide the service after C
   transfers money into M's account.  No refunds are possible in the
   protocol.  The system is designed for low value transactions in
   which, if M cheats, C can choose to never deal with M again but the
   value of the transaction is lost.  This scheme is for online systems
   in which M, C and P can all communicate with real time messages.  The
   system does not provide anonymous transactions.  While it is possible
   to develop schemes that deal with some of these problems, payment
   service providers deploying them have not been willing to provide
   services for transaction fees on the order one US cent.  The authors
   believe that the simplified scheme presented here will make it easier
   to reach these low value transactions.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [3].

   This work adopts the terminology from the framework in RFC 2801 [8].

   Customer: The entity that is paying for the call, typically the SIP
   UAC.

   Merchant: The entity wishing to be paid for the call, typically the
   SIP UAS or a proxy in the same administrative domain as the UAS.

   Payment Service Provider (or PSP): The third party that handles the
   transfer of currency from Customer to Merchant.  RFC 2801 refers to
   this as the Brand.

   Offer: The information sent from the Merchant to the Customer
   describing what payment is needed.

   Request for Payment (or RFP): The information sent from the Customer
   to the Payment Service Provider describing the transfer of currency
   needed.

   Receipt: The information sent from the Payment Service Provider to
   the Customer and passed on to the Merchant.  It provides confirmation
   that a particular transaction has occurred.

   Currency: Could be a classical currency such as the Euro or US Dollar
   or could be a pseudo currency such as airline mileage points.



Jennings & Jun          Expires January 9, 2005                 [Page 4]


Internet-Draft                SIP Payment                      July 2004


3.  Requirements

   Provide a system for callers to pay the person they are calling using
   a 3rd party clearing house.

   Work for very low value transactions.

   Support anonymous customers

   Not need to support refunds or guarantee that the 3rd party can
   prevent the Merchant from cheating.

4.  Protocol

4.1  UAC Behavior

   The UAC SHOULD indicate that it can accept the application/pay-offer
   MIME type in SIP requests it sends.

   In the case wherein which the UAC receives a 402 response containing
   an application/pay-offer body, it MUST check that this offer is
   acceptable to the user of the UAC.  This could be done using a policy
   that was previously entered by the user.  If the offer contains a
   Payment Service Provider with which the user has an account and the
   offer is acceptable, then the UAC sends a Request for Payment to the
   Payment Service Provider.  This is done by setting up an HTTPS
   connection to the URL specified for the Payment Service Provider and
   performing an HTTP POST of the XML Payment document.  The exact
   syntax of this document is defined in section 7.  The UAC needs to
   look at the available Payment Service Providers, cost, and currency
   and select an appropriate one.  The UAC MUST copy the
   PaymentServiceProviderData fields from the offer into the Request for
   Payment.  The UAC must look at the cost elements in the offer to
   decide how large a payment the user wishes to make and set the amount
   and currency field appropriately.  Finally it needs to fill the
   CustomerData fields.  It is critical that the UAC check the
   certificate of the HTTPS TLS connection as specified in RFC 2818 [5]
   and RFC 2246 [4].

   The response from the Payment Service Provider either will be an
   error or will contain an application/pay-receipt body.  The user
   needs to be informed if an error is received and the transaction
   SHOULD not be retried unchanged.  When a valid response is received,
   the UAC SHOULD resubmit the SIP transaction that caused the 402 but
   this time attach the application/pay-receipt body to it.

   The UAC needs to compute the amount of payment it wishes to make by
   looking at the costs provided.  This is described in section 4.3.



Jennings & Jun          Expires January 9, 2005                 [Page 5]


Internet-Draft                SIP Payment                      July 2004


   The UAC is also responsible for computing when the payments it has
   made will run out and refreshing the call with additional payments
   before this happens.  For example, the UAC could initially decide to
   provide enough payment for 3 minutes.  After 2.5 minutes it might
   decide to pay for an additional 3 minutes.  It would do this by
   making a payment to the payment server for an additional 3 minutes'
   worth of resources and then sending the receipt with a SIP Re-INVITE
   or UPDATE transaction to the UAS.

4.2  UAS Behavior

   When the UAS receives a request it wishes to charge for, it should
   check whether the UAC has set the Accept header to include
   application/pay-offer.  If it has, it MAY reject the request with a
   402 and attach an application/pay-offer to the response.  The syntax
   of the pay-offer body is defined in section 7.  It needs to include
   lists of all the Payment Service Providers that are acceptable to the
   UAS and include the UAS's merchant-id at each one.  It also needs to
   form a list of currencies that are acceptable and what the cost in
   each one is.  The costs are described in section 4.3.

   When the UAS receives a request that contains an application/
   pay-receipt, it should check that this is valid, using these steps.
   First, make sure the amount of the payment is appropriate and if it
   wishes, check that this is a receipt for an Offer it made.  Second,
   check that the signature of the Receipt is valid.  Computing and
   verifying the signatures is described in section 7.4.  Third, check
   that the time between the payment and now is acceptably low.  This
   MUST be a configurable parameter and should default to 30 seconds.
   The UAS SHOULD support NTP RFC 1305 [6].  Fourth, the UAS MUST check
   that this receipt has not been previous used.  The limited time
   window limits the amount of state the UAS must keep to make this
   check.  If several UASs are using the same merchant-id at the Payment
   Service Provider, this replay detection needs to be done across all
   the UASs.  The OfferData can be used with opaque encrypted data to
   help do this.

   If the payment is accepted, it is Merchant's responsibility to end
   the call after the amount paid becomes inadequate to cover the
   session.  The UAS could use a mechanism like SIP session timer  to
   perform this function.  The UAC may send a Re-Invite or UPDATE with a
   new receipt for a payment to prolong the session.  The UAS is
   provisioned with the URL and account numbers of Payment Service
   Providers that are acceptable, along with the certificate containing
   the public key for the Payment Service Provider.  The expiry dates in
   this certificate MUST be checked and honored.





Jennings & Jun          Expires January 9, 2005                 [Page 6]


Internet-Draft                SIP Payment                      July 2004


4.3  Computing costs

   There are three types of costs: initial connection cost, cost per
   second, and cost per unit data.  All three costs are added together
   to form the total cost and are assumed to be zero if not specified.
   The cost of the first time unit block size worth of time and the
   first data unit block size of data are considered to be included in
   the initial connection cost.

   If a call costs 30 cents to connect and then 12 cents per minute and
   is billed in 15 second increments (rounded down), the cost would be
   set so that the currency was USD, the initial costs was 0.3, the cost
   per unit time is 0.04, and the time unit size is 15000.  If the time
   is to be rounded up, then some extra to cover the price of the first
   increment would be added to the connect cost.

4.4  Proxy Behavior

   In general a proxy does not do any special processing.  A proxy in
   the same domain as the UAS MAY perform the UAS functions on behalf of
   the UAS.  In this case the proxy performing this service would send
   the 402 to a request with no Receipt and would validate that the
   Receipt was acceptable before forwarding a request to the UAS.

4.5  Payment Service Provider Behavior

   The primary function of the Payment Service Provider is to receive
   Requests for Payments over HTTPS, transfer the currency from one
   account to another, and return a Receipt over HTTPS.

   A Payment Service Provider MUST support HTTPS.  When it receives a
   new connection it MUST present a valid TLS certificate that
   corresponds to its domain in the normal ways specified in RFC 2818
   [5].  The cipher suite negotiated must be encrypted and integrity
   protected because sensitive information is going to be transferred
   over this connection.

   When a Payment Service Provider receives a Request for Payment, it
   performs the following steps:
   1.  Verify that the customer-id corresponds to a valid account and
       that the authorization credential is correct for that account.
       If this fails, the connection should be terminated.  An empty or
       error response MAY be sent.
   2.  MUST validate that the currency is acceptable by the Merchant,
       that the Customer has appropriate funds, and that the merchant-id
       corresponds to a valid account.
   3.  MUST form the Receipt by setting the PaymentServiceProviderData,
       currency information, amount, and merchant-id.



Jennings & Jun          Expires January 9, 2005                 [Page 7]


Internet-Draft                SIP Payment                      July 2004


   4.  May set the PaymentData that the Payment Service Provider wishes
       to keep in the receipt.
   5.  MUST set the Date to the current time.
   6.  MUST compute and set the signature as described in section 7.4.
   7.  MUST transfer the money from the customer account to the vendor
       account.
   8.  MUST send the receipt as the HTTP response.

4.6   Customer and Merchant Enrollment and Transfer functions.

   The Payment Service Provider needs to provide a way for Customers and
   Merchants to enroll and transfer money in and out.  This is outside
   the scope of this document but could be done using web forms to
   enroll, get an account number, and provide the typical credit card
   mechanism to transfer money into the account.  Transfers out of the
   account could be done with the typical mechanism for transfers to
   bank accounts.

4.7  Account Names

   Note: Need to define they syntax for valid account id.  Email style
   account names (where the host part is not the same as the PSP domain)
   need to be allowed.

4.8   Merchant Fetching Public Key

   The Merchant needs to be able to fetch the Payment Service Provider's
   public key.  This is done by an HTTPS request to a URI provided by
   the Payment Service Provider.  TODO - add more detail on how to do
   this.  It is suggested that Payment Service Providers use signing
   certificates that are only valid for a short period of time - in the
   order of 1 to 7 days.

5.   SIP Extensions

5.1  Update response code 402

   This document updates 402 to mean that "A Payment is Required".
   Other mechanisms are used to indicate what type of payment is
   required.  In the case of this draft, a particular MIME body type
   indicates the type of payment required.  A single 402 may indicate
   that more than one type of payment is required.

6.  Example

   The following example shows a simple call where the caller is not
   recognized by the callee and the callee wants to charge 25 cents to
   the caller to help reduce SPAM.  The caller does not even bother to



Jennings & Jun          Expires January 9, 2005                 [Page 8]


Internet-Draft                SIP Payment                      July 2004


   actually collect this 25 cents but donates it their favorite charity.

      P                          C                         M
      |                          |  1) Call                |
      |                          |------------------------>|
      |                          |                         |
      |                          |  2) 402+Offer           |
      |  3) Request for Payment  |<------------------------|
      |<-------------------------|                         |
      |                          |                         |
      |  4) Receipt              |                         |
      |------------------------->|  5) Call+Receipt        |
      |                          |------------------------>|
      |                          |                         |
      |                          |  6) 200 OK              |
      |                          |<------------------------|
      |                          |                         |

   Still To Do - put in the rest of the messages for the example.

7.  Syntax

7.1  Offer

   The Offer contains a lists of costs and a list of Payment Service
   Providers.  The Customer can choose to pay any one of the provided
   costs and can choose any one of the Payment Service Providers to use,
   as long as the PSP supports the currency for the chosen cost.

   The bodies will be defined with XML Schemas.  The syntax is not
   specified yet, since we are just trying to get down the basic
   semantics.

   Notes on types: The types are all constructed so that they have a
   clear canonical form for computing the signatures and so that "|" can
   be used a separator between them.  Currency: if ISO, then 3 upper
   case letters.  Amount: decimal number.  If greater than or equal to
   1, no leading zeros; otherwise must start with 0.  No trailing 0.
   Must not have more than 8 digits to the left of the decimal point and
   not more than 6 digits to the right of the decimal point.  Vendor ID:
   base 10 integer, 64 bits, no leading zeros, 0 not valid.  Customer
   ID: base 10 integer, 64 bits, no leading zeros, 0 not valid.
   CustomerData: base64 encoded data.  MerchantData: base 64 encoded
   data.  PaymentData: base64 encoded data.







Jennings & Jun          Expires January 9, 2005                 [Page 9]


Internet-Draft                SIP Payment                      July 2004


   Offer
   * Cost List
     * Cost
       - currency name space
       - currency: 3 uppercase letters, ISO currency code
       - initial cost
       - cost per unit time
       - time unit size in milliseconds
       - cost per unit data
       - data unit size in octets
   * Payment Service Provider List
     * Paymnet Service Provider instance
       * PaymentServiceProviderData
         - id: domain name as a unique identifier for PSP
         - URL: general http URL to learn about the PSP
         - URL for RCP: URL to send the payment request
         - supported currencies: list of currencies
                                 supported by this PSP
                                 TODO TBD if this is needed
       - merchant-id: merchant's account # at this PSP
       - Accepted currencies: list of currencies
                              accepted through this PSP
       - PSP Bits: some data provided by PSP
   * OfferData
     - offer-id:
     - offerExpiry date: ISO format UTC
     - MerchantBits: some bits provided by vendor


7.2  Request for Payment

   Request for Payment
   * Payment Service Provider; copied from Offer
     - ...
     - ...
   * CustomerData
     - customer-id: customer's account # at this PSP
     - customer authorization: authorization credential
   * RequestData
     - currency
     - amount
   * OfferData; copied from Offer
     - ...
     - ...

   Note: Request for Payment will be an HTTP message, which has fewer
   size restrictions.  Therefore Customer does not need to try to reduce
   the size of the request.  Generating the Request for Payment is



Jennings & Jun          Expires January 9, 2005                [Page 10]


Internet-Draft                SIP Payment                      July 2004


   mostly copying chunks from Offer

7.3  Receipt

   Receipt
   - receipt-id: - 64bit integer
   - PaymentServiceProvider-id
   * OfferData; copied from RFP
     - ...
     - ...
   * ReceiptData
     - Date: ISO format UTC time
     - currency namespace
     - currency
     - amount
     - digest
     - hash
     * PaymentData (optional) - bits provided by PSP
   - SignatureData


7.4  Computing Signatures

   The signature in a receipt is computed across all the fields (other
   than the signature field itself, of course).  The fields are defined
   so they have a clear and simple canonical form.  A "|" separator is
   used between the fields.  RSA and SHA1 MUST be implemented for
   computing signatures.

7.5  Verifying Signature

   Merchant needs to verify the signature in the Receipt to determine
   what to do.  A suggested verification involves
   1.  Check ReceiptData.Date.  If too old, reject.
   2.  Check whether receipt-id has been accepted in a previous payment
       since the TTL used by the UAS.  If so, reject.  (See section 7.6
       on replay prevention)
   3.  Check whether Offer comes from this UAS.  If not, reject.
   4.  Perform RSA signature verification.  UAS chooses the public key
       based on PaymentServiceProvider-id

7.6  Replay Prevention

   Replay detection.  If OfferData.offer-id contains device-id, the
   scope of replay detection can be limited to a single device.  TODO -
   add more here.





Jennings & Jun          Expires January 9, 2005                [Page 11]


Internet-Draft                SIP Payment                      July 2004


8.  Usage Scenario

8.1  SPAM

   Payment at risk has been suggested as part of a possible solution to
   SPAM in VoIP systems [9].  The idea is that A would call B.  If A was
   not on B's white list, B could ask A to pay 5 cents for the privilege
   of ringing B's phone.  A could pay, and if B wished, B could refund
   the 5 cents by simply doing a second payment from B to A.  The
   payment service provider would collect two transaction fees in this
   scenario.

   Another possible scenario is that B simply requests that A donate 5
   cents to one of B's favorite charities and show B the receipt for
   this transaction.

8.2  Micro Billing

   In this scenario, a merchant running a PSTN GW may charge a customer
   5 cents to connect and operate for the first 90 seconds and then may
   charge 5 more cents for each additional minute.  The customer would
   initially transfer 5 cents and then, before the 90 seconds ran out,
   would transfer another 5 cents and keep on doing this until the call
   ended.

9.  Open Issues

   Would like to unify the body syntax so that it can also be used for
   Advice Of Charge information.

10.  Security Consideration

   This system has many limitations and is appropriate only for low
   value transactions.  Much more is needed in this section, but some
   topics to cover include:
      Certificate loss and revocation.
      Credential loss.
      Recommendation on low value transactions only.
      Loss of receipt in TCP transfer.
      Payment handler can cheat customer and vendor.
      Merchant can cheat customer.
      Things can simply get lost and cheat customer.
      Solutions like OSP are more complex but make these attacks less
      likely to be effective.

11.  IANA Registration

   TODO - Need MIME types for Offer, Payment, and Receipt.



Jennings & Jun          Expires January 9, 2005                [Page 12]


Internet-Draft                SIP Payment                      July 2004


   TODO - Update SIP 402 response code.

12.  References

12.1  Normative References

   [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [2]  International Organization for Standardization, "Codes for the
        representation of currencies and funds", ISO Standard 4217,
        2001.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [4]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
        2246, January 1999.

   [5]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

12.2  Informational References

   [6]  Mills, D., "Network Time Protocol (Version 3) Specification,
        Implementation", RFC 1305, March 1992.

   [7]  European Telecommunications Standards Institute,
        "Telecommunications and Internet Protocol Harmonization Over
        Networks (TIPHON); Open Settlement Protocol (OSP) for Inter-
        domain pricing, authorization, and usage exchange", ETSI
        Technical  Specification 101 321.

   [8]  Burdett, D., "Internet Open Trading Protocol - IOTP Version
        1.0", RFC 2801, April 2000.

   [9]  Rosenberg, J. and C. Jennings, "The Session Initiation Protocol
        (SIP) and Spam", July 2004.













Jennings & Jun          Expires January 9, 2005                [Page 13]


Internet-Draft                SIP Payment                      July 2004


Authors' Addresses

   Cullen Jennings
   Cisco Systems
   170 West Tasman Drive
   MS: SJC-21/2
   San Jose, CA  95134
   USA

   Phone: +1 408 902-3341
   EMail: fluffy@cisco.com


   Gyuchang Jun
   Bitpass, Inc.
   3300 Hillview Avenue, Suite 165
   Palo Alto, CA  94304
   USA

   Phone: 650 354-1882































Jennings & Jun          Expires January 9, 2005                [Page 14]


Internet-Draft                SIP Payment                      July 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Jennings & Jun          Expires January 9, 2005                [Page 15]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/