Re: [h323forum] Re: Codec negotiation question
Trying to not 'plug' any company or technology in this arena, however, I am doing a consulting project for a company that schedules the packets - versus prioritizing them. They are in beta mode but their tests reveal a very effective method for delivering video with greatly reduced latency and jitter.
It would be useful to be able to have input from this group both on the idea and on their technology specifically.
Regards, Denise
Denise K. Shull SHULL ADVISORS, LLC Strategic Application of Meeting Technologies 646-498-6403 www.videooverip.biz
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Monday, December 16, 2002 8:04 PM To: Paul Long; h323forum@mail.imtc.org; ITU-SG16@echo.jf.INTEL.COM Subject: [h323forum] Re: Codec negotiation question
Paul,
Do you mean RFC 2508?
In any case, Robert's point is indeed valid. This is where having a specialize GW that multiplexes the RTP streams for delivery over the long-haul is something practical.
Perhaps we could take that up as a work item with SG16? It would be reasonable to specify how such an Gateway might function in order to trunk a large number of active calls over long distance. Anyone interested in such a work item?
Paul
----- Original Message ----- From: "Paul Long" plong@packetizer.com To: h323forum@mail.imtc.org Sent: Monday, December 16, 2002 7:49 PM Subject: [h323forum] Re: Codec negotiation question
Robert,
Excellent point. I hadn't thought of that. I wonder what happened to cRTP. Anybody know? That would sure help.
Paul
On Mon, 16 Dec 2002 12:53:34 -0500 "Paul Long" plong@packetizer.com wrote:
I know lots of folks would like a means of expressing exact packetization, but isn't the solution trivial? All you need is a
small
FIFO and a few lines of code to re-packetize according to any
internal
requirements. Just write incoming frames regardless of size, e.g., 30fpp, to the FIFO, and read whatever size frames you want, e.g.,
80fpp
from the FIFO (only read if there are at least X fpp in the FIFO).
DSP hardware is not the only reason for wanting to have the remote endpoint send larger packets. We have many clients on long haul
internet
links (300ms+ ping times), often with a slow tail circuit (ISDN or
even
modem) and you REALLY want the other end to send more than one
G.723.1
frame per packet to reduce the significant overhead that there is in
the
RTP.
It is unfortunate but true that there is no way of expressing a
minimum
acceptable number of frames per packet.
Regards, Chris
Paul Long wrote:
Davide,
There is nothing in the standard that requires the acceptance
of an
OLC
or precludes terminating the call for any reason whatsoever so
both
EPs
are technically compliant.
Packetization in TCS and OLC expresses the _maximum_ frames
per
packet,
but several vendors don't understand this simple concept and
continue
to produce products that expect an exact packetization. There
is a
good
chance that that is why EP A is rejecting the OLC. It wants
the
channel
opened at exactly 80fpp, although there is no way to express
this
in
H.323. IMO, if this is the reason, that product is broken.
Paul
Hi all,
I have a question about a codec negotiation. During H.245 negotiation, endpoint A (master) exports
g711A-law
with
packetization 80, endpoint B (slave) exports g711A-law with packetization 30. After that, endpoint A opens a channel with packetization = 20 ms. Endpoint B acknoledges the OLC and
tries
to
open
a channel with packetization = 30 ms.
Here Endpoint A rejects the OLC and the call is disengaged.
Does anybody can tell me which endpoint dosn't behave
according
to
the H323 standard?
Thank you in advance.
Davide
You are currently subscribed to h323forum as: cwp@isdn-
comms.co.uk
To unsubscribe send a blank email to %%email.unsub%%
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down
Road
Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
You are currently subscribed to h323forum as:
equival@equival.com.au
To unsubscribe send a blank email to %%email.unsub%%
Robert Jongbloed Equivalence Pty. Ltd. Architect Open Phone Abstraction Library (OPAL) & OpenH323 Open Source Telecommunication Protocol Libraries
Quicknet's revolutionary MicroTelco Services offers LOW WORLDWIDE RATES ANY TIME OF THE DAY with No monthly fees! No monthly minimums! No connection fees! US rates as low as 2.9 cents a minute! To see more rates, visit www.microtelco.com
****LIVE VIDEO CONFERENCE NOW AVAILABLE***** CUseeMe v5.0 software is an affordable easy-to-use software application providing live visual communication between friends, family and colleagues worldwide. To learn more, visit, www.cuseemeworld.com
You are currently subscribed to h323forum as: paulej@packetizer.com To unsubscribe send a blank email to %%email.unsub%%
--- You are currently subscribed to h323forum as: deniseshull@sbcglobal.net To unsubscribe send a blank email to leave-h323forum-30418E@mail.imtc.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com
Denise,
I think that any such scheme should be a candidate for consideration. There are a number of such complexities to consider when building such a gateway for trunking traffic over a long distance. Defining how to queue packets for transmission (scheduled, prioritized, FIFO, etc.) is certainly an important aspect to consider. There are others and I'd like to see such discussions progress.
Would you or the company you're consulting with like take an active part in a standardization activity along these lines?
Paul
----- Original Message ----- From: "Denise Shull" deniseshull@sbcglobal.net To: "'Paul E. Jones'" paulej@packetizer.com; "'Paul Long'" plong@packetizer.com; h323forum@mail.imtc.org; ITU-SG16@echo.jf.INTEL.COM Sent: Tuesday, December 17, 2002 3:55 PM Subject: RE: [h323forum] Re: Codec negotiation question
Trying to not 'plug' any company or technology in this arena, however, I am doing a consulting project for a company that schedules the packets - versus prioritizing them. They are in beta mode but their tests reveal a very effective method for delivering video with greatly reduced latency and jitter.
It would be useful to be able to have input from this group both on the idea and on their technology specifically.
Regards, Denise
Denise K. Shull SHULL ADVISORS, LLC Strategic Application of Meeting Technologies 646-498-6403 www.videooverip.biz
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Monday, December 16, 2002 8:04 PM To: Paul Long; h323forum@mail.imtc.org; ITU-SG16@echo.jf.INTEL.COM Subject: [h323forum] Re: Codec negotiation question
Paul,
Do you mean RFC 2508?
In any case, Robert's point is indeed valid. This is where having a specialize GW that multiplexes the RTP streams for delivery over the long-haul is something practical.
Perhaps we could take that up as a work item with SG16? It would be reasonable to specify how such an Gateway might function in order to trunk a large number of active calls over long distance. Anyone interested in such a work item?
Paul
----- Original Message ----- From: "Paul Long" plong@packetizer.com To: h323forum@mail.imtc.org Sent: Monday, December 16, 2002 7:49 PM Subject: [h323forum] Re: Codec negotiation question
Robert,
Excellent point. I hadn't thought of that. I wonder what happened to cRTP. Anybody know? That would sure help.
Paul
On Mon, 16 Dec 2002 12:53:34 -0500 "Paul Long" plong@packetizer.com wrote:
I know lots of folks would like a means of expressing exact packetization, but isn't the solution trivial? All you need is a
small
FIFO and a few lines of code to re-packetize according to any
internal
requirements. Just write incoming frames regardless of size, e.g., 30fpp, to the FIFO, and read whatever size frames you want, e.g.,
80fpp
from the FIFO (only read if there are at least X fpp in the FIFO).
DSP hardware is not the only reason for wanting to have the remote endpoint send larger packets. We have many clients on long haul
internet
links (300ms+ ping times), often with a slow tail circuit (ISDN or
even
modem) and you REALLY want the other end to send more than one
G.723.1
frame per packet to reduce the significant overhead that there is in
the
RTP.
It is unfortunate but true that there is no way of expressing a
minimum
acceptable number of frames per packet.
Regards, Chris
Paul Long wrote:
Davide,
There is nothing in the standard that requires the acceptance
of an
OLC
or precludes terminating the call for any reason whatsoever so
both
EPs
are technically compliant.
Packetization in TCS and OLC expresses the _maximum_ frames
per
packet,
but several vendors don't understand this simple concept and
continue
to produce products that expect an exact packetization. There
is a
good
chance that that is why EP A is rejecting the OLC. It wants
the
channel
opened at exactly 80fpp, although there is no way to express
this
in
H.323. IMO, if this is the reason, that product is broken.
Paul
>Hi all, > >I have a question about a codec negotiation. >During H.245 negotiation, endpoint A (master) exports
g711A-law
with
packetization 80, endpoint B (slave) exports g711A-law with packetization 30. After that, endpoint A opens a channel with packetization = 20 ms. Endpoint B acknoledges the OLC and
tries
to
open
a channel with packetization = 30 ms.
>Here Endpoint A rejects the OLC and the call is disengaged. > >Does anybody can tell me which endpoint dosn't behave
according
to
the H323 standard?
>Thank you in advance. > >Davide
You are currently subscribed to h323forum as: cwp@isdn-
comms.co.uk
To unsubscribe send a blank email to %%email.unsub%%
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down
Road
Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
You are currently subscribed to h323forum as:
equival@equival.com.au
To unsubscribe send a blank email to %%email.unsub%%
Robert Jongbloed Equivalence Pty. Ltd. Architect Open Phone Abstraction Library (OPAL) & OpenH323 Open Source Telecommunication Protocol Libraries
Quicknet's revolutionary MicroTelco Services offers LOW WORLDWIDE RATES ANY TIME OF THE DAY with No monthly fees! No monthly minimums! No connection fees! US rates as low as 2.9 cents a minute! To see more rates, visit www.microtelco.com
****LIVE VIDEO CONFERENCE NOW AVAILABLE***** CUseeMe v5.0 software is an affordable easy-to-use software application providing live visual communication between friends, family and colleagues worldwide. To learn more, visit, www.cuseemeworld.com
You are currently subscribed to h323forum as: paulej@packetizer.com To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to h323forum as: deniseshull@sbcglobal.net To unsubscribe send a blank email to leave-h323forum-30418E@mail.imtc.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com
You can look at the IETF AVT Working group's draft on TCRTP:
http://www.ietf.org/internet-drafts/draft-ietf-avt-tcrtp-07.txt
It's a mature protocol being implemented (or already implemented) by handful of vendors.
Thanks, Bala
-----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@echo.jf.INTEL.COM] On Behalf Of Denise Shull Sent: Tuesday, December 17, 2002 3:56 PM To: ITU-SG16@echo.jf.INTEL.COM Subject: Re: [h323forum] Re: Codec negotiation question
Trying to not 'plug' any company or technology in this arena, however, I am doing a consulting project for a company that schedules the packets - versus prioritizing them. They are in beta mode but their tests reveal a very effective method for delivering video with greatly reduced latency and jitter.
It would be useful to be able to have input from this group both on the idea and on their technology specifically.
Regards, Denise
Denise K. Shull SHULL ADVISORS, LLC Strategic Application of Meeting Technologies 646-498-6403 www.videooverip.biz
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Monday, December 16, 2002 8:04 PM To: Paul Long; h323forum@mail.imtc.org; ITU-SG16@echo.jf.INTEL.COM Subject: [h323forum] Re: Codec negotiation question
Paul,
Do you mean RFC 2508?
In any case, Robert's point is indeed valid. This is where having a specialize GW that multiplexes the RTP streams for delivery over the long-haul is something practical.
Perhaps we could take that up as a work item with SG16? It would be reasonable to specify how such an Gateway might function in order to trunk a large number of active calls over long distance. Anyone interested in such a work item?
Paul
----- Original Message ----- From: "Paul Long" plong@packetizer.com To: h323forum@mail.imtc.org Sent: Monday, December 16, 2002 7:49 PM Subject: [h323forum] Re: Codec negotiation question
Robert,
Excellent point. I hadn't thought of that. I wonder what happened to cRTP. Anybody know? That would sure help.
Paul
On Mon, 16 Dec 2002 12:53:34 -0500 "Paul Long" plong@packetizer.com wrote:
I know lots of folks would like a means of expressing exact packetization, but isn't the solution trivial? All you need is a
small
FIFO and a few lines of code to re-packetize according to any
internal
requirements. Just write incoming frames regardless of size, e.g., 30fpp, to the FIFO, and read whatever size frames you want, e.g.,
80fpp
from the FIFO (only read if there are at least X fpp in the FIFO).
DSP hardware is not the only reason for wanting to have the remote endpoint send larger packets. We have many clients on long haul
internet
links (300ms+ ping times), often with a slow tail circuit (ISDN or
even
modem) and you REALLY want the other end to send more than one
G.723.1
frame per packet to reduce the significant overhead that there is in
the
RTP.
It is unfortunate but true that there is no way of expressing a
minimum
acceptable number of frames per packet.
Regards, Chris
Paul Long wrote:
Davide,
There is nothing in the standard that requires the acceptance
of an
OLC
or precludes terminating the call for any reason whatsoever so
both
EPs
are technically compliant.
Packetization in TCS and OLC expresses the _maximum_ frames
per
packet,
but several vendors don't understand this simple concept and
continue
to produce products that expect an exact packetization. There
is a
good
chance that that is why EP A is rejecting the OLC. It wants
the
channel
opened at exactly 80fpp, although there is no way to express
this
in
H.323. IMO, if this is the reason, that product is broken.
Paul
Hi all,
I have a question about a codec negotiation. During H.245 negotiation, endpoint A (master) exports
g711A-law
with
packetization 80, endpoint B (slave) exports g711A-law with packetization 30. After that, endpoint A opens a channel with packetization = 20 ms. Endpoint B acknoledges the OLC and
tries
to
open
a channel with packetization = 30 ms.
Here Endpoint A rejects the OLC and the call is disengaged.
Does anybody can tell me which endpoint dosn't behave
according
to
the H323 standard?
Thank you in advance.
Davide
You are currently subscribed to h323forum as: cwp@isdn-
comms.co.uk
To unsubscribe send a blank email to %%email.unsub%%
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down
Road
Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
You are currently subscribed to h323forum as:
equival@equival.com.au
To unsubscribe send a blank email to %%email.unsub%%
Robert Jongbloed Equivalence Pty. Ltd. Architect Open Phone Abstraction Library (OPAL) & OpenH323 Open Source Telecommunication Protocol Libraries
Quicknet's revolutionary MicroTelco Services offers LOW WORLDWIDE RATES ANY TIME OF THE DAY with No monthly fees! No monthly minimums! No connection fees! US rates as low as 2.9 cents a minute! To see more rates, visit www.microtelco.com
****LIVE VIDEO CONFERENCE NOW AVAILABLE***** CUseeMe v5.0 software is an affordable easy-to-use software application providing live visual communication between friends, family and colleagues worldwide. To learn more, visit, www.cuseemeworld.com
You are currently subscribed to h323forum as: paulej@packetizer.com To unsubscribe send a blank email to %%email.unsub%%
--- You are currently subscribed to h323forum as: deniseshull@sbcglobal.net To unsubscribe send a blank email to leave-h323forum-30418E@mail.imtc.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com
Bala,
This is certainly a good document to consider. Looking at it briefly, I did have a number of questions as to how this would signaled to the other end. I assume that perhaps two GWs are configured to know about each other and whenever a call is routed between them, it's just a given that the RTP traffic is dropped into this tunnel... you might be able to clarify that.
In any case, the scope of this work may be that it does not define protocols, but simply specify how existing protocols might be used in the context of H.323 and/or H.248. Certainly, I would say that the possibility to have more than one way to do it should be considered... this document definitely does not consideration to what Denise had mentioned. ("Scheduling", for example, would be something to discuss in context of this or another protocol that solves the same type problem.)
Paul
----- Original Message ----- From: "Balasubramanian Pitchandi" bs@utstar.com To: "'Denise Shull'" deniseshull@SBCGLOBAL.NET; ITU-SG16@echo.jf.INTEL.COM; paulej@packetizer.com Sent: Tuesday, December 17, 2002 4:42 PM Subject: RE: [h323forum] Re: Codec negotiation question
You can look at the IETF AVT Working group's draft on TCRTP:
http://www.ietf.org/internet-drafts/draft-ietf-avt-tcrtp-07.txt
It's a mature protocol being implemented (or already implemented) by handful of vendors.
Thanks, Bala
-----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@echo.jf.INTEL.COM] On Behalf Of Denise Shull Sent: Tuesday, December 17, 2002 3:56 PM To: ITU-SG16@echo.jf.INTEL.COM Subject: Re: [h323forum] Re: Codec negotiation question
Trying to not 'plug' any company or technology in this arena, however, I am doing a consulting project for a company that schedules the packets - versus prioritizing them. They are in beta mode but their tests reveal a very effective method for delivering video with greatly reduced latency and jitter.
It would be useful to be able to have input from this group both on the idea and on their technology specifically.
Regards, Denise
Denise K. Shull SHULL ADVISORS, LLC Strategic Application of Meeting Technologies 646-498-6403 www.videooverip.biz
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Monday, December 16, 2002 8:04 PM To: Paul Long; h323forum@mail.imtc.org; ITU-SG16@echo.jf.INTEL.COM Subject: [h323forum] Re: Codec negotiation question
Paul,
Do you mean RFC 2508?
In any case, Robert's point is indeed valid. This is where having a specialize GW that multiplexes the RTP streams for delivery over the long-haul is something practical.
Perhaps we could take that up as a work item with SG16? It would be reasonable to specify how such an Gateway might function in order to trunk a large number of active calls over long distance. Anyone interested in such a work item?
Paul
----- Original Message ----- From: "Paul Long" plong@packetizer.com To: h323forum@mail.imtc.org Sent: Monday, December 16, 2002 7:49 PM Subject: [h323forum] Re: Codec negotiation question
Robert,
Excellent point. I hadn't thought of that. I wonder what happened to cRTP. Anybody know? That would sure help.
Paul
On Mon, 16 Dec 2002 12:53:34 -0500 "Paul Long" plong@packetizer.com wrote:
I know lots of folks would like a means of expressing exact packetization, but isn't the solution trivial? All you need is a
small
FIFO and a few lines of code to re-packetize according to any
internal
requirements. Just write incoming frames regardless of size, e.g., 30fpp, to the FIFO, and read whatever size frames you want, e.g.,
80fpp
from the FIFO (only read if there are at least X fpp in the FIFO).
DSP hardware is not the only reason for wanting to have the remote endpoint send larger packets. We have many clients on long haul
internet
links (300ms+ ping times), often with a slow tail circuit (ISDN or
even
modem) and you REALLY want the other end to send more than one
G.723.1
frame per packet to reduce the significant overhead that there is in
the
RTP.
It is unfortunate but true that there is no way of expressing a
minimum
acceptable number of frames per packet.
Regards, Chris
Paul Long wrote:
Davide,
There is nothing in the standard that requires the acceptance
of an
OLC
or precludes terminating the call for any reason whatsoever so
both
EPs
are technically compliant.
Packetization in TCS and OLC expresses the _maximum_ frames
per
packet,
but several vendors don't understand this simple concept and
continue
to produce products that expect an exact packetization. There
is a
good
chance that that is why EP A is rejecting the OLC. It wants
the
channel
opened at exactly 80fpp, although there is no way to express
this
in
H.323. IMO, if this is the reason, that product is broken.
Paul
>Hi all, > >I have a question about a codec negotiation. >During H.245 negotiation, endpoint A (master) exports
g711A-law
with
packetization 80, endpoint B (slave) exports g711A-law with packetization 30. After that, endpoint A opens a channel with packetization = 20 ms. Endpoint B acknoledges the OLC and
tries
to
open
a channel with packetization = 30 ms.
>Here Endpoint A rejects the OLC and the call is disengaged. > >Does anybody can tell me which endpoint dosn't behave
according
to
the H323 standard?
>Thank you in advance. > >Davide
You are currently subscribed to h323forum as: cwp@isdn-
comms.co.uk
To unsubscribe send a blank email to %%email.unsub%%
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down
Road
Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
You are currently subscribed to h323forum as:
equival@equival.com.au
To unsubscribe send a blank email to %%email.unsub%%
Robert Jongbloed Equivalence Pty. Ltd. Architect Open Phone Abstraction Library (OPAL) & OpenH323 Open Source Telecommunication Protocol Libraries
Quicknet's revolutionary MicroTelco Services offers LOW WORLDWIDE RATES ANY TIME OF THE DAY with No monthly fees! No monthly minimums! No connection fees! US rates as low as 2.9 cents a minute! To see more rates, visit www.microtelco.com
****LIVE VIDEO CONFERENCE NOW AVAILABLE***** CUseeMe v5.0 software is an affordable easy-to-use software application providing live visual communication between friends, family and colleagues worldwide. To learn more, visit, www.cuseemeworld.com
You are currently subscribed to h323forum as: paulej@packetizer.com To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to h323forum as: deniseshull@sbcglobal.net To unsubscribe send a blank email to leave-h323forum-30418E@mail.imtc.org
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com
Paul,
The remote side is informed through the signaling (SIP, H.323, Megaco/MGCP etc) that the connection being created is a RTPTrunk connection (the other choice being a regular RTP connection). Right now, there may not be any specific signaling elements to pass this information - We use proprietary extensions in such cases.
So, for a long distance call, the signaling will indicate that a RTPTrunk has to be created and a designated GW (or a module in the GW) would create that trunk with the given parameters (local and remote IP addresses, port numbers etc.)
Thanks, Bala
PS: I am copying this message to the AVT so that if they have any inputs on this issue, they can share with us.
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Tuesday, December 17, 2002 5:58 PM To: bs@utstar.com; 'Denise Shull'; ITU-SG16@echo.jf.INTEL.COM Subject: Re: [h323forum] Re: Codec negotiation question
Bala,
This is certainly a good document to consider. Looking at it briefly, I did have a number of questions as to how this would signaled to the other end. I assume that perhaps two GWs are configured to know about each other and whenever a call is routed between them, it's just a given that the RTP traffic is dropped into this tunnel... you might be able to clarify that.
In any case, the scope of this work may be that it does not define protocols, but simply specify how existing protocols might be used in the context of H.323 and/or H.248. Certainly, I would say that the possibility to have more than one way to do it should be considered... this document definitely does not consideration to what Denise had mentioned. ("Scheduling", for example, would be something to discuss in context of this or another protocol that solves the same type problem.)
Paul
----- Original Message ----- From: "Balasubramanian Pitchandi" bs@utstar.com To: "'Denise Shull'" deniseshull@SBCGLOBAL.NET; ITU-SG16@echo.jf.INTEL.COM; paulej@packetizer.com Sent: Tuesday, December 17, 2002 4:42 PM Subject: RE: [h323forum] Re: Codec negotiation question
You can look at the IETF AVT Working group's draft on TCRTP:
http://www.ietf.org/internet-drafts/draft-ietf-avt-tcrtp-07.txt
It's a mature protocol being implemented (or already implemented) by handful of vendors.
Thanks, Bala
-----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@echo.jf.INTEL.COM] On Behalf Of Denise Shull Sent: Tuesday, December 17, 2002 3:56 PM To: ITU-SG16@echo.jf.INTEL.COM Subject: Re: [h323forum] Re: Codec negotiation question
Trying to not 'plug' any company or technology in this arena, however,
I
am doing a consulting project for a company that schedules the packets
-
versus prioritizing them. They are in beta mode but their tests
reveal
a very effective method for delivering video with greatly reduced latency and jitter.
It would be useful to be able to have input from this group both on
the
idea and on their technology specifically.
Regards, Denise
Denise K. Shull SHULL ADVISORS, LLC Strategic Application of Meeting Technologies 646-498-6403 www.videooverip.biz
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Monday, December 16, 2002 8:04 PM To: Paul Long; h323forum@mail.imtc.org; ITU-SG16@echo.jf.INTEL.COM Subject: [h323forum] Re: Codec negotiation question
Paul,
Do you mean RFC 2508?
In any case, Robert's point is indeed valid. This is where having a specialize GW that multiplexes the RTP streams for delivery over the long-haul is something practical.
Perhaps we could take that up as a work item with SG16? It would be reasonable to specify how such an Gateway might function in order to trunk a large number of active calls over long distance. Anyone interested in such a work item?
Paul
----- Original Message ----- From: "Paul Long" plong@packetizer.com To: h323forum@mail.imtc.org Sent: Monday, December 16, 2002 7:49 PM Subject: [h323forum] Re: Codec negotiation question
Robert,
Excellent point. I hadn't thought of that. I wonder what happened to cRTP. Anybody know? That would sure help.
Paul
On Mon, 16 Dec 2002 12:53:34 -0500 "Paul Long" plong@packetizer.com wrote:
I know lots of folks would like a means of expressing exact packetization, but isn't the solution trivial? All you need is a
small
FIFO and a few lines of code to re-packetize according to any
internal
requirements. Just write incoming frames regardless of size,
e.g.,
30fpp, to the FIFO, and read whatever size frames you want,
e.g.,
80fpp
from the FIFO (only read if there are at least X fpp in the
FIFO).
DSP hardware is not the only reason for wanting to have the remote endpoint send larger packets. We have many clients on long haul
internet
links (300ms+ ping times), often with a slow tail circuit (ISDN or
even
modem) and you REALLY want the other end to send more than one
G.723.1
frame per packet to reduce the significant overhead that there is
in
the
RTP.
It is unfortunate but true that there is no way of expressing
a
minimum
acceptable number of frames per packet.
Regards, Chris
Paul Long wrote:
Davide,
There is nothing in the standard that requires the
acceptance
of an
OLC
or precludes terminating the call for any reason whatsoever
so
both
EPs
are technically compliant.
Packetization in TCS and OLC expresses the _maximum_ frames
per
packet,
but several vendors don't understand this simple concept and
continue
to produce products that expect an exact packetization.
There
is a
good
chance that that is why EP A is rejecting the OLC. It wants
the
channel
opened at exactly 80fpp, although there is no way to express
this
in
H.323. IMO, if this is the reason, that product is broken.
Paul
>Hi all, > >I have a question about a codec negotiation. >During H.245 negotiation, endpoint A (master) exports
g711A-law
with
packetization 80, endpoint B (slave) exports g711A-law with packetization 30. After that, endpoint A opens a channel
with
packetization = 20 ms. Endpoint B acknoledges the OLC and
tries
to
open
a channel with packetization = 30 ms.
>Here Endpoint A rejects the OLC and the call is disengaged. > >Does anybody can tell me which endpoint dosn't behave
according
to
the H323 standard?
>Thank you in advance. > >Davide
You are currently subscribed to h323forum as: cwp@isdn-
comms.co.uk
To unsubscribe send a blank email to %%email.unsub%%
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down
Road
Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
You are currently subscribed to h323forum as:
equival@equival.com.au
To unsubscribe send a blank email to %%email.unsub%%
Robert Jongbloed Equivalence Pty. Ltd. Architect Open Phone Abstraction Library (OPAL) & OpenH323 Open Source Telecommunication Protocol Libraries
Quicknet's revolutionary MicroTelco Services offers LOW WORLDWIDE RATES ANY TIME OF THE DAY with No monthly fees! No monthly minimums! No connection fees! US rates as low as 2.9 cents a minute! To see more rates, visit www.microtelco.com
****LIVE VIDEO CONFERENCE NOW AVAILABLE***** CUseeMe v5.0 software is an affordable easy-to-use software application providing live visual communication between friends, family and colleagues worldwide. To learn more, visit, www.cuseemeworld.com
You are currently subscribed to h323forum as: paulej@packetizer.com To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to h323forum as:
deniseshull@sbcglobal.net
To unsubscribe send a blank email to leave-h323forum-30418E@mail.imtc.org
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com
Bala,
So it seems that an area that may still need to be addressed is what this signaling looks like within H.323 or SIP. I've not seen any drafts for SIP and there's certainly nothing on the H.323 side.
As I mentioned, though, it may be that the particular draft you referenced may not lead to a complete solution that meets everybody's requirements. For example, Denise mentioned one thing that may or may not be captured in that draft.
I'm also looking within the ITU (particularly SG15) to see if any work in this area has already been done. I know that I've heard it discussed on more than one occasion, but I've not been personally involved in this activity.
Paul
----- Original Message ----- From: "Balasubramanian Pitchandi" bs@utstar.com To: "'Paul E. Jones'" paulej@packetizer.com; "'Denise Shull'" deniseshull@SBCGLOBAL.NET; ITU-SG16@echo.jf.INTEL.COM Cc: avt@ietf.org Sent: Tuesday, December 17, 2002 7:09 PM Subject: RE: [h323forum] Re: Codec negotiation question
Paul,
The remote side is informed through the signaling (SIP, H.323, Megaco/MGCP etc) that the connection being created is a RTPTrunk connection (the other choice being a regular RTP connection). Right now, there may not be any specific signaling elements to pass this information - We use proprietary extensions in such cases.
So, for a long distance call, the signaling will indicate that a RTPTrunk has to be created and a designated GW (or a module in the GW) would create that trunk with the given parameters (local and remote IP addresses, port numbers etc.)
Thanks, Bala
PS: I am copying this message to the AVT so that if they have any inputs on this issue, they can share with us.
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Tuesday, December 17, 2002 5:58 PM To: bs@utstar.com; 'Denise Shull'; ITU-SG16@echo.jf.INTEL.COM Subject: Re: [h323forum] Re: Codec negotiation question
Bala,
This is certainly a good document to consider. Looking at it briefly, I did have a number of questions as to how this would signaled to the other end. I assume that perhaps two GWs are configured to know about each other and whenever a call is routed between them, it's just a given that the RTP traffic is dropped into this tunnel... you might be able to clarify that.
In any case, the scope of this work may be that it does not define protocols, but simply specify how existing protocols might be used in the context of H.323 and/or H.248. Certainly, I would say that the possibility to have more than one way to do it should be considered... this document definitely does not consideration to what Denise had mentioned. ("Scheduling", for example, would be something to discuss in context of this or another protocol that solves the same type problem.)
Paul
----- Original Message ----- From: "Balasubramanian Pitchandi" bs@utstar.com To: "'Denise Shull'" deniseshull@SBCGLOBAL.NET; ITU-SG16@echo.jf.INTEL.COM; paulej@packetizer.com Sent: Tuesday, December 17, 2002 4:42 PM Subject: RE: [h323forum] Re: Codec negotiation question
You can look at the IETF AVT Working group's draft on TCRTP:
http://www.ietf.org/internet-drafts/draft-ietf-avt-tcrtp-07.txt
It's a mature protocol being implemented (or already implemented) by handful of vendors.
Thanks, Bala
-----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@echo.jf.INTEL.COM] On Behalf Of Denise Shull Sent: Tuesday, December 17, 2002 3:56 PM To: ITU-SG16@echo.jf.INTEL.COM Subject: Re: [h323forum] Re: Codec negotiation question
Trying to not 'plug' any company or technology in this arena, however,
I
am doing a consulting project for a company that schedules the packets
versus prioritizing them. They are in beta mode but their tests
reveal
a very effective method for delivering video with greatly reduced latency and jitter.
It would be useful to be able to have input from this group both on
the
idea and on their technology specifically.
Regards, Denise
Denise K. Shull SHULL ADVISORS, LLC Strategic Application of Meeting Technologies 646-498-6403 www.videooverip.biz
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Monday, December 16, 2002 8:04 PM To: Paul Long; h323forum@mail.imtc.org; ITU-SG16@echo.jf.INTEL.COM Subject: [h323forum] Re: Codec negotiation question
Paul,
Do you mean RFC 2508?
In any case, Robert's point is indeed valid. This is where having a specialize GW that multiplexes the RTP streams for delivery over the long-haul is something practical.
Perhaps we could take that up as a work item with SG16? It would be reasonable to specify how such an Gateway might function in order to trunk a large number of active calls over long distance. Anyone interested in such a work item?
Paul
----- Original Message ----- From: "Paul Long" plong@packetizer.com To: h323forum@mail.imtc.org Sent: Monday, December 16, 2002 7:49 PM Subject: [h323forum] Re: Codec negotiation question
Robert,
Excellent point. I hadn't thought of that. I wonder what happened to cRTP. Anybody know? That would sure help.
Paul
On Mon, 16 Dec 2002 12:53:34 -0500 "Paul Long" plong@packetizer.com wrote:
I know lots of folks would like a means of expressing exact packetization, but isn't the solution trivial? All you need is a
small
FIFO and a few lines of code to re-packetize according to any
internal
requirements. Just write incoming frames regardless of size,
e.g.,
30fpp, to the FIFO, and read whatever size frames you want,
e.g.,
80fpp
from the FIFO (only read if there are at least X fpp in the
FIFO).
DSP hardware is not the only reason for wanting to have the remote endpoint send larger packets. We have many clients on long haul
internet
links (300ms+ ping times), often with a slow tail circuit (ISDN or
even
modem) and you REALLY want the other end to send more than one
G.723.1
frame per packet to reduce the significant overhead that there is
in
the
RTP.
It is unfortunate but true that there is no way of expressing
a
minimum
acceptable number of frames per packet.
Regards, Chris
Paul Long wrote: > Davide, > > There is nothing in the standard that requires the
acceptance
of an
OLC
> or precludes terminating the call for any reason whatsoever
so
both
EPs
> are technically compliant. > > Packetization in TCS and OLC expresses the _maximum_ frames
per
packet,
> but several vendors don't understand this simple concept and
continue
> to produce products that expect an exact packetization.
There
is a
good
> chance that that is why EP A is rejecting the OLC. It wants
the
channel
> opened at exactly 80fpp, although there is no way to express
this
in
> H.323. IMO, if this is the reason, that product is broken. > > Paul > > >>Hi all, >> >>I have a question about a codec negotiation. >>During H.245 negotiation, endpoint A (master) exports
g711A-law
with
> > packetization 80, endpoint B (slave) exports g711A-law with > packetization 30. After that, endpoint A opens a channel
with
> packetization = 20 ms. Endpoint B acknoledges the OLC and
tries
to
open
> a channel with packetization = 30 ms. > >>Here Endpoint A rejects the OLC and the call is disengaged. >> >>Does anybody can tell me which endpoint dosn't behave
according
to
> > the H323 standard? > >>Thank you in advance. >> >>Davide > > > --- > You are currently subscribed to h323forum as: cwp@isdn-
comms.co.uk
> To unsubscribe send a blank email to %%email.unsub%% >
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down
Road
Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
You are currently subscribed to h323forum as:
equival@equival.com.au
To unsubscribe send a blank email to %%email.unsub%%
Robert Jongbloed Equivalence Pty. Ltd. Architect Open Phone Abstraction Library (OPAL) & OpenH323 Open Source Telecommunication Protocol Libraries
Quicknet's revolutionary MicroTelco Services offers LOW WORLDWIDE RATES ANY TIME OF THE DAY with No monthly fees! No monthly minimums! No connection fees! US rates as low as 2.9 cents a minute! To see more rates, visit www.microtelco.com
****LIVE VIDEO CONFERENCE NOW AVAILABLE***** CUseeMe v5.0 software is an affordable easy-to-use software application providing live visual communication between friends, family and colleagues worldwide. To learn more, visit, www.cuseemeworld.com
You are currently subscribed to h323forum as: paulej@packetizer.com To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to h323forum as:
deniseshull@sbcglobal.net
To unsubscribe send a blank email to leave-h323forum-30418E@mail.imtc.org
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com
_______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt
Denise/Paul,
By Scheduling do you mean "re-ordering" the out-of-order packets?
If so, then there is an ongoing effort in AVT that addresses this as part of the Enhanced CRTP in this draft:
http://www.ietf.org/internet-drafts/draft-ietf-avt-crtp-enhance-05.txt
Thanks, Bala
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Tuesday, December 17, 2002 5:58 PM To: bs@utstar.com; 'Denise Shull'; ITU-SG16@echo.jf.INTEL.COM Subject: Re: [h323forum] Re: Codec negotiation question
Bala,
This is certainly a good document to consider. Looking at it briefly, I did have a number of questions as to how this would signaled to the other end. I assume that perhaps two GWs are configured to know about each other and whenever a call is routed between them, it's just a given that the RTP traffic is dropped into this tunnel... you might be able to clarify that.
In any case, the scope of this work may be that it does not define protocols, but simply specify how existing protocols might be used in the context of H.323 and/or H.248. Certainly, I would say that the possibility to have more than one way to do it should be considered... this document definitely does not consideration to what Denise had mentioned. ("Scheduling", for example, would be something to discuss in context of this or another protocol that solves the same type problem.)
Paul
----- Original Message ----- From: "Balasubramanian Pitchandi" bs@utstar.com To: "'Denise Shull'" deniseshull@SBCGLOBAL.NET; ITU-SG16@echo.jf.INTEL.COM; paulej@packetizer.com Sent: Tuesday, December 17, 2002 4:42 PM Subject: RE: [h323forum] Re: Codec negotiation question
You can look at the IETF AVT Working group's draft on TCRTP:
http://www.ietf.org/internet-drafts/draft-ietf-avt-tcrtp-07.txt
It's a mature protocol being implemented (or already implemented) by handful of vendors.
Thanks, Bala
-----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@echo.jf.INTEL.COM] On Behalf Of Denise Shull Sent: Tuesday, December 17, 2002 3:56 PM To: ITU-SG16@echo.jf.INTEL.COM Subject: Re: [h323forum] Re: Codec negotiation question
Trying to not 'plug' any company or technology in this arena, however,
I
am doing a consulting project for a company that schedules the packets
-
versus prioritizing them. They are in beta mode but their tests
reveal
a very effective method for delivering video with greatly reduced latency and jitter.
It would be useful to be able to have input from this group both on
the
idea and on their technology specifically.
Regards, Denise
Denise K. Shull SHULL ADVISORS, LLC Strategic Application of Meeting Technologies 646-498-6403 www.videooverip.biz
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Monday, December 16, 2002 8:04 PM To: Paul Long; h323forum@mail.imtc.org; ITU-SG16@echo.jf.INTEL.COM Subject: [h323forum] Re: Codec negotiation question
Paul,
Do you mean RFC 2508?
In any case, Robert's point is indeed valid. This is where having a specialize GW that multiplexes the RTP streams for delivery over the long-haul is something practical.
Perhaps we could take that up as a work item with SG16? It would be reasonable to specify how such an Gateway might function in order to trunk a large number of active calls over long distance. Anyone interested in such a work item?
Paul
----- Original Message ----- From: "Paul Long" plong@packetizer.com To: h323forum@mail.imtc.org Sent: Monday, December 16, 2002 7:49 PM Subject: [h323forum] Re: Codec negotiation question
Robert,
Excellent point. I hadn't thought of that. I wonder what happened to cRTP. Anybody know? That would sure help.
Paul
On Mon, 16 Dec 2002 12:53:34 -0500 "Paul Long" plong@packetizer.com wrote:
I know lots of folks would like a means of expressing exact packetization, but isn't the solution trivial? All you need is a
small
FIFO and a few lines of code to re-packetize according to any
internal
requirements. Just write incoming frames regardless of size,
e.g.,
30fpp, to the FIFO, and read whatever size frames you want,
e.g.,
80fpp
from the FIFO (only read if there are at least X fpp in the
FIFO).
DSP hardware is not the only reason for wanting to have the remote endpoint send larger packets. We have many clients on long haul
internet
links (300ms+ ping times), often with a slow tail circuit (ISDN or
even
modem) and you REALLY want the other end to send more than one
G.723.1
frame per packet to reduce the significant overhead that there is
in
the
RTP.
It is unfortunate but true that there is no way of expressing
a
minimum
acceptable number of frames per packet.
Regards, Chris
Paul Long wrote:
Davide,
There is nothing in the standard that requires the
acceptance
of an
OLC
or precludes terminating the call for any reason whatsoever
so
both
EPs
are technically compliant.
Packetization in TCS and OLC expresses the _maximum_ frames
per
packet,
but several vendors don't understand this simple concept and
continue
to produce products that expect an exact packetization.
There
is a
good
chance that that is why EP A is rejecting the OLC. It wants
the
channel
opened at exactly 80fpp, although there is no way to express
this
in
H.323. IMO, if this is the reason, that product is broken.
Paul
>Hi all, > >I have a question about a codec negotiation. >During H.245 negotiation, endpoint A (master) exports
g711A-law
with
packetization 80, endpoint B (slave) exports g711A-law with packetization 30. After that, endpoint A opens a channel
with
packetization = 20 ms. Endpoint B acknoledges the OLC and
tries
to
open
a channel with packetization = 30 ms.
>Here Endpoint A rejects the OLC and the call is disengaged. > >Does anybody can tell me which endpoint dosn't behave
according
to
the H323 standard?
>Thank you in advance. > >Davide
You are currently subscribed to h323forum as: cwp@isdn-
comms.co.uk
To unsubscribe send a blank email to %%email.unsub%%
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down
Road
Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
You are currently subscribed to h323forum as:
equival@equival.com.au
To unsubscribe send a blank email to %%email.unsub%%
Robert Jongbloed Equivalence Pty. Ltd. Architect Open Phone Abstraction Library (OPAL) & OpenH323 Open Source Telecommunication Protocol Libraries
Quicknet's revolutionary MicroTelco Services offers LOW WORLDWIDE RATES ANY TIME OF THE DAY with No monthly fees! No monthly minimums! No connection fees! US rates as low as 2.9 cents a minute! To see more rates, visit www.microtelco.com
****LIVE VIDEO CONFERENCE NOW AVAILABLE***** CUseeMe v5.0 software is an affordable easy-to-use software application providing live visual communication between friends, family and colleagues worldwide. To learn more, visit, www.cuseemeworld.com
You are currently subscribed to h323forum as: paulej@packetizer.com To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to h323forum as:
deniseshull@sbcglobal.net
To unsubscribe send a blank email to leave-h323forum-30418E@mail.imtc.org
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com
participants (4)
-
Balasubramanian Pitchandi -
Denise Shull -
Paul E. Jones -
Paul E. Jones