Re: Multiplexing sessions possible?

Andrew,

It would be better to maintain a lookup table of dialogs, rather than 
ServerTransactions. If you keep a reference to the ServerTransaction, the 
associated state (including SIP message received, etc.) does not get freed 
by the garbage collector.

Be sure to cleanup state properly, i.e. remove it upon BYE and perhaps 
periodically remove dead dialogs

If you want to be picky, a better place to put the call-id would be a URI 
parameter in the Contact header your concentrator forwards to the receiver. 
You will get it back as a parameter in the request URI for mid-call 
requests. That way, you could interwork with any standard client as 
receiver.

For step 5, if by "message back" you mean a response, a suggestion would be 
to use Transaction.setApplicationData to store a reference to the upstream 
Dialog.

Regards,
Jeroen

Andrew T Gin wrote:
> Hi
> Is there a simple way to multiplex or aggregate sip sessions onto a
> single session?
> for example
> Client1 Client2
>    |          |
> concentrator
>        |
>   Receiver
>
> That is, Client 1 and Client 2 have sessions with the concentrator.
> The concentrator has 1 session with the receiver and forwards
> messages from Client 1 and Client 2 to the Receiver. Forwarding data
> is easy, but what about forwarding data back to the clients (sent by
> the receiver)? Is there a way to recover a dialog by knowing the call
> ID?
> The way im doing it now is:
> 1. Concentrator sets up a single session with the receiver
> 2. Concentrator then waits for invites from clients
> 3. When a client sends an invite with the concentrator, a session is
> established between the concentrator and client; the concentrator does
> not have any interaction with the receiver in terms of invites from
> clients.
> 4. When the session between a client and concentrator is established,
> the client begins to send data. The concentrator then forwards this
> data to the receiver. I store the call-ID in a callInfo header in the
> message sent to the receiver. I also store the call-ID and the
> associated serverTransaction in a lookup table in the concentrator
> 5. the Receiver sends a message back to the concentrator, with the
> call-ID in the callInfo header.
> 6. The concentrator looks up the serverTransaction (based on the
> call-ID), and calls serverTransaction.getDialog to recover the call id
> and local(from) and remote(to) tags.
>
> I know my way is quite ugly and clunky, but is there a more elegant
> way of doing it?
>
> Thanks
> Andrew
> _______________________________________________
> nist-sip mailing list
> [email protected]
> http://www-x.antd.nist.gov/mailman/listinfo/nist-sip