Re: Multiplexing sessions possible?

Lebing,

As I said, perhaps I misunderstood the call flow. In general there are 3 
places to keep state:
1 - Contact URI
2 - Record-Route URI
3 - Via param

(1) can only be used by an endpoint (UAC or UAS or B2BUA), (2) is typically 
used by a proxy, (3) can be used by both but scope is limited to current 
transaction

Regards,
Jeroen

Lebing Xie wrote:
> Hi, Jeroen
>
> I am not agree with the idea putting CallID into contact header.
> According to RFC, Contact header can be used to contact the party even
> after this call is terminated, say some later time. I thought a better
> idea is put call id as parameter into RecordRouter or VIA header for
> diglog/transaction level mapping.
>
> urs Lebing
>
>
> On Fri, 2007-04-20 at 23:11 +0200, 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