Job Opportunity for H.323/SIP Protocol Engineer

[Voip 4U]

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 at utstar.com>
To: "'Paul E. Jones'" <paulej at packetizer.com>; "'Denise Shull'"
<deniseshull at SBCGLOBAL.NET>; <ITU-SG16 at echo.jf.INTEL.COM>
Cc: <avt at 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 at packetizer.com]
> Sent: Tuesday, December 17, 2002 5:58 PM
> To: bs at utstar.com; 'Denise Shull'; ITU-SG16 at 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 at utstar.com>
> To: "'Denise Shull'" <deniseshull at SBCGLOBAL.NET>;
> <ITU-SG16 at echo.jf.INTEL.COM>; <paulej at 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 at echo.jf.INTEL.COM] On Behalf Of Denise Shull
> > Sent: Tuesday, December 17, 2002 3:56 PM
> > To: ITU-SG16 at 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 at packetizer.com]
> > Sent: Monday, December 16, 2002 8:04 PM
> > To: Paul Long; h323forum at mail.imtc.org; ITU-SG16 at 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 at packetizer.com>
> > To: <h323forum at 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 at 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 at 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 at 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 at packetizer.com
> > > To unsubscribe send a blank email to %%email.unsub%%
> > >
> >
> >
> > ---
> > You are currently subscribed to h323forum as:
> deniseshull at sbcglobal.net
> > To unsubscribe send a blank email to
> > leave-h323forum-30418E at mail.imtc.org
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at lists.intel.com
> >
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at lists.intel.com