[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
                  Analysis of TISPAN req. to SIP   June 2005


   Sipping Working Group
   Internet Draft                                         Roland Jesske
   Expires: December 28, 2005                          Denis Alexeitsev
                                                       Deutsche Telekom
                                                   Miguel Garcia-Martin
                                                                  Nokia
                                                              June 2005





       Analysis of the Input Requirements for the Session Initiation
       Protocol (SIP) in support for the European Telecommunications
   Standards Institute (ETSI) Next Generation Networks (NGN) simulation
                                 services
                        draft-jesske-sipping-tispan-analysis-00.txt


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 November 24, 2005.

   Copyright Notice

   Copyright (C) The Internet Society (2005).


Abstract



Jesske                 Expires -  December 2005               [Page 1]


                  Analysis of TISPAN req. to SIP   June 2005


   This document analyzes the requirements generated by ETSI to support
   NGN simulation services implemented with SIP. The document analyzes
   standard solutions that can meet the requirements. Where a standard
   solution is not available, the document proposes one or more
   solutions. The aim is to provoke discussion within the Internet
   community and get early feedback.


Table of Contents

   1. Overview
   2. Analysis of the TISPAN Simulation Services requirements
      2.1 General Requirements[REQ-GEN-1]
      2.2 Anonymous Communication Rejection (ACR)[ACR-REQ-1] and [ACR-
   REQ-2]
      2.3 Terminating Indication Presentation (TIP)/Terminating
   Indication Restriction (TIR). [REQ-TIP-1] and [REQ-TIP-2]
      2.4 Advice of Charge (AOC) [REQ-AoC-1] and [REQ-AoC-2]
      2.5 Communication Completion on Busy Subscriber (CCBS) [REQ-CCBS-
   1]- [REQ-CCBS4]
      2.6 Communication Completion on no Reply (CCNR) [REQ-CCNR-1]-
   [REQ-CCBNR4]
      2.7 Malicious Communication IDentification (MCID) [REQ-MCID-1] and
   [REQ-MCID-2]
      2.8 Communication Waiting (CW) [REQ-7] [REQ-CW-1] and [REQ-CW-2]
      2.9 Communication Diversion (CDIV) [REQ-CDIV-1] and [REQ-CDIV-4]
      2.10 [REQ-CAT-1] and [REQ-CAT-2]
   3. Security Considerations
   4. IANA Considerations


1. Overview

   This document is a companion document of the Internet Draft
   "Input Requirements for the Session Initiation Protocol (SIP) in
   support for the European Telecommunications Standards Institute
   (ETSI) Next Generation Network (NGN) simulation services" [3]. We
   analyze each requirement trying to find an available standard
   solution that meets the requirement. When such solution is not known,
   we analyze different alternatives that will meet the requirement. The
   document's intention is to provoke discussion in the Internet
   community in order to find suitable mechanisms that guarantee the
   implementation of the requirements within the ETSI NGN timeframe.

2 Analysis of the TISPAN Simulation Services reqirements

   The following section could be seen as collected thoughts what
   possibilities are given to fulfill the above mentioned requirements.


Jesske                 Expires -  December 2005               [Page 2]


                  Analysis of TISPAN req. to SIP   June 2005


   Some of these ideas are still under discussion in ETSI and thus, do
   not even represent a firm proposal, but just a collection of
   alternatives that require further exploration.


2.1 General Requirements[REQ-GEN-1]

   This requirement, since it is generally applicable to all the
   requirements, does not require a particular behavior. However,
   solutions that meet other requirements should also meet the
   constraint of seamlessly interwork with a similar service in the
   PSTN.

2.2 Anonymus Communication Rejection (ACR)[ACR-REQ-1] and [ACR-REQ-2]

   Requirement [ACR-REQ-1] requires informing the caller that her call
   has been rejected due to anonymity. We thought that an application
   server that implements the ACR service can either send an instant
   message to the caller (if supported) or divert the call to an
   announcement player that plays the appropriate audio message,
   however, this will be hard to be processed by an automata or a PSTN
   gateway. For example, in a PSTN originated call the PSTN should
   indicated an appropriate Release Cause (cause 24) due to interaction
   with the ACR service. Thus, any solution based on these two proposals
   would make difficult to meet REQ-GEN-1. The Release Causes are
   described within ETSI EN300 485 [13]

   A more sophisticated solution proposes to add a Reason header with an
   appropriate Release Cause 24 as described in ETSI EN300 485 [13] to a
   603 Decline response. This will allow interworking with the PSTN. Yet
   another alternative is to create a new response code, but we believe
   it is not really necessary to go into that solution.

   As the current Reason header extension header is limited to requests,
   some extension is needed to state that the Reason header is valid for
   either the 603 (Decline) response, or some other status code as
   determined by this discussion.

   Requirement [ACR-REQ-2] reads about allowing certain authorized
   callers to bypass the ACR service of a given callee. For that we
   envision that an application or SIP proxy server that has access to
   the caller's user profile is able to add indicate in SIP that the
   user is authorized to bypass a potential callee's ACR service. We
   propose to add a new P-ACR header field that proxies or application
   servers can insert. This header would be subject to the same security
   concerns and trusted domain considerations as the P-Asserted-Identity
   header field [8].

2.2.1 The P-ACR header field


Jesske                 Expires -  December 2005               [Page 3]


                  Analysis of TISPAN req. to SIP   June 2005


   In support for the ACR service [REQ-ACR-2], there is a need to
   indicate that in some circumstances the ACR service provided towards
   the terminating UE should not apply.

   One of these cases is when the originating user has requested privacy
   of his asserted identity, but because the user belongs to an
   authorized group (e.g., policeman), all SIP request should go through
   to the called UA, no matter whether the called user has activated ACR
   or not.

   In another scenario, a PSTN originated call does not deliver the
   asserted identity of the called party (e.g., if the call is
   originated in an analogue switch). In this case the PSTN gateway is
   not able to provide an asserted identity of the calling party. If the
   call is routed to a user who has the ACR service activated, the call
   shouldn't be rejected due to ACR.

   To tackle this problem we suggest creating a new P-ACR header, which
   can be populated by a trusted entity (e.g., an Application Server or
   Media Gateway Control Function). The contents of the header will
   indicate that willingness of bypassing a potential ACR service in the
   called party side, and the motivation for it.

   It is the same restrictions for the P-ACR as in RFC3325 for the P-
   Asserted-ID described must apply.

   Proposed syntax for this header:

          P-ACR          = "P-ACR" HCOLON p-acr-spec
                           *(COMMA p-acr-spec)
          p-acr-spec     = "bypass" *(SEMI due-to-param)
          due-to-param   = "due-to" EQUAL reason-token
          reason-token   = "interworking" / "is-authorized" / "network"/
                            token

   Example: P-ACR = bypass;due-to=is-authorized

      Header field         where   proxy   ACK  BYE  CAN  INV  OPT  REG
      ------------         -----   -----   ---  ---  ---  ---  ---  ---
      P-ACR                         adr     -    -    -    o    -    -


                                           SUB  NOT  REF  INF  UPD  PRA
                                           ---  ---  ---  ---  ---  ---
                                            o    -    o    -    -    -


                                           MESSAGE  PUBLISH
                                             ---      ---


Jesske                 Expires -  December 2005               [Page 4]


                  Analysis of TISPAN req. to SIP   June 2005


                                              o        o

   The draft-ietf-sip-identity was not considered due to the fact that
   this draft recommends practices and conventions for identifying end
   users in SIP messages, and proposes a way to distribute
   cryptographically-secure authenticated identities. This is only for
   Requests specified. The P-ACR is especially used for indicating
   bypass mechanisms for ACR and the indication how P-Asserted-Identity
   was set.

    2.3 Terminating Indication Presentation (TIP)/Terminating Indication
    Restriction (TIR). [REQ-TIP-1] and [REQ-TIP-2]

   The implementation of these requirements need some header to convey
   the callee's URI, which might be different from the To header field
   or Request-URI, due to, e.g., redirections, call transfer, usage of
   PBX extensions, etc.

   We believe that the P-Asserted-Identity [8] header field inserted in
   responses meets these requirements.
   An additional Identity header is needed that is send from the
   connected SIP user like the From header from the originating user.

2.3.1 The P-Additional-Identity Header

   The P-Additional-Identity header field is used among SIP entities
   (typically intermediaries) to carry the identity of the user
   sending a SIP response as it was not verified by authentication.

   This additional header is needed for example a user calling a PBX
   desk (e.g., +49 6151 83 0000 for Deutsche Telekom in Darmstadt) will
   be forwarded to an Extension (e.g., +49 6151 83 5940 for Roland
   Jesske). It is required that the caller gets the latter identity,
   which is allocated to the callee.


      PAdditionalID = "P-Additional-Identity" HCOLON PAdditionalID-value
                      *(COMMA PAdditionalID-value)
      PAdditionalID-value = name-addr / addr-spec

   A P-Additional-Identity header field value MUST consist of exactly
   one name-addr or addr-spec.  There may be one or two P-Additional-
   Identity values.  If there is one value, it MUST be a sip, sips, or
   tel URI.
   If there are two values, one value MUST be a sip or sips URI and the
   other MUST be a tel URI.  It is worth noting that proxies can (and
   will) add and remove this header field.

   This document adds the following entry to Table 2 of [1]:


Jesske                 Expires -  December 2005               [Page 5]


                  Analysis of TISPAN req. to SIP   June 2005



      Header field         where   proxy   ACK  BYE  CAN  INV  OPT  REG
      ------------         -----   -----   ---  ---  ---  ---  ---  ---
      P-Additional-Identity  r      adr     -    o    -    o    o    -


                                           SUB  NOT  REF  INF  UPD  PRA
                                           ---  ---  ---  ---  ---  ---
                                            o    o    o    -    -    -

                                           MESSAGE  PUBLISH
                                             ---      ---
                                              o        o


   Note: Here is also an ongoing discussion if a new header is needed or
   if a existing header could be used to identify the ôrealö connected
   user. The Contact or Reply-to header were identified as not usable.

2.4 Advice of Charge (AOC) [REQ-AoC-1] and [REQ-AoC-2]

   The Advice of Charge simulation service requires a caller to give an
   indication to the network that he wants to receive advice of charge
   information for a given communication (e.g., session, subscription,
   instant message, etc.). A mechanism to invoke the service based on a
   SIP-event base subscription and notification has been analyzed.
   However, this solution will introduce a synchronization problem, due
   to indicating the request for the service out-of-band. The basic
   problem is how to identify the SIP request for which the advice
   should be provided prior to sending the request, when such request
   has not even been created.

   We propose, though, that the SIP request for which the Advice of
   Service information is requested is complemented with a new header
   that invokes the service. Once the service is properly invoked, there
   are a number of available mechanisms to deliver the information to
   the user, including but not restricted to, audio visual
   announcements, instant message, etc.

   A detailed proposal for a new P-AoC header field is described in
   draft-garcia-sipping-etsi-ngn-p-headers-00 [7].


2.5 Communication Completion on Busy Subscriber (CCBS) [REQ-CCBS-1]to
    [REQ-CCBS4]
   Discussion in ETSI TISPAN are leaning towards a segmented
   implementation of the CCBS service, where there is an application
   server which is serving the caller, and another application server
   which serving the callee. The main role of application servers is to


Jesske                 Expires -  December 2005               [Page 6]


                  Analysis of TISPAN req. to SIP   June 2005


   provide queue management. This is based on the modelling in the ISDN
   stage 2 and operates in this manner to allow interworking with the
   related ISDN service through a SIP/PSTN gateway.

   We model the actual implementation of the CCBS service according to
   the following:

   - When the AS of the callee detects that the callee is busy and that
   the callee supports the dialog event package [9], it forwards the
   busy response to the AS of the caller with an indication that the
   CCBS service is possible (i.e. queuing capabilities, and dialog event
   are supported, REQ-CCBS-1 and REQ-CCBS-2).
   - Upon receipt of this indication, the caller is offered to activate
   the CCBS service (e.g. the AS of the caller plays an announcement
   with DTMF collection, etc).
   - If the caller accepts the service activation, the AS of the caller
   subscribes to the CCBS service (e.g. subscribes to the CCBS queue of
   the callee to the dialog status of this callee, REQ-CCBS-2).
   - Upon receipt of the CCBS subscription request, the AS of the caller
   confirms that CCBS monitoring has started,
   - the AS of the callee then subscribes to the dialog event [9] of the
   callee,
   - Upon receipt of a notification that the callee is free, the AS of
   the callee, notifies the AS of the caller.

   - The AS of the caller sets-up the CCBS call using either a 3rd party
   control mechanism of a Refer with an indication that this is a CCBS
   call (REQ-CCBS-4).

   In order to provide compatibility with terminals that implement the
   dialog event package, subscriptions that may originate or terminate
   in a terminal will be implemented according to the dialog event
   package [9].

   Subscriptions not involving terminals (i.e., such as the
   subscriptions from one application server to another one) need to be
   complemented with additional information (REQ-CCBS-3). It is proposed
   to define a new "CCBS" event package for backwards compatibility
   purposes. The main difference between the "CCBS" event package and
   the ôdialogö event package lies in the way subscriptions and
   notifications are handled, there is no need to change the contents of
   the XML documents exchanged therein. Consequently, the CCBS event
   package notifications should contain a dialog information document as
   described in [9].  This allows to "tunnel" dialog information
   documents contained in dialog package notifications originated by
   endpoints into CCBS package notifications sent by application
   servers. The additional information to the dialog event package for
   providing queues management and concurs to build a subscription
   target is as follows:


Jesske                 Expires -  December 2005               [Page 7]


                  Analysis of TISPAN req. to SIP   June 2005



   queue: this information is needed for the application server to know
   whether to insert this new subscription in the queue or not. We
   suggest to add a new "queue" parameter to the "dialog" Event header
   field value. Possible values are "true","false", "suspend" (to
   suspend its place in queue), "resume" to resume its place in queue.

   Hence, the CCBS Event: header will look like, for example

   To start CCBS subscription:
      Event: ccbs;queue=true;caller=sip:+390112285111@example.com

   To suspend CCBS service (for instance, if caller becomes busy):
      Event: ccbs;queue=suspend;caller= sip:+390112285111@example.com

   To resume CCBS service:
      Event: ccbs;queue=resume;caller= sip:+390112285111@example.com

   A value of "ccbs" or "dialog" in the 486 Busy Here response will
   indicate the URI where the subscription could be made. This URI
   could, e.g., a GRUU. Additionally, the presence in a 486 Busy Here
   response of an Allow-Events header field with the value "CCBS" would
   help to determine the support for the service. However, RFC 3265 [11]
   seems to indicate that the Allow-Evens header is only meaningful in
   requests and 200 or 489 responses.

   Implementation of REQ-CCBS-3 requires that the second time that the
   caller sends the INVITE request to the callee, as a result of an
   indication that the callee is not busy any longer, the INVITE request
   is marked with an flag indicating that the INVITE is the result of
   CCBS service. It is proposed that a Call-Info header field is
   extended with a new value of the "purpose" parameter. Hence, at the
   time of the CCBS call, the AS can insert the Call-Info: header into
   the INVITE message directed to user B when triggering the 3rd party
   call, or instruct the terminal to do so in the Refer-To: header
   inserting the æCall-Info:Æ header as a URL header (after the æ?Æ
   character).

   Note: With regard to CCBS the discussion is ongoing what kind of
   solution could be taken. If a new Event Package is needed or if the
   extension of the existing dialog event package is good enough for
   CCBS.

2.6 Communication Completion on no Reply (CCNR) [REQ-CCNR-1] to
    [REQ-CCNR-4]






Jesske                 Expires -  December 2005               [Page 8]


                  Analysis of TISPAN req. to SIP   June 2005


   The implementation of the CCNR service does not require any extra
   implementation beyond the solutions proposed for implementing the
   CCBS service.


2.7 Malicious Communication IDentification (MCID) [REQ-MCID-1] and [REQ-
MCID-2]

   The implementation of the MCID service suggests to split the solution
   into the mechanism whereby a callee can indicate to an application
   server that he suspects a call is malicious [REQ-MCID-1], from the
   mechanism whereby an application server acquires the caller's
   identity if not present in the SIP request [REQ-MCID-2].

   A possible solution for implementing REQ-MCID-1 consists of the user
   subscribing to a new event package. The application server will act
   as a notifier. Since the user does not need to receive any
   information, other than a message indicating whether the service has
   been successfully activated or not, we propose to do a fetch
   operation (as per RFC 3265 [11]) with the new event package.

   We propose, therefore, a new event "mcid" event package. The value is
   accompanied by package parameters indicating the call to be
   identified (e.g., by its from-tag, call-id, and to-tag (if
   available)). The event package itself should contain a simple
   indication of the acceptance or not of the service.

   To implement REQ-MCID-2 we envision that all SIP requests addressed
   to the user will be routed through the MCID application server. The
   application server will analyze all SIP requests. Two possbilities
   might take place: the SIP request contains trusted identity
   information (e.g., a trusted P-Asserted-Identity [8] header field, or
   an Identity [12] header field); or such identity is not present in
   the request, in which case, it might be still available upon request.
   This is the sometimes the case when a call is originated in the PSTN,
   because sometimes the calling party number is only available upon
   request.

   To meet this requirement and be able to request the identity of the
   originator, we propose a SIP event package for requesting identity
   information. In most cases this will not be used, but in cases of
   interworking with the PSTN, the PSTN gateway will receive a SUBSCRIBE
   request for the new event package, will do the PSTN operations to
   retrive the calling party number, and will provide the appropriate
   notification to the subscriber (the application server).


2.8 Communication Waiting (CW) [REQ-CW-1] and [REQ-CW-2]



Jesske                 Expires -  December 2005               [Page 9]


                  Analysis of TISPAN req. to SIP   June 2005


   A solution that meets REQ-CW-1 suggests to use send an instant
   message indicating the ser the relevant parameters of the waiting
   call.

   To implement REQ-CW-2 we suggest to use a 182 Queue response until
   the callee accepts the incoming session.

2.9 Communication Diversion (CDIV) [REQ-CDIV-1] to [REQ-CDIV-4]

   For supporting CDIV service we envision the usage of draft-ietf-sip-
   history-info-06 [6] and draft-elwell-sipping-redirection-reason-01
   [2].We therefore request the adoption of draft-elwell-sipping-
   redirection-reason as a working group charter item.

2.10 [REQ-CAT-1] and [REQ-CAT-2]

   To support REQ-CAT-1 and REQ-CAT-2 we propose that, a PSTN Gateway
   (UA) or SIP proxy that has knowledge of the user's category inserts a
   P-Caller-Category header field categorizing the caller.

   Sometimes the category of the caller is determined to be "operator".
   In such case, the presence of the Accept-Language header field can be
   combined to determine the language of the operator.

   Use of this mechanism in any other context has serious security
   shortcomings, namely that there is absolutely no guarantee that the
   information has not been modified, or was even correct in the first
   place.

   The proposed syntax for this header:

          P-Caller-Category   = "P-Caller-Category " HCOLON p-cat-spec
                                 *(COMMA p-cat-spec)
          p-cat-spec     = "operator" / "subscriber" / "data" /
                           "test" / "payphone" / "mobile" / token

   Example: P-Caller-Category = "payphone"

   An other possibility is to use the solution described within draft-
   mahy-iptel-cpc-00 [14]. This solution was dicussed in the past within
   IPTEL but not follwed on

   Question is which would be the appropriate way to follow.


4. Security Considerations





Jesske                 Expires -  December 2005              [Page 10]


                  Analysis of TISPAN req. to SIP   June 2005


   The requirements in this document are intended to result in a
   mechanism with applicability for ETSI NGN and NOT for the general
   Internet.

   Use of this mechanism in any other context has serious security
   shortcomings, namely that there is absolutely no guarantee that the
   information has not been modified, or was even correct in the first
   place.


5. IANA Considerations

   This document discusses implementation possibilities and does not
   pretend to be a firm proposal for the implementation of any of the
   solutions. Therefore, this document does not provide any action to
   IANA.

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] Elwell, J., "SIP Reason header extension for indicating
      redirection reasons", draft-elwell-sipping-redirection-reason-
      02.txt (work in progress), June 2005.

   [3] Jesske, R., Alexeitsev, D., Garcia-Martin, M. "Input Requirements
      for the Session Initiation Protocol (SIP) in support for the
      European Telecommunications Standards Institute (ETSI) Next
      Generation Network (NGN) simulation services", draft-jesske-
      sipping-tispan-requirements-01.txt (work in progress), June 2005.

   [4] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP
      and SDP".

   [5] Peterson, J., "A Privacy Mechanism for the Session Initiation
       Protocol (SIP)", RFC 3323, November 2002.

   [6] Barnes, M., "An Extension to the Session Initiation Protocol for
      Request History Information", draft-ietf-sip-history-info-06.txt
      (work in progress), January 2005.

   [7] Garcia-Martin, M. "Private Header (P-Header) Extensions to the
      Session Initiation Protocol(SIP) in support of the European
      Telecommunications Standards Institute (ETSI) Next Generation
      Networks (NGN)", draft-garcia-sipping-etsi-ngn-p-headers-00.txt
      (work in progress), June 2005.



Jesske                 Expires -  December 2005              [Page 11]


                  Analysis of TISPAN req. to SIP   June 2005


   [8] Jennings C., Peterson J., and Watson M. "Private Extensions to
      the Session Initiation Protocol (SIP) for Asserted Identity within
      Trusted Networks", RFC 3325, November 2002.

   [9] Rosenberg, J., Schulzrinne, H., Mahy, R"An INVITE Initiated
      Dialog Event Package for the Session Initiation Protocol (SIP)",
      draft-ietf-sipping-dialog-package-06.txt (work in progress), April
      2005.

   [10] Rosenberg, J. "Obtaining and Using Globally Routable User Agent
      (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-
      ietf-sip-gruu-03 (work in progress), February 2005.

   [11] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
      Notification", RFC 3265, June 2002.

   [12] Peterson, J., Jennings, C. "Enhancements for Authenticated
      Identity Management in the Session Initiation Protocol (SIP)",
      draft-ietf-sip-identity-05.txt (work in progress), March 2005.

   [13]  ETSI EN 300 485: "Integrated Services Digital Network (ISDN);
      Definition and usage of cause and location in Digital Subscriber
      Signalling System No. one (DSS1) and Signalling System No. 7 (SS7)
      ISDN User Part (ISUP) [ITU-T Recommendation Q.850 (1998) with
      addendum modified]".

   [14]  R. Mahy "The Calling Party's Category tel URI Parameter" draft-
      mahy-iptel-cpc-00, June 2003

Contributors



   Keith Drage
   Lucent Technologies
   SN5 6PP SWINDON
   United Kingdom
   Phone: +44 1793 897312
   Email: drage@lucent.com

   Sebastien Garcin
   France Telecom
   38-40, Rue du General Leclerc
   92130 Issy Les Moulineaux
   France


Acknowledgments



Jesske                 Expires -  December 2005              [Page 12]


                  Analysis of TISPAN req. to SIP   June 2005


   The authors would like to thank the participants of the ETSI TISPAN
   WG3 for the comments and initial review of this document.


Author's Addresses

   Roland Jesske
   Deutsche Telekom
   Am Kavalleriesand 3
   64307 Darmstadt
   Germany
   Phone: +496151835940
   Email: r.jesske@t-com.net

   Denis Alexeitsev
   Deutsche Telekom
   Am Kavalleriesand 3
   64307 Darmstadt
   Germany
   Phone: +496151832130
   Email: d.alexeitsev@t-com.net

   Miguel A. Garcia-Martin
   Nokia
   P.O. Box 407
   NOKIA GROUP, FIN 00045
   Finland
   EMail: miguel.an.garcia@nokia.com

Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   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.

   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.

   Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to


Jesske                 Expires -  December 2005              [Page 13]


                  Analysis of TISPAN req. to SIP   June 2005


   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.

Acknowledgement

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



























Jesske                 Expires -  December 2005              [Page 14]