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