Subject: [Megaco] TCP: H.248 Incomplete Message Handling

From: "Shashank Taneja" <[email-masked]>
Date: Mon, 27 Aug 2007 20:48:56 +0530

Hello,

I need some clarification on the issue of handling of partial H.248
messages received in case of TCP transport.

Since TCP is a byte-stream oriented protocol we may receive an
incomplete H.248 message in one TCP PDU. In particular for the text
encoding of the message, since the length of the message is not encoded
within the H.248 Message it is not possible to know how many more bytes
are expected to make this partial message complete. Furthermore there is
no delimiter for the end of H.248 message. 
This would create a lot of complexity in segregating an incomplete
message from a badly encoded message as the length of message is not
available.
Please share your views/ideas on this. Are there any
assumptions/decisions that have been discussed for H.248 over TCP.

Thanks in advance and any thoughts on this would be deeply appreciated.

Thanks

Shashank

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Maridi R. Makaraju \(Raju\)" <[email-masked]>
Date: Mon, 27 Aug 2007 10:30:15 -0500

Shashank,
 
For TCP, TPKT RFC 1006 should be used to delineate H.248 messages within a TCP stream.
See "D.2 Using TCP" of Megaco spec.
 
-Raju

  _____  

From: Shashank Taneja [mailto:[email-masked]] 
Sent: Monday, August 27, 2007 10:19 AM
To: [email-masked]
Subject: [Megaco] TCP: H.248 Incomplete Message Handling

Hello,

I need some clarification on the issue of handling of partial H.248 messages received in case of TCP transport.

Since TCP is a byte-stream oriented protocol we may receive an incomplete H.248 message in one TCP PDU. In particular for the text
encoding of the message, since the length of the message is not encoded within the H.248 Message it is not possible to know how many
more bytes are expected to make this partial message complete. Furthermore there is no delimiter for the end of H.248 message. 
This would create a lot of complexity in segregating an incomplete message from a badly encoded message as the length of message is
not available.
Please share your views/ideas on this. Are there any assumptions/decisions that have been discussed for H.248 over TCP.

Thanks

Shashank