Re: Multiplexing sessions possible?

Andrew,

Perhaps I've misunderstood your callflows

Indeed you typically need the ServerTransaction to forward a response. You 
could maintain a reference to it by using 
ClientTransaction.setApplicationData( st ) when you forward a request to the 
receiver. Then, upon a response, you retrieve the clienttransaction from the 
event, and get the st back.

There are multiple ways of creating/forwarding responses. What you are 
currently doing is known as a Back-2-back-User-Agent approach, i.e. you 
generate a new response based on the status code of the received response 
and the contents of the original request. Another way (as done by proxies) 
would be to *strip the topmost Via header* (if you don't, indeed you will 
get the response back at the same machine) and then use st.sendResponse on 
that

The SipProvider takes the IP+port from the topmost Via header

Regards,
Jeroen

Andrew T Gin wrote:
> 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