SIP level bundeling

[atul garg]

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

[Iñaki Baz Castillo]

Post by atul garg
Hello,
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

Post by atul garg
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???

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.

Post by atul garg
      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 ???)

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.

Post by atul garg
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 ...

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
<***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related t

[Brett Tate]

Post by atul garg

Post by atul garg
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 ...
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).

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.

_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Worley, Dale R (Dale)]

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
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.