Subject: Re: [sipcore] draft-ietf-martini-gin-05

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Jul 2010 21:29:00 -0400

(Still catching up on my reading)

This draft is hanging together very well now. I have a few comments:

Section 7.1.2.2:

According to RFC5627 (gruu) section 3.2, every registration refresh 
generates a new temp gruu, with special rules for expiration. Does that 
apply here too? Or is that changed for bnc registrations? Either way, I 
think the implications need to be discussed.

Section 7.2.1:

I think there may be an issue here. Normally RFC5628 (gruu reg event) 
would apply here, reporting the gruus assigned. (The most recent for the 
temp gruu.) That could work for the pub-gruu of each implicitly 
registered number. But it won't work for the temp gruus - the SSP 
doesn't even know what those are. If there was a record for the "base" 
AOR, that could contain the temp-gruu template. But that is currently 
forbidden.

Again, I think something needs to be said about this, whatever way it 
should work.

One thing to keep in mind is that management of temp gruus can be touchy 
relative to registration refreshes. If the registration ever expires, 
even momentarily, then the previously assigned temp gruus become 
invalid. Only new ones obtained after reregistration are then valid. In 
the case of the pbx with devices registered to it, that have have been 
issued "derived" temp gruus, those also become invalid.

The only way to be certain this hasn't happened is to subscribe to the 
reg event package and get gruu reg event info about the temp gruu. But 
that will only work if the pbx can get temp gruu info from a reg event 
subscription to the SSP.

Sorry to be so tardy in getting this info out. I think I alluded to it 
earlier, but I don't think I ever provided specifics.

	Thanks,
	Paul

7.2.2

There is an out for the SSP to handle the subscriptions if it can keep a 
complete, accurate and up to date copy of the data, e.g. through a 
backend subscription.) Its even harder than that, since the pbx could 
apply an authorization policy to each of those AORs, restricting who can 
see the info, and how much of it. The SSP couldn't learn that through 
backend subscriptions unless it maintains a distinct backend 
subscription for each potential subscriber.

In this section gruus again rear their ugly heads. If the pbx supports 
gruu, then it probably SHOULD support the gruu reg event package and 
return the appropriate information.