Re: [martini] #36: Reg-event package and individual extension state (section 7.2.2)

["martini issue tracker" <[e-mail]>]

#36: Reg-event package and individual extension state (section 7.2.2)
------------------------------------------------+---------------------------
 Reporter:  john.elwell@…                       |        Owner:            
     Type:  defect                              |       Status:  closed    
 Priority:  minor                               |    Milestone:  milestone1
Component:  gin                                 |      Version:  1.0       
 Severity:  Active WG Document                  |   Resolution:  fixed     
 Keywords:                                      |  
------------------------------------------------+---------------------------
Changes (by bernard_aboba@…):

  * status:  reopened => closed
  * version:  => 1.0
  * resolution:  => fixed


Comment:

 Proposed fix:
 http://www.ietf.org/mail-archive/web/martini/current/msg01716.html

 After giving things some thought and reading through the 'reg' event
 package RFC, I think things will only really work if the SIP-PBX puts the
 public (i.e. SSP) AOR into the registration document. I propose the
 following text (which will appear in the next version of GIN unless there
 is a constructive counter-proposal):

    When a SIP-PBX receives a registration event subscription addressed
    to an AOR that has been registered using the bulk registration
    mechanism described in this document, then the resulting registration
    information documents SHOULD contain an 'aor' attribute in its
 <registration/> element that corresponds to the AOR at the SSP.

       For example, consider a SIP-PBX that has registered with an SSP
       that has a domain of "ssp.example.com" The SIP-PBX used a contact
       of "sip:198.51.100.3:5060;bnc".  After such registration is
       complete, a registration event subscription arriving at the SSP
       with a Request-URI of "sip:[phone] at ssp.example.com" will be
       re-targeted to the SIP-PBX, with a Request-URI of
       "sip:[phone] at 198.51.100.3:5060".  The resulting registration
       document created by the SIP-PBX would contain a <registration/>
       element with an "aor" attribute of
       "sip:[phone] at ssp.example.com".

       This behavior ensures that subscribers external to the system (and
       unaware of GIN procedures) will be able to find the relevant
       information in the registration document (since they will be
       looking for the publicly-visible AOR, not the address used for
       sending information from the SSP to the SIP-PBX).


 Also, based on Paul's comments during Interim V regarding the potential
 ability for SSPs to form back-end subscriptions to SIP-PBXes for
 registration state, I propose loosening up the normative requirement about
 passing through reg event SUBSCRIBEs; everything after the word "unless"
 is new:

    If the SSP receives a SUBSCRIBE request for the registration event
    package with a Request-URI that indicates a contact registered via
    the "Bulk Number Contact" mechanism defined in this document, then
    the SSP MUST proxy that SUBSCRIBE to the SIP-PBX in the same way that
    is would proxy an INVITE bound for that AOR, unless the SSP has and
    can maintain a copy of complete, accurate, and up-to-date information
    from the SIP-PBX (e.g., through an active back-end subscription).


 Again, this text will appear in the next version of GIN unless there is a
 constructive counter-proposal.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/36#comment:3>
martini <http://tools.ietf.org/martini/>