Re: Multiplexing sessions possible?

Hi
Thanks for your suggestions. I guess I wasn't too far off the 'optimum' 
solution!
How are responses sent when there is no knowledge of which server 
transaction it belongs to? If I know the serverTransaction then I 
normally create a response using
Response newResponse = 
messageFactory.createResponse(response.getStatusCode(), 
serverTransaction.getRequest());
serverTransaction.sendResponse(newResponse);

serverTransaction.sendResponse sends it off to the client correctly.
However when I only know the dialog, when I create a response, I use 
sipProvider.sendResponse(), is that correct? Without the 
serverTransaction, there is no other way to send a response. Is this 
correct? Unfortunately when I use sipProvider.sendResponse, the response 
is sent to myself; it is not sent to the correct receiving party. How 
does sipProvider know which host to send the stateless response to?

Jeroen van Bemmel wrote:
> 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 
>