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

From: "martini issue tracker" <[email-masked]>
Date: Mon, 19 Apr 2010 22:12:54 -0000

#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/>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Apr 2010 11:16:20 -0400

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)
> 
>  Reporter:  john.elwell@...                       |        Owner:
> Changes (by adam@...):
> Ticket URL:
> <http://trac.tools.ietf.org/wg/martini/trac/ticket/36#comment:1>
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini

---

From: "martini issue tracker" <[email-masked]>
Date: Fri, 23 Apr 2010 15:37:19 -0000

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

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

Comment:

 I don't see why this should act any differently from reg-event for any
 other AoR of the SSP.  If a SUBSCRIBE request for the reg-event package is
 targeted at "sip:[email-masked]", then it is asking for registration state
 info of that AoR.  The PBX does not know that information.  Only the
 Registrar or something with access to the location service database knows
 that information.  For example, there may be other registered contacts for
 that AoR, or no registered contacts currently (no PBX).  The register
 state-machine described in RFC 3680 for the resource identified by the
 target is the one in the SSP for that AoR, not the PBX.

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

---

From: "Brian Lindsay" <[email-masked]>
Date: Fri, 23 Apr 2010 14:48:34 -0400

Hi Adam/all,

  Regarding section 7.1.1, there is the following text:

   "When an incoming request arrives at the SSP for a GRUU corresponding
   to a bulk number contact ("bnc"), the SSP performs slightly different
   processing for the GRUU than a Proxy/Registrar would.  When the GRUU
   is retargeted to the registered bulk number contact, the SSP MUST
   copy the "sg" parameter from the GRUU to the new target.  The PBX can
   then use this "sg" parameter to determine which user agent the
   request should be routed to.  For example, the first line of an
   INVITE request that has been retargeted to the PBX for the terminal
   shown above would look like this:

   <allOneLine>
   INVITE sip:[email-masked];gr=urn:uuid:f81d4fae-7dec-
   11d0-a765-00a0c91e6bf6;sg=00:05:03:5e:70:a6 SIP/2.0
   </allOneLine>"

  The text above calls out the "sg" parm is copied to the new target,
but it doesn't explicitly mention the "gr" parm being copied.

  RFC 5627 states regarding request targeting : "[...] the Request-URI
will be rewritten with the registered contacts, replacing the GRUU and
its "gr" URI parameter.  The "gr" URI parameter is not carried forward
into the rewritten Request-URI."

  It seems like the text would need to be modified to also note the
deviation from RFC 5627 in terms of handling of the gr parm itself
(unless I'm missing something?).

  Thanks
    Brian

---

From: Adam Roach <[email-masked]>
Date: Fri, 23 Apr 2010 13:52:28 -0500

> (unless I'm missing something?).

Good catch. The text is correct -- the example is wrong.

/a

---

From: Dean Willis <[email-masked]>
Date: Mon, 26 Apr 2010 00:59:54 -0500

On Apr 23, 2010, at 10:16 AM, Hadriel Kaplan 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.

I'm thinking along similar lines.

Assumption #1 for MARTINI (at least at this phase) is that we're doing  
a bulk registration that produces a result which can not be externally  
distinguished from multiple unique registrations. It's not a new  
routing model -- it is just a bulk registration.

I'd LIKE to do a new routing model, but that's a bigger more complex  
thing that can be handled separately.

--
Dean