|
Since I really need to have this type of flexibility,
wouldn't it be simplest to extend MessageFilterRule to have an additional args
for UriList that can be set and tested for just like the other lists are tested.
This change is relatively trivial to do, but involves
changing the MessageFilterRule(...) signature.
What side affects would happen if I did the
following:
class MessageFilterRule
{
public:
typedef
std::vector<Data> SchemeList;
typedef
std::vector<Data> HostpartList;
enum HostpartTypes { Any,
HostIsMe, DomainIsMe, List };
typedef
std::vector<Data> EventList;
typedef
std::vector<MethodTypes> MethodList;
typedef
std::vector<Uri> UriList;
MessageFilterRule(SchemeList schemeList =
SchemeList(),
HostpartTypes hostpartType = Any,
MethodList methodList = MethodList(),
EventList eventTypeList = EventList(),
UriList uriList =
UriList());
MessageFilterRule(SchemeList
schemeList,
HostpartList hostpartList,
MethodList methodList = MethodList(),
EventList eventList = EventList(),
UriList uriList =
UriList());
bool matches(const SipMessage
&) const;
private:
bool schemeIsInList(const
Data &scheme) const;
bool hostIsInList(const Data
&hostpart) const;
bool
methodIsInList(MethodTypes method) const;
bool uriIsInList(const
Uri& uri) const;
bool eventIsInList(const
SipMessage& msg) const;
Bill Kovar
Avaya Inc.
(732) 852-2609
If the uris all
have the same host-part, not without subclassing DialogUsageManager. Or, perhaps
you could create a wrapper TU that contains a DUM and will answer isForMe in the
way you want.
For the list:
Does it make sense to make MessageFilterRule suitable for subclassing? This
would allow arbitrarily complex TU selection, which could be a very powerful
tool.
Thoughts?
Best regards,
Byron Campen
As I thought....
My solution (3rd Party Call Controller monitoring several
URIs) requires that I have one application (single IP:port) that contains
several (~10) UAs that each have a unique URI but share the same SipStack. Is
this at all doable given the capabilities discussed.
Bill Kovar
Avaya Inc.
(732) 852-2609
Are you trying
to choose the TU based on the user-part of the uri? If so, there isn't
anything in MessageFilterRule that will help you. You would need to make the
filter-rule based on the host-part of the uri.
Best regards,
Byron Campen
Byron,
I was using the To header as an example. Request-Uri is
obviously more appropriate. However, looking at the various args to
MessageFilterRule(...) I can't determine which part could be used for a
Header filter.
The choices are (and my ideas of their
applicability):
SchemeList - should be don't care
HostpartTypes - should be don't
care
HostpartList - should be don't care
MethodList - SIP methods - this looks like the one to
use but don't know how to set a specific Request-Uri
EventList - probably want to use this one too since I'm
using REFER.
The above is based on my examination of
MessageFilterRule.cxx. I have not pulled an SVN update since 2/06. Maybe the
file has changed to add additional functionality??
Bill Kovar
Avaya Inc.
(732) 852-2609
Why are you
making routing decisions based on the contents of the To header? The To:
header is not intended to drive routing; that is the job of the
Request-Uri.
Best regards,
Byron Campen
Byron,
I looked at the example you listed and I'm not clear
on how I would be able to to get the msgs to route correctly. The only
true difference between the UAs is their AOR value. Is there a way to use
the
MessageFilterRules to force the msg to go
to the correct UA based on the TO address??
Or something
else?
Suggestions??
Bill Kovar
Avaya Inc.
(732) 852-2609
The
TuSelector in the resip stack uses
TransactionUser::isForMe(SipMessage& msg) to determine which TU to
send the message to. The TuSelector will hand the message to the first TU
that returns true when isForMe is called. You can influence how a
given DUM answers isForMe by registering MessageFilterRules with that
particular instance of DUM. (see repro/repro.cxx for an example of how
this can be done)
Best regards,
Byron Campen
All,
Although I
was told several months ago that this should work, I am seeing problems
with the same SipStack associated with 2 different UAs.
The
Registration of each UA seems to get routed correctly, i.e. the
OnSuccess() for the Register for a specific UA is being delivered to the
correct UA.
However,
when an INVITE is sent to a particular URI, it goes to the first UA that
was associated with the SipStack.
Any
thoughts?? It seems the transaction layer is tied to IP:PORT somehow
which could be a cause of this problem...
Bill Kovar
Avaya Inc.
(732) 852-2609
_______________________________________________
resiprocate-devel mailing list
|