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
