6 Jan
2011
6 Jan
'11
6:34 a.m.
Hi,
My situation is that I have a number of SIP end points (server) that
support SUBSCRIBE method on various resources they hold. Primarily these
are dialog resources, but include arbitrary other resources with custom
MIME types.
I also have a large number of SIP end-points (clients) that use
SUBSCRIBE to resources held by these end-points. Some of these
end-points are standard phones (SPA-962) monitoring dialog state. Other
end points are custom clients that monitor a variety of custom resources
and MIME types.
I have got to the point where the number of SUBSCRIBE clients is making
it impractical for the SUBSCRIBE sources to support them.
I want to make a SUBSCRIBE proxy server that makes arbitrary SUBSCRIBE
requests to my SIP end points (server) and in turn accepts SUBSCRIBE
requests from my consumer SIP clients (Phones etc). In effect the server
would aggregate SUBSCRIBE requests into a single SUBSCRIBE to a target
resource.
Ideally the SUBSCRIPTION would be dynamic, generated by the SUBSCRIBE
requests from the SIP phones and other clients, but this can be static.
I've read the documentation for the RLS module in Kamailio but I can't
actually figure out what it does. It may do what I want (if only in some
database mode) but I'd appreciate advice as to whether to pursue this as
an option or go to plan-B
Regards
Jeremy
7 Jan
7 Jan
10:58 p.m.
Jeremya wrote:
Hi,
My situation is that I have a number of SIP end points (server) that
support SUBSCRIBE method on various resources they hold. Primarily these
are dialog resources, but include arbitrary other resources with custom
MIME types.
I also have a large number of SIP end-points (clients) that use
SUBSCRIBE to resources held by these end-points. Some of these
end-points are standard phones (SPA-962) monitoring dialog state. Other
end points are custom clients that monitor a variety of custom resources
and MIME types.
I have got to the point where the number of SUBSCRIBE clients is making
it impractical for the SUBSCRIBE sources to support them.
Why? What it your problem? To many active subscriptions on the servers?
I want to make a SUBSCRIBE proxy server that makes
arbitrary SUBSCRIBE
requests to my SIP end points (server) and in turn accepts SUBSCRIBE
requests from my consumer SIP clients (Phones etc). In effect the server
would aggregate SUBSCRIBE requests into a single SUBSCRIBE to a target
resource.
So, instead of A subscribing to X at the server and B subscribing X at
the server, you want Kamailio to "intercept" this subscription and
instead Kamailio is only making a single subscription to the server
which holds the data of X?
Ideally the SUBSCRIPTION would be dynamic, generated
by the SUBSCRIBE
requests from the SIP phones and other clients, but this can be static.
I think the resources for the ougoing subscription would be available
inside the modules (pua module) but I think another module would be
needed which does the aggregation.
I've read the documentation for the RLS module in
Kamailio but I can't
actually figure out what it does. It may do what I want (if only in some
database mode) but I'd appreciate advice as to whether to pursue this as
an option or go to plan-B
RLS module implements resource list subscriptions: E.g. instead of A
subscrbing to X, Y and Z A has only a single subscription to "foobar"
and the RLS module will extend this single subscription into 3
subscription. (thus decreasing the load on the client, but not on the
presence server).
What is plan-B?
regards
klaus
8 Jan
8 Jan
12:52 a.m.
Klaus Darilion wrote:
Yes
The clients I have include SPA962. They support aggregated dialog
subscriptions as well as individual dialog subscriptions. Perhaps this
is all I need? If so, are there any examples of how to use RLS? As I
said I've read the docs but it ain't clear.
Jeremya wrote:
Yes, but also the clients are not very robust, so temporary network
problems gets them giving up. (They are all at one location, so a
co-located aggregator wouldn't have network issues)
Hi,
My situation is that I have a number of SIP end points (server) that
support SUBSCRIBE method on various resources they hold. Primarily
these are dialog resources, but include arbitrary other resources
with custom MIME types.
I also have a large number of SIP end-points (clients) that use
SUBSCRIBE to resources held by these end-points. Some of these
end-points are standard phones (SPA-962) monitoring dialog state.
Other end points are custom clients that monitor a variety of custom
resources and MIME types.
I have got to the point where the number of SUBSCRIBE clients is
making it impractical for the SUBSCRIBE sources to support them.
Why? What it your problem? To many active subscriptions on the servers? I want to make a SUBSCRIBE proxy server that
makes arbitrary
SUBSCRIBE requests to my SIP end points (server) and in turn accepts
SUBSCRIBE requests from my consumer SIP clients (Phones etc). In
effect the server would aggregate SUBSCRIBE requests into a single
SUBSCRIBE to a target resource.
So, instead of A subscribing to X at the server and B subscribing X at
the server, you want Kamailio to "intercept" this subscription and
instead Kamailio is only making a single subscription to the server
which holds the data of X? Ideally the SUBSCRIPTION would be dynamic,
generated by the SUBSCRIBE
requests from the SIP phones and other clients, but this can be static.
I think the resources for the ougoing subscription would be available
inside the modules (pua module) but I think another module would be
needed which does the aggregation.
I've read the documentation for the RLS
module in Kamailio but I
can't actually figure out what it does. It may do what I want (if
only in some database mode) but I'd appreciate advice as to whether
to pursue this as an option or go to plan-B
RLS module implements resource list subscriptions: E.g. instead of A
subscrbing to X, Y and Z A has only a single subscription to "foobar"
and the RLS module will extend this single subscription into 3
subscription. (thus decreasing the load on the client, but not on the
presence server).
What is plan-B?
Code it using sipxtapi. I've done subscribe servers and subscribe
clients using it, but the underlying code is ever so broken...
regards
klaus
5075
days inactive
5076
days old
2 comments
2 participants
participants (2)
-
Jeremya -
Klaus Darilion