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!