Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for SIPcompression

From: "Liu Zhigang.C (NRC/Dallas)" <[email-masked]>
Date: Mon, 20 Aug 2001 14:20:39 -0500

Hans,

Attached is a message sequence for mobile-originated call
scenario in 3GPP (sorry about the size, ~6K). It was based 
on 3GPP TS 24.228 (v0.4.0 March/2001): "Signaling flows for 
the IP multimedia call control based on SIP and SDP". 

It was generated back in April when we started the test.
Recently, there is a new version (v1.2.0 July/2001) of
TS 24.228 released. So, some updates might be needed.
But the basic sequence is still the same. 

If time allowed, we probably need another sequence for mobile-
terminated call, which can be found in the same document.

BR,
Zhigang

PS. I noticed that the lines in the files are terminated by LF 
instead of CRLF (as it should be). I guess it was messed up 
during the transfer between Windows and Linux.

> -----Original Message-----
> From: ext Hans Hannu [mailto:[email-masked]]
> Sent: August 20, 2001 12:47 PM
> To: Liu Zhigang.C (NRC/Dallas); [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for
> SIPcompression
> 
> 
> Hi Zhigang,
> 
> I read Ishita's mail too quickly. Thus, we currently only 
> have one message sequnce, section 3.1.1 Successful Simple SIP 
> to SIP, from draft-ietf-sip-call-flows-05.txt. 
> If you could provide more sequences it would be good.
> 
> BR
> /Hans H
> 
> > -----Original Message-----
> > From: Liu Zhigang.C (NRC/Dallas) [mailto:[email-masked]]
> > Sent: den 20 augusti 2001 19:02
> > To: [email-masked]; 'Lawrence Conroy'; [email-masked];
> > [email-masked]
> > Cc: [email-masked]; Le Khiem (NRC/Dallas)
> > Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for
> > SIPcompression
> > 
> > 
> > Hi Hans,
> > 
> > Are the message sequences you get from Richard and Ishita
> > based on draft-ietf-sip-call-flows-05.txt or 3GPP TS
> > 24.228? Were they sent to the mailing list?
> > 
> > BR,
> > Zhigang
> > 
> > > -----Original Message-----
> > > From: ext Hans Hannu [mailto:[email-masked]]
> > > Sent: August 20, 2001 11:46 AM
> > > To: 'Lawrence Conroy'; [email-masked]; [email-masked]
> > > Cc: [email-masked]; Liu Zhigang.C (NRC/Dallas); Le Khiem
> > > (NRC/Dallas)
> > > Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for
> > > SIPcompression
> > > 
> > > 
> > > Hi,
> > > 
> > > I like the idea of having some defined scenarios to be able 
> > > to compare the
> > > scheme against and those scenarios could be included in the 
> > > requirements
> > > document, but perhaps not under the requirements section, but 
> > > under the
> > > "assumptions" section.
> > > 
> > > We have already some message sequences (thanks to Richard and 
> > > Ishita) that
> > > we could use. What we need to do now is just find out some 
> > > representative
> > > channel bitrates to run these against. Maybe someone could 
> > > provide some
> > > channel bitrates?
> > > 
> > > Are there other "message exchange sequences" that someone 
> > > thinks are more
> > > representative than those already used?
> > > 
> > > BR
> > > /Hans H
> > > 
> > > > >Hi Hans,
> > > > >
> > > > >Since the SIP Call set up latency is one of the main (if not
> > > > the main)
> > > > >problem we want to solve with signaling compression, I
> > > > propose we add a
> > > > >requirement to that effect:
> > > > >
> > > > >The compression scheme MUST be such that when applied to
> > > > SIP, the call
> > > > >set up latency is less than X seconds, for a 
> > representative set of
> > > > >scenarios to be defined. Scenarios specify the messages
> > > > exchanged, their
> > > > >contents, as well as the channel bit rates.
> > > > >
> > > > >We need to agree on X and the scenarios, but I believe this
> > > > requirement
> > > > >is useful, because compression ratio alone does not
> > > > adequately capture
> > > > >the problem of call set up latency. Scenarios can be 
> > based on those
> > > > >typically envisioned in cellular cases like 3GPP.
> > > > >
> > > > >Khiem
> > > > >
> > > > To which I reply:
> > > > Hi Folks,
> > > >    There is a GERAN meeting at the end of the month, and I 
> > > will canvas
> > > > to see if there is a HARD limit such as that proposed as a
> > > > requirement.
> > > >
> > > > However...
> > > > I think that the assumption that the main goal of SIP Comp is
> > > > to reduce
> > > > (or, as described above, =>LIMIT<= ) the call set up time is
> > > > not obvious
> > > > (to me, at least) and I'm not yet happy to have it 
> included in the
> > > > requirements document as proposed.
> > > >
> > > > For GERAN at least, the HARD requirement is on the mid-call 
> > > Re-Invite
> > > > sequence, NOT on the call set up. That's probably true for
> > > > UTRAN as well,
> > > > but that's not my area of interest.
> > > >
> > > > I have already sent a posting on my understanding of the
> > > > GERAN mid-call
> > > > problem and the figures that seem to apply there (and the 
> > reasons).
> > > >
> > > > Of course one benefit of SIP Comp is that we reduce the 
> > transmission
> > > > time for messages sent during call set up for latency 
> > > reasons, and so
> > > > we may avoid too many re-transmissions of SIP messages.
> > > > However, I don't
> > > > see how this is a HARD requirement and would be interested in
> > > > understanding
> > > > the logic here.
> > > >
> > > > Do we have a specific limit (like the DCS one that is, I
> > > > believe, regulated
> > > > by the FCC)?
> > > >
> > > > BR,
> > > >   L.
> > > > --
> > > > [email-masked]: +44 1794 833666::<my opinions>:
> > > >
> > > 
> > 
>

---

From: Romeo Zwart <[email-masked]>
Date: Wed, 22 Aug 2001 17:42:33 +0200

Please all note the highly relevant remark by Lawrence earlier on in
this thread:

   LWC>> For GERAN at least, the HARD requirement is on the mid-call
   LWC>> Re-Invite sequence, NOT on the call set up. That's probably
   LWC>> true for UTRAN as well, but that's not my area of interest.

At least in the GERAN environment, the real tough cases are
associated with mid-call signalling. This example flow is
clearly not from a mid-call scenario. Also the quoted BW
(starting off with 9.6kbps) does not sound like the mid-call
available bandwidth in GERAN to me - but then I have not been
directly involved in this work, so I may be underestimating
GERAN :-)

   LWC>> I have already sent a posting on my understanding of the
   LWC>> GERAN mid-call problem and the figures that seem to apply
   LWC>> there (and the reasons).

Lawrence, was this a post to rohc or sip list or both?

Thanks,

Romeo

> > > > > Do we have a specific limit (like the DCS one that is, I

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip