Jyoti,
You may have mis-understood my question. I understand the general working of state-creations and use of partial-state-id.
My question really is the following: Is it good practice for the server to start using a state-id that it has uploaded to A without getting a feedback for it from A. Apparently not. (esply the initial REGISTER/200 OK case - how do we make sure the first message from the server after a initial REGISTER/200 OK procedure, goes really compressed (i.e, no decompression bytecode))
If I read your email right --- I don't quite understand what you are saying and how it will work. In the example you show, the server uses the partial-state-id of the state that was uploaded
by A in the 200 OK (F2) for the REGISTER??? How will this work?
If that state is say the bytecode from A, how does the server determine what compressor to use? By looking at the state-id?? no, that can't be... Here the server cannot send a message using A's partial-state-id.
Unless the state-id you are talking about is for a well-known state or something that is mutually agreed offline between A and the Server, what you suggest will not work. - actually in this case, there is no reason for A to send the bytecode in the first place.
Thanks -Srini
P.S: F2 & F3 arrows in your picture are pointing the wrong way
[EMAIL PROTECTED] wrote:
Hi Srini
Please find the explaination of your scenario as under :- F1: A -----Register msg---------------> Server F2: A -----200 Ok to Register---------> Server F3: A -----Invite msg-----------------> Server
Assumtion : Both A & Server are sigcomp enabled and both have this information.
F1 will be sigcomp message which will contain compressed register msg along with the Bytecode for decompression. This bytecode can contain the STATE-Create request. At this point , at Server end, depending upon the SMS, State can be created.Lets assume State is created. F1 = Sigcomp hdrs + bytecode of A + compressed msg
F2 will be sigcomp msg sent from Server to A which will contain the Partial-State-Id of the state created by endpoint A (at Server). It implies that from now onwards end-point A need not send decompression bytecode to server & must send only the partial-state-id (which will identify the bytecode at server end). Thus, state is created in (A-to-Server) link. Also incase the server wants to send the compressed message & wants to create a state at endpoint-A,it can send the State-Create request to A in the bytecode of Server. F2 = Sigcomp hdrs(partial-state-id of bytecode-A) + bytecode of Server + compressed msg
F3 will be sigcomp msg sent from A to Server which will contain the partial-state-id of A (not the full decompression bytecode of A). Also incase the Server has created a state at stage F2 then endpoint-A will send partial-state-id of Server in this message to Server. F3 = Sigcomp hdrs(partial-state-id of bytecode-Server) + compressed msg & reference to partial-state-id of bytecode-A
Hope that above clarifies your doubt.
thanks and regards Jyoti Bhalla
======================================= Jyoti Bhalla Hughes Software Systems Bangalore India http://www.hssworld.com =======================================
[EMAIL PROTECTED] wrote on 07/26/2004 10:08:20 PM:
All, Have question on SIGCOMP as applied to SIP.
Take a model where SIGCOMP compartments are created at registration time. Say, a REGISTER from the client establishes state at the Server, and 200-OK for the REGISTER establishes state at the client. The server could ack client's state-creation requests along with this 200-OK. The client is now ready to send compressed msgs using the state acked from the server.
However there is no SIP/SIGCOMP that goes back to the server at this point. Therefore, any initial messages that the server sends to the client after this registration cannot yet be compressed using state info sent with the 200-OK. (until an feedback/ack is received from the client for the states created)
Is this how it is done? What are the current best-practices, on the server-side, in this context?
Should I otherwise post this to the rohc list at ietf.
Thanks for any help/advice. -- Srini K ksrini at motorola
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
