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