[sip-comm-dev] Dispatching incoming SIP messages consistently over time


#1

Hi all,

I'm struggling with an implementation problem and I'd like to hear your
comments about it.

For a cleaner design, it would be better if we could enforce that all
incoming SIP messages part of a same dialog were dispatched to the SIP
account which received the first message.

In other words, if I receive consecutively within a dialog the following
messages: (remote end initiating and ending the call)
(1) INVITE
(2) ACK
(3) BYE

(2) and (3) should be dispatched to the same account (1) was dispatched
to. Therefore, we must find a way to retrieve this account when
processing (2) *without* repeating the algorithm which led to the
dispatching of (1) (there are corner cases where this algorithm could
possibly be not consistent over time when dispatching messages of a same
dialog - for instance with same username and broken/intolerant registrar).

Which tools do we have? JAIN-SIP provides means to attach (ie mark) an
Object to a Message, a Transaction or a Dialog, but:
- (2) is obviously not the same Message as (1), nor the same Transaction
- when receiving (1), the Dialog does not exist yet (it is created when
  SIP Communicator creates the Response, so after the dispatching
  process)
- JAIN-SIP provides a very convenient Dialog.getFirstTransaction() but
  it is unfortunately marked as deprecated.

Any Idea?

I'm CC'ing users@jain-sip.

Cheers,

···

--
Sébastien Mazy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hi Jean,

Thanks for your reply, again.

When you create the dialog after the message has been dispatched you can set
the dialog application data the account to which (1) was dispatched.

Yes, that's exactly what I'd like.

If the account is not available anymore, you can set in the message
application data after the algorithm dispatching so that it becomes
available when you set the dialog application meta data after the response
has been created.

In this case, getting the account information is never a problem.

Would that work or am I missing something in your design and problem?

Here is what I first intended to reply:

"Theoretically it is a perfectly valid solution.
Unfortunately the SIP data flow in SIP Communicator and probably any
other SIP client is such that it would a lot of code duplication to
implement it that way. What I need – and I should have precised
it in my previous mail – is a single point where I can intercept the
newly created dialog before the response to the dialog creating request
is sent."

But I had missed something important, which invalidated the following
assumption:

> - when receiving (1), the Dialog does not exist yet (it is created when
> SIP Communicator creates the Response, so after the dispatching
> process)

From the javadoc:

"SipProvider.setAutomaticDialogSupportEnabled(...)
If this support is enabled, then Dialog creating Transactions (i.e.
INVITE) that are associated with this Provider automatically create a
Dialog when the Transaction is created."

With automatic dialog support enabled, the dialog is not created when
the Response is created or sent, but when getNewServerTransaction() is
called, which can be done in the SipListener during the dispatching
process.

[so Dialog.getFirstTransaction() is indeed not needed to make the link
between the first transaction and the rest of the dialog]

My bad, and sorry for the noise. Anyway, I'm glad to be able to take
advantage of the stateful nature of the stack.

···

On Thu, Jan 29, 2009 at 05:01:44PM +0100, Jean Deruelle wrote:

On Wed, Jan 28, 2009 at 11:34 PM, Sébastien Mazy <smazy@dev.java.net> wrote:

--
Sébastien Mazy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net