Re: [martini] FW: GIN: 'reg' event package proposal

[Martien Huysmans <[e-mail]>]

Any comments to the questions below?

Regards Martien

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Martien Huysmans
Sent: Monday, June 28, 2010 3:04 PM
To: [e-mail]
Subject: [martini] FW: GIN: 'reg' event package proposal

Forgot to include [e-mail] in the To.

-----Original Message-----
From: Martien Huysmans
Sent: Monday, June 28, 2010 2:46 PM
To: 'Adam Roach'
Subject: RE: [martini] GIN: 'reg' event package proposal

Adam

Assume that the pbx has a user, say sip:[e-mail] with corresponding SSP identity: sip:[e-mail].
Then I guess that it's is upto the SIP-PBX to include both, if both are publicly-visible?

Would the procedure below imply that a SIP-PBX could provide a different replies to a SUBSCRIBE for regvent depending on the RURI:
- SUBSCRIBE sip:[e-mail] as described below
- SUBSCRIBE sip:[e-mail] with all AOR's included ?

Do you see a similar rule for the Contact's included in the registration document?

Regards Martien

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Adam Roach
Sent: Saturday, June 19, 2010 1:03 AM
To: [e-mail]
Subject: [martini] GIN: 'reg' event package proposal

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:[e-mail]" will be
       re-targeted to the SIP-PBX, with a Request-URI of
       "sip:[phone]@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:[e-mail]".

       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.

/a
_______________________________________________
martini mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/martini
_______________________________________________
martini mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/martini