| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
Why not just use 1 stack and 1 DUM? Use the AppDialogSet’s to
associate app data with invite transactions to keep track which callbacks apply
to which URI. From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Kovar,
William (Bill) 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 From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx] 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?? Which one is appropriate to set Request-Uri=sip:X@xxxxx for
all Methods and Events. Bill
Kovar Avaya
Inc. (732)
852-2609 From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx] 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 From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx] 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 |