Jhon miller wrote:
hi all, I have Proxy(namely P1) with 10 valid Users.I have a separate Proxy(namely P2) with 4 Valid users. I want to send only one SUBSCRIBE from P1 to P2 on behalf of that 10 users.(I dont want to maintain 10 Subscribe) Is it possible to Bulk Subscription.(ie a Proxy send a Subscribe on behalf of the valid users)
The simple answer is NO. But some further explanation and nuances are appropriate:
You aren't too specific about the use case. Lets assume that the users are named:
- sip:[EMAIL PROTECTED]
- ...
- sip:[EMAIL PROTECTED]
- sip:[EMAIL PROTECTED]
- ...
- sip:[EMAIL PROTECTED]
and then assume that everybody wants to get the presence of everybody else.
In general, there will be a separate authorization decision for each user. (So y4 may permit only x1,x2,y3, while x1 only permits x10,y1.)
The only defined way to handle this situation is for every subscription to be handled independently, so it may be authorized, or refused.
Also, notifications are not supposed to be sent unless there is a subscription. Were the proxy to initiate the subscriptions, then the UAs would have none, and so could not receive notifications. And, if the proxy initiated a subscription, it wouldn't be a proxy - it would be a UA.
However there are some other possible approaches to this.
It may be that each UA wants to minimize its outbound subscriptions. It can do this by storing a buddy list on a server - perhaps the same server that acts as its proxy. The buddy list is an instance of what is called a resource list - a list of URIs. This list can have a URI of its own, and a SUBSCRIBE may be directed to it. E.g.
SUBSCRIBE sip:[EMAIL PROTECTED]
In this case the server (p1) is acting as a special UA (a Resource List Server - RLS) which is a sort of B2BUA. When it receives one subscribe to a list, it fans it out into multiple subscribes to all the entries in the list, and directs all the NOTIFY responses back to the subscriber.
This helps x1, but it doens't decrease the total number of subscriptions in the system, unless the RLS does some proprietary optimizations. For instance, if it is also the presence server for x1...x10, it might be able to respond on their behalf without actually subscribing. But it is more problematic when crossing domains.
If p1 was acting as an RLS for x1...x10, it could conceivably generate a single subscribe to each of y1...y4, using its own credentials, and then provide the results back to any of x1...x10 that have requested it. This doesn't provide the best of results, because the results received will reflect what the y users are willing to disclose to p1 rather than to the actual subscribers. It also still requires one subscription to each user in the foreign domain.
To resolve the latter problem, it would be necessary to have some agreement between P1 and P2, so that P2 maintained a buddy list for the benefit of P1, listing all of P2's users that P1 is interested in. Then P1 could subscribe to that buddy list.
None of this is very appealing. The only thing that provides good confidentiality properties is individual subscriptions.
Paul _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
