Concerning your registerDialogProcessor() suggestion. Sounds nice but I
am worried about the programming overhead. This would require operation
sets to register themselves as a processor for every dialog they create.
Just for the record: We had a talk yesterday and agreed that
registering a mandatory listener for every dialog is a bad idea.
Now, I thought about this since our talk yesterday and here's what I
suggest: both the Dialog and the Transaction interfaces have the
following two methods:
public void setApplicationData(Object applicationData);
public Object getApplicationData();
They are meant for applications to tag dialogs and transaction with
stateful, dialog/transaction dependent information. I think we could
easily implement all muxing/demuxing with them.
Sure. These methods are very handy.
We can even make them
almost transparent for the rest of the application. We just need to make
sure that all dialogs and transactions get tagged with a reference to
the owning SC provider when they are created. It would probably also be
a good idea to make sure that no dialogs nor transactions can be created
within SC without attaching the corresponding tag. We would probably
need to restrict access to the jain sip providers in order to achieve this.
Currently I'm implementing it in the following way:
- "SipProvider ProviderServiceSipImpl.getJainSipProvider(String
transport)" will return a VirtualSipProvider
- VirtualSipProvider is a wrapper around the real SipProvider
(instance of SipProviderImpl), the only difference is that it tags
every created dialog (is it needed to tag transactions? can I have a
transaction without a dialog?). There is one VirtualSipProvider per
transport per ProtocolProviderServiceSipImpl instance (so basically 3
- there is only one instanciated SipMessageDispatcher whatever the
number of ProtocolProviderSipImpl is (it is a static field of
ProtocolProviderServiceSipImpl). This single instance is the
SipListener for every "real" SipProvider (ie instance of
SipProviderImpl). It directly dispatches received events whose DialogS
are tagged to the proper ProtocolProviderServiceSipImpl (so that it
will be processed as before and be sent to an OpSet).
- It will be completely transparent for OpSets. Not a single line of
them will be changed.
- Dialogs we initiated would be dispatched quickly and reliably
- for Dialogs we didn't initiate (non tagged), see below
If Dialog.getApplicationData/setApplicationData is to be used, please
note that I use it in
Noted. I'll be careful no to break that. I even think of not using
setApplicationData to make that fully transparent. Since I created
VirtualSipProvider, I could also create a new field in the Dialog
returned by getNewDialog().
Enrico also suggesting having a look at the use part of the request URI
in addition to analysing the whole URI. Here's what this gives us:
1. Check if the TO header matches any of our AORs
2. Check if the Request URI matches any of our AORs
3. Check if the user part of the request URI matches the user part of
any of our AORs
4. Forward to a default account.
Does this make sense?
According to http://wiki.voip.co.uk/sip/matching_using_to_header, the
only reliable way to guess which account an incoming message is
addressed to is by looking at the Request-URI, because it shoud match
the contact header field sent to the registrar (if we have a registrar
of course). And as this contact header contains our own IP address or
hostname, you can only check the user part of the Request-URI. (That
would explain why Twinkle doesn't allow to have two accounts with the
same contact user part.)
So I would change the order:
1. Check if the user part of the request URI matches the user part of
any of our AORs only if all of our AORs have different user parts
2. Check if the TO header matches any of our AORs
3. Forward to a default account (which could be the one without a
registrar if it exists).
And so we would handle the case where the user decided to redirect
calls to one SIP account to another (and both are registrated in SC).
Yes, that's really a corner case
Anyway, for the file transfer purposes i needed to allow multiple
OperationSets [OperationSetBasicTelephony and
OperationSetFileTransferSipImpl] to register on the provider so that i could
process the incoming SIP INVITE requests that it's how the file transfer is
negotiated. So, basicly i ended up registering both operation sets so that
both of them get called when there is an INVITE and what i did was that on
the processRequest, i checked the body of the incoming SDP offer to see if
it had a 'file-selector' attribute, if it did the processRequest of the
OperationSetFileTransferSipImpl continued processing the INVITE, if it
didn't then OperationSetBasicTelephony would take care of it.
As for the problem of registering the same request (most of a time a
NOTIFY) twice, I'm still convinced it could be a good idea to provide
a way to create a per-Dialog listener when you want to, it would just
add a few lines of code to ProtcolProviderServiceSipImpl. A new
method, for example getNewDialog(SipListener aListener), would allow
to bypass the default SipListener (the related
ProtocolProviderServiceSipImpl) for this dialog only. But for the
moment, I'll only concentrate on the above issues.
I know long and with quotations mails are hard to read, sorry.
On Mon, Aug 25, 2008 at 1:37 PM, Emil Ivov <email@example.com> wrote:
On Mon, Aug 25, 2008 at 1:45 PM, Lubomir Marinov <firstname.lastname@example.org> wrote:
On Mon, Aug 25, 2008 at 5:04 PM, Emil Ivov <email@example.com> wrote:
On Mon, Aug 25, 2008 at 5:08 PM, Joao Antunes <firstname.lastname@example.org> wrote: