2011/5/30 atul garg <[email protected]> > > 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 rather than here. Anyhow I reply below: > 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. > 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. > 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 <[email protected]> _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is essentially closed and only used for finishing old business. Use [email protected] for questions on how to develop a SIP implementation. Use [email protected] for new developments on the application of sip. Use [email protected] for issues related to maintenance of the core SIP specifications.
