Subject: RE: SIP - BCP Query

From: [email-masked]
Date: Tue, 14 Sep 1999 16:46:06 -0600

Hello,

This is with regard to the Content-Length calculation in the SIP-BCP draft
draft-zimmerer-mmusic-sip-bcp-t-00.txt.
The method followed by us is explained below.
Comments are welcome. Any necessary changes will be incorporated in later
versions of this draft.

Aparna 

a) This is the example that we have used in the BCP draft. The number of
octets
     used in each line are shown at the end of each line in parenthesis.

                INVITE sip:[email-masked] SIP/2.0
	From: sip:[email-masked]
	To: sip:[email-masked]
	Call-ID: [email-masked]
	Content-Type: Application/ Multipart
	Content-Length: 327

                MIME-Version: 1.0(17)
	Content-Type: multipart/mixed; boundary=unique-boundary-1(57)

	--unique-boundary-1(19)
	Content-Type: application/SDP; charset=ISO-10646(49)

                v=0(3)
	o=ezimmerer 2890844526 2890842807 IN IP4 126.16.64.4(52)
	s=SDP seminar(13)
   	c=IN IP4 MG122.level3.com(25)
	t=2873397496 2873404696(23)
	m=audio 9092 RTP/AVP 0 3 4(26)

	--unique-boundary-1(19)
	Content-type:application/ISUP;version=ETSI1(44)
	Content-Transfer-Encoding: binary(34)

	89 8b 0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00(17*2)

	--unique-boundary-1--(21)

b)  Rules used to calculate the Content-Length:
     b.1 Use 2 octets to encode the CRLF sequence at the end of each line
           and the beginning of a blank line.
     b.2 For the MIME header: each character maps onto one octet.
     b.3 For the SDP payload: each character maps onto one octet according
to UTF-8 encoding (RFC 2044) used as specified in the SIP-BCP.
     b.4 For the ISUP payload: self-explanatory.

c) Content-Length calculation:
     c.1 Number of octets in the ISUP payload (including the CRLF at the
end)
            =  34 + 2 = 36
     c.2 Number of octets in the MIME header for the ISUP payload (including
the CRLF at the end of each line)
            = 46+ 36
            = 82
     c.3 Number of octets in the SDP payload (including the CRLFs at the end
of each of the lines)
            = 5 + 54 + 15 + 27 + 25 + 28
            = 154
     c.4 Number of octets in the MIME header for the SDP payload (including
the CRLF at the end of the line)
            =51
     c.5 Number of octets in the MIME multi-part header
            = 19 + 59
            = 78
     c.6 Number of octets in the '--unique-boundary-1' string and newlines
used throughout:
             = 21 + 21 + 23 + 6*2 = 77
     c.7 The grand-total
             = 36 + 82 +154 + 51 + 78 + 77 = 478

Yes, the Content-Length in our example should be changed to 478.

Aparna V.
Level 3 Communications

-----Original Message-----
From: Bobby Sardana [mailto:[email-masked]]
Sent: Saturday, September 11, 1999 5:32 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: SIP - BCP Query

Greetings:

While in the process of updating our SIP grammar to be SIP-BCP
compliant, I was not able to determine the following:

a. The ISUP example, mentioned in section 2.2.1 of the
draft-ietf-mmusic-sip-bcp-t-00.txt, mentions an example of embedded IAM
message within the body of the SIP message. I was wondering if the
calculated Content-Length, mentioned as 327 is right? If it is, an
explanation of how it was calculated would help. I am aware of HTTP 1.1
Content-Length calculations and tried to apply it against the example
but still was unable to resolve the length to be anywhere near 327.

Thanks.

Bobby Sardana.
[email-masked]

---

From: "Adam B. Roach" <[email-masked]>
Date: Wed, 15 Sep 1999 11:16:53 -0500 (CDT)

>	89 8b 0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00(17*2)
...
>     c.1 Number of octets in the ISUP payload (including the CRLF at the

When I read this, I assumed that, since you specify "binary encoding,"
each byte is encoded as a byte, not a two-character hex representation.
It was my interpretation that you spelled it out with hex digits in the
draft because a literal encoding of those bytes would be confusing,
unreadable, and difficult to transfer via e-mail.

This is further enforced by the contention in the draft that binary
encoding is used instead of base64 for space considerations.

Finally, if you're using a binary representation, there *is* no CR/LF
at the end of the section. It is my impression, then, that this section
should be 17 bytes instead of 36. 

Am I missing something?

Perhaps this should be spelled out more clearly in the draft. If it's
confusing enough that one of the authors misinterprets it, I'm willing
to be that many others will be thrown for a loop.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: Bobby Sardana <[email-masked]>
Date: Wed, 15 Sep 1999 23:39:35 -0500

Greetings:

To continue with some of the legit concerns raised by Adam, here are a few of
my own:

> >     c.1 Number of octets in the ISUP payload (including the CRLF at the

 a. The example had " space" characters in it to separate the octets. What
about the count of those?

b. Will the octets be a stream (which it should be) with no whitespace or the
layout dictates to have each octet marked with a separator (easy for parsing)?

Thanks.

Bobby Sardana.
[email-masked]