Subject: [Sip] SIP level bundeling

From: atul garg <[email-masked]>
Date: Mon, 30 May 2011 14:52:13 +0530 (IST)

Hello,

I was supposed to do some implementation for the SIP message coming over TCP, I ahve few questions in following cases-

1) I read that many SIP messages can be bundelled into one TCP packet, -
      a) In this case, does all message belong to same SIP call(ie. same call id) - if so then when practiacally it is possible???
      b) If these sip messages are of different calls, then again what would be the scenario where IP and TCP level addresses are same but still messgaes are of different calls.( How UCA and UAS - multiple SIP session at same port ???)

2) In case of SIP fregmanmtion, I guess as TCP does not know the logical intelligence of SIP message, therefore sip message can be fregmented at any location even in between sip header, before call is ..... am i correct ...

TIA
Atul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 30 May 2011 12:35:17 +0200

2011/5/30 atul garg <[email-masked]>
> I was supposed to do some implementation for the SIP message coming over TCP, I ahve few questions in following cases-

Hi, please ask this kind of questions in sip-implementors maillist

>       a) In this case, does all message belong to same SIP call(ie. same call id) - if so then when practiacally it is possible???

Like in *any* protocol (or lot of) on top of TCP, multiple protocol
messages can arrive within same TCP stream. In fact, you could receive
even just incomplete fragments of a message and then must wait until
the rest arrives.

So, when a SIP message (request/response) arrives within a TCP stream
you MUST treat it as separate message and NEVER assume it belongs to
the same call/dialog as a previous message.

Imagine a TCP connection between two proxies. There can be multiple
dialogs/transactions over the same TCP connection at the same time.

>       b) If these sip messages are of different calls, then again what would be the scenario where IP and TCP level addresses are same but still messgaes are of different calls.( How UCA and UAS -…

Proxy A ----> Proxy B  is a good example.

Proxy ----> MediaServer  as well.

But in general you MUST NOT assume that a TCP connection just carries
a single dialog, that is a big fail.

> 2) In case of SIP fregmanmtion, I guess as TCP does not know the logical intelligence of SIP message, therefore sip message can be fregmented at any location even in between sip header, before call…

Of course. TCP is not message boundary so the receiver must buffer the
received data until it becomes a valid SIP message (it could drop the
connection if it takes so long as it could be an attack).

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Brett Tate <[email-masked]>
Date: Mon, 30 May 2011 05:35:57 -0700

> > 2) In case of SIP fregmanmtion, I guess as TCP does not know the
> logical intelligence of SIP message, therefore sip message can be
> fregmented at any location even in between sip header, before call is
> ..... am i correct ...
> 

Additionally concerning stream-oriented transports, the Content-Length header value is used to locate the end of the SIP message.  See RFC 3261 section 7.5, 18.3, and 20.14.

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 31 May 2011 11:54:19 -0400

The important thing to understand is that TCP provides a *byte-stream* between two endpoints.  In practice, the bytes will be grouped into IP packets, but that grouping is a matter of the TCP implementation -- that grouping is not visible to the higher layers of the stack and is not allowed to be meaningful.

If the TCP connection is for SIP, then SIP messages follow each other in the TCP stream.  The messages are not logically connected in any way; each message is processed based on its contents only (except for some special rules regarding how to route responses).  The first SIP message begins at the first byte of the TCP stream.  The message is required to contain a Content-Length header telling the length of the body.  The end of the headers is determined by the CR-LF-CR-LF sequence (empty line), and following that is the body whose length is specified by the Content-Length header.  Immediately after the body of the first message, the second message begins.  Etc.  (IP packet boundaries may fall at any place in any message, and that is not significant.)

Dale