Russell Bryant wrote:
Mihai Balea wrote:
That is the theoretical maximum UDP packet size. As I mentioned in
one of my previous emails, Mac OSX limits UDP packets to approx. 9K.
I'm sure there are other systems out there that would enforce similar
limits (I am thinking embedded systems).
Ah. Well, for this reason, as well as concerns of having to retransmit
an extremely large Full frames, I would say that the text in the RFC
describing this new segmented information element method should only be
used in situations where the payload is "slightly" larger than 255
bytes, such as the case with the OSP token information, which will take
4 segments. However, the text should strongly discourage use of this
method for extremely large amounts of data.
Even if ~ 64K would be achievable, what if I need to transmit 65K? The
solution does not scale well and limits like this can be easily
exceeded in today's applications.
If we come to a point where we would like to implement the ability to do
transfers of this size, then we will have to handle it with a separate
method.
On the topic of holding up the link while transmitting a large
packet, this isn't something that would be newly introduced into
IAX2. In fact, it is normal to have extremely large IAX2 trunk
frames which get transmitted a lot more often than any signaling frames.
Trunk frames do not require retransmission.
True. I was just trying to address the concern about blocking the link
while the single large packet is transmitted.
If we're extending the protocol, I would be in favor of defining a new
type of large frame plus a packetization mechanism that would be able
to transfer an unlimited amount of data. We could have a separate
mechanism of retransmission if needed, as long as we do not impact the
existing control and media frames.
I agree with you if we decide to implement a method for doing something
like peer-to-peer file transfers over IAX2. However, I still think this
generic IE segmentation method is perfect for OSP tokens, and perhaps
other applications in the future which would only take a few segments.
There are actually two independent tasks that we need to solve, when we
carry large amounts of information in IAX2 _signalling_ messages:
Task A: Breaking the IE into segments that can be included in an IAX2
signaling message in a backward compatible manner..
Task B: If an IAX2 signaling message becomes larger than what can be
transported over the network, i.e. bigger than max UDP packet (~1500
bytes), the IAX2 message needs to be broken into pieces, i.e. need to be
segmented.
The purpose of the current IE segmentation proposal is to cover the task
A (only), and it already covers the OP's OSPTOKEN application in a
future proof manner.
However, if we do not create additionally an IAX2 message segmentation
method, there is no way to transport transport, for example, an IAX2 NEW
message that contains a bit more supplementary service information in
addition to the OSPTOKEN. In other words, the IAX2 signalling message
size limit can be hit fairly easily with single IEs and a couple of
segmented IEs.
I am not taking a position, whether a particular application needs to be
implemented using IAX2 signaling transport, but just saying that there
are signaling applications requiring IAX2 message segmentation. If this
requirement is agreed I can make a proposal for message segmentation.
Markku
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
