[reSIProcate] Many DUM -> one SipStack... Does it actually work??

Tue Aug 8 10:42:53 CDT 2006

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
bkovar at avaya.com

  _____  

From: Byron Campen [mailto:bcampen at estacado.net] 
Sent: Tuesday, August 08, 2006 10:27 AM
To: Kovar, William (Bill)
Cc: resiprocate-devel at list.sipfoundry.org
Subject: Re: [reSIProcate] Many DUM -> one SipStack... Does it actually
work??

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
	bkovar at avaya.com

  _____  

	From: Byron Campen [mailto:bcampen at estacado.net] 
	Sent: Tuesday, August 08, 2006 10:05 AM
	To: Kovar, William (Bill)
	Cc: resiprocate-devel at list.sipfoundry.org
	Subject: Re: [reSIProcate] Many DUM -> one SipStack... Does it
actually work??

	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 at Y.COM
<mailto:X at Y.COM>  for all Methods and Events.

		Bill Kovar
		Avaya Inc.
		(732) 852-2609
		bkovar at avaya.com

  _____  

		From: Byron Campen [mailto:bcampen at estacado.net] 
		Sent: Monday, August 07, 2006 5:50 PM
		To: Kovar, William (Bill)
		Cc: resiprocate-devel at list.sipfoundry.org
		Subject: Re: [reSIProcate] Many DUM -> one SipStack...
Does it actually work??

		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
			bkovar at avaya.com

  _____  

			From: Byron Campen [mailto:bcampen at estacado.net]

			Sent: Monday, August 07, 2006 3:44 PM
			To: Kovar, William (Bill)
			Cc: resiprocate-devel at list.sipfoundry.org
			Subject: Re: [reSIProcate] Many DUM -> one
SipStack... Does it actually work??

			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
				bkovar at avaya.com

_______________________________________________
				resiprocate-devel mailing list
				resiprocate-devel at list.sipfoundry.org

https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060808/e68659fa/attachment.htm>