Re: Multiplexing sessions possible?

"M. Rangnathan" <[email protected]> Sat, 21 Apr 2007 09:35:21 -0400
Newsgroups gmane.comp.voip.nist-sip
Message-ID <[email protected]>
Andrew,

How about  Request request =  
(ServerTransaction)requestEvent.getSource().getRequest();


Regards,

Ranga

P.S. Folks, lets start using the user list on java.net. Our mailing list 
subscriber (web form) got compromised recently as we don't have any 
authentication mechanisms in place. Consequently, I had to put new 
subscriptions on hold.


 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 
>>
> _______________________________________________
> nist-sip mailing list
> [email protected]
> http://www-x.antd.nist.gov/mailman/listinfo/nist-sip


-- 
M. Ranganathan 

Advanced Networking Technologies Division,
National Institute of Standards and Technology (NIST),
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
tel:301 975 3664 , fax:301 590 0932 http://w3.antd.nist.gov/
Advanced Networking Technologies For the People!