Document Sample
ppt---Index-of-apache2-default Powered By Docstoc
					SIP/SIPPING WG Interim Meeting
              May 6-7, 2002

 Generic Request History
Capability - Requirements

  Mary Barnes (
  Mark Watson (
      Cullen Jennings (
    Jon Peterson (
                      Changes in -01
• Examples (next charts) added to the appendix
• Updated requirements:
      • Req 4.2 clarified (URI from which request was retargetted)
      • Req 4.3 (Identity which modified) and Req 9 (completeness)
• Added a section that highlights additional
  considerations introduced by specific
      • Clarified that the optionality of Request History would likely be
        determined by local policy
      • Recommendation that “internal retargetting” also be captured.
      • Proposal to use the Reason header to capture the “Reason” for

05/07/2002            draft-watson-sipping-request-history-01               2
General problem:
   1) Information is lost as the INVITE is retargetted
   2) Caller is unaware of where the call is going
   3) Callee is unaware of where call has been
                                                 5      INVITE
             1    INVITE
                                                        R-Uri: <D>
                  R-Uri: <B>
                                                        To: <B>
                  To: <B>
                  From: <A>                             From: <A>
       A                         Proxy1                                    Proxy2
                                                                                                8     INVITE
                                                                                                      R-Uri: <E>
                     2   INVITE                       302 <D>        6   INVITE                       To: <B>
                                           3                                          7
                         R-Uri: <B>                                      R-Uri: <D>                   From: <A>
                         To: <B>           INVITE                        To: <B>          Busy Here
                         From: <A>         R-Uri: <C>                    From: <A>
                                           To: <B>
                                           From: <A>

                                      B                      C                        D                        E
      •    Proxy2 does not know that <C> was tried
      •    E does not know that <C> or <D> was tried
      •    A does not know that <C> or <D> were tried
      •    A does not know <B> is unavailable until <E> alerting
     05/07/2002                       draft-watson-sipping-request-history-01                                      3
Example 1:
• UA 1 sends a call to proxy 1 which sequentially
  tries several places before retargetting the call to a
  second proxy which unfortunately tries many of
  the same places.

             1                   5
 UA1             Proxy1                        Proxy2

                                     4       6
                                                       7      8
                  2         3

                  UA2                UA3                UA4       UA5
05/07/2002        draft-watson-sipping-request-history-01           4
Example 2:
• UA 1 called UA A which had been forwarded to
  UA B which forwarded to a UA VM (voicemail
  server) which needs information (e.g. reason the
  call was retargetted) to make a policy decision
  about what mailbox to use, which greeting to play

             1 (INV)                   6 (INV)
  UA 1                 Proxy                              UA VM

             3 (INV)     4 (302) 5 (INV)

                       UA A                  UA B

05/07/2002              draft-watson-sipping-request-history-01   5
Summary of proposed requirements:

• Record old URI in request when „retargetting‟
  (changing of Request-URI) occurs.
• Record new URI to maintain „history‟ for
• Inform UAC when retargetting occurs
• Provide reason for retargetting.
• Chronological ordering of the information to allow
  the capture of each occurrence of retargetting.

05/07/2002    draft-watson-sipping-request-history-01   6
Questions for SIP/SIPPING Interim?
• Is the general problem (information loss)
  worth solving ? Hum vote IETF-53 indicated “yes”
• Are the requirements in draft-watson-
  sipping-req-history sufficient to solve this
  problem ?

05/07/2002     draft-watson-sipping-request-history-01   7
If the answers are “Yes”
• Propose the following:
      – Evaluation of existing SIP headers that might
        be suitable analyzed against the requirements:
             • Remote Party ID
             • Cookie
             • State
      – If these are deemed unsuitable:
             • Propose the definition of a new SIP header.

05/07/2002            draft-watson-sipping-request-history-01   8
Existing SIP Headers
• Remote-Party-Id (RPI)
              Advantages:
                  Can leverage the existing privacy framework (draft-ietf-sip-privacy-04.txt)
                  Stack multiple headers for multiple redirections
                  Extensible
              Disadvantages:
                  Recent updates to the existing privacy framework restrict the applicability of this
                   header so it‟s not really a generic header.

• Cookie
              Advantages:
                  Flexible and extensible
              Disadvantages:
                  Generally used for keeping persistent state information across sessions. May not
                   be a match here.

• State
              Advantages:
                  Existing SIP header used for carrying state information between the Proxies and
                   the endpoints
              Disadvantages:
                  Needs behavior change in Proxies and UA‟s in treating this header.

05/07/2002                 draft-watson-sipping-request-history-01                                       9
Previous New SIP Headers                                        Proposed
• “Diversion” Header
              Advantages:
                  Captures “retarget” information.
              Disadvantages:
                  Calling party is not identified as being able to be notified of
                   “retargetting” information.
                  Doesn‟t capture the new URI (which allows the entire history to be
                   captured without depending upon information derived from other
                   instances of “Contacts-Tried”)

• “Contacts-Tried” Header
              Advantages:
                  Contains a list of contacts tried, reason and status.
              Disadvantages:
                  Doesn‟t capture the new URI (which allows the entire history to be
                   captured without depending upon information derived from other
                   instances of “Contacts-Tried”)
                  Calling party is not identified as being able to be notified of “Contacts-
                   Tried” information.
05/07/2002                draft-watson-sipping-request-history-01                          10
Propose the definition of a new header

 • “Request-History” Header
              Advantages:
                  Captures “retarget” information.
                  Calling party is able to be notified of “retargetting” information.
                  Captures the new URI

05/07/2002                draft-watson-sipping-request-history-01                        11

Shared By:
Tags: ppt--, -Inde
Description: ppt---Index-of-apache2-default