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

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 3 May 2010 17:36:00 +0200

Typical use of this reg-event package seems to be that the UA (PBX)
can be notified that it is being deregistered by the SSP. For example
for reauthentication purposes.

So I do think you have a point but for other reasons then you give ;-)

/Hans Erik van Elburg

On Fri, Apr 23, 2010 at 5:16 PM, Hadriel Kaplan <[email-masked]> wrote:
>
> Huh.  This is an interesting issue, because I think it means the bulk registration is not just a short-hand for multiple unique registrations.
>
> What I mean is that I was assuming the bulk REGISTER was just a collapsed/compressed form of separate Registrations, and that it really does register contacts for separate AoRs, which really are the SSP's AoRs, as in "sip:[email-masked]".  And the SSP Registrar really does have registration state for that AoR: one that has the expanded contact of the PBX, an expires of the bnc REGISTER, etc.
>
> If that's true, I don't see why a SUBSCRIBE to "sip:[email-masked]" for reg-event should be automatically contact-routed to the PBX.  It wouldn't have been if the registered AoR was "sip:[email-masked]", for example.
>
> If the subscriber is asking for the reg-event state of "sip:[email-masked]", then that's what it should get.  It may, upon learning the registered contact, send another SUBSCRIBE to the contact itself, which would go to the PBX, but that's a different target.
>
> -hadriel
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of martini issue tracker
>> Sent: Monday, April 19, 2010 6:13 PM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: Re: [martini] #36: Reg-event package and individual extension
>> state (section 7.2.2)
>>
>> #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:
>>  Severity:  Active WG Document                  |   Resolution:  fixed
>>  Keywords:                                      |
>> ------------------------------------------------+-------------------------
>> --
>> Changes (by adam@...):
>>
>>   * status:  new => closed
>>   * resolution:  => fixed
>>
>>
>> Comment:
>>
>>  This is mostly correct. There's nothing that says that the SSP can't, for
>>  example, act as a presence server for the users behind the PBX. That
>> would
>>  be something that the SSP and PBX owners would need to agree on, of
>>  course. However, you are correct in pointing out that the behavior in
>>  7.2.2 is a reiteration of the generally expected behavior described in
>>  section 6. This will be clarified as follows:
>>
>>            As described in section 6, the
>>            SSP will generally retarget all requests addressed to
>>            a phone number owned by a PBX to that PBX according
>>            to the mapping established at registration time.
>>            Although policy at the SSP may override this generally
>>            expected behavior, proper behavior of the registration
>>            event package requires that all "reg" event SUBSCRIBE
>>            requests are processed by the PBX. As a consequence,
>>            the requirements on an SSP for processing registration
>>            event package SUBSCRIBE requests are not left to policy.
>>
>>  This also highlights the fact that there are no normative requirements to
>>  handle INVITE in this way -- I've added some text to section 6 to both
>>  clarify that the processing generally applies to any method, and that it
>>  is mandatory for INVITE.
>>
>> --
>> Ticket URL:
>> <http://trac.tools.ietf.org/wg/martini/trac/ticket/36#comment:1>
>> martini <http://tools.ietf.org/martini/>
>>
>> _______________________________________________
>> martini mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/martini
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>