H.245 vs. SDP

Gur Kimchi Gur_Kimchi at VOCALTEC.COM
Fri Apr 16 20:07:45 EDT 1999


Actually, we can look at this from another angle.  For H.GCP, the main
protocol suite to
interwork with (and work within) is H.323 - not SIP.  There is a strong
parallel between H.245
and H.GCP as it currently stands, with the exception of the use of SDP.
Any effort to ignore
H.323 interworking in this group will have the same effect as ignoring SIP
in MMUSIC ;-)

The following are simple to map between ISUP-over-IP/GCP and H.225/H.245
systems:

Function                 H.245                H.GCP (Megaco Design Group
Draft)
------------------------------------------------------------------------
Capabilities Exchange    CapsExchange         Audit
Connection Creation      OpenLogicalChannel   Add
Connection Modification  ReplacmentFor OLC    Modify
Connection Deletion      CloseLogicalChannel  Subtract
Connection Moving        ReplacmentFor OLC    Move

So it is simple to have a Gateway between the two models.  We can
extrapolate
further as we could actually look at H.GCP as doing the same things as
H.245 - think
of it as a text based alternative to H.245, so we can imagine the following
models:

                       current SIP  --> future SIP   | current 323  -->
future 323
+--------------------+---------------+---------------+---------------
+---------------+
| service signalling |   SIP         |  SIP          |  Annex G      |
Annex G       |
+--------------------+---------------+---------------+
---------------+---------------+
| call signalling    |    SIP        |   SIP         |   H.225/Q.931 |
H.225/Q.931  |
+--------------------+---------------+---------------+
---------------+---------------+
| connection control |     none      |    GCP        |    H.245      |
GCP         |
+--------------------+---------------+---------------+
---------------+---------------+
| media transmission |      RTP/RTCP |     RTP/RTCP  |     RTP/RTCP  |
RTP/RTCP   |
+--------------------+---------------+---------------+
---------------+---------------+

Further, H.GCP after all is just a method to decompose gateways, nothing
else, so it
will be used to construct logical gatways.  These gatways MUST interoperate
with any
other H.323 host - and they cannot when using SDP.

+--------------------+          +--------------------+
|         MGC        |<---245-->|                    |
+--------------------+          |                    |
           |                    |                    |
          GCP                   |   Simple Gateway   |
           |                    |                    |
+--------------------+          |                    |
|         MG         |          |                    |
+--------------------+          +--------------------+

SDP is just not expressive enough for the products many of us are trying to
build.
Like or not, the mutex and simultaneous capabilities descriptors in H.245
are there
for a purpose - as many systems have limitations that need to be expressed.
having
to design MG hardware to cope with SDP limitations is not the correct
answer.

A possible solution is create an ASN.1 Text Encoding Rules (TER?  I seem to
remember
some old work that called this NER) for H.245 that will create tables of
structure.name=value pairs.  This will allow people to build systems with
practically no ASN compilers, and allow simple over-the-wire debugging.
This H.245
encoding in TER should be used in H.GCP instead of SDP.

Bottom line?  We can build SDP to H.245 translators, but there is no way to
build full
H.245 to SDP translators - SDP is just too limited.

I hope that at the end of this difficult, and sometimes painful exercise of
decomposing the
gateway we dont find ourselves designing a less-capabile gateway then what
we had before...

I am afraid MMUSIC will come to the same conclusion at some point, and will
have to
invent a new SDP that allows multi-dimensional (maybe with AND/OR/NOT
qualifiers) -
but this is clearly beyond the scope, and schedule, of the H.GCP work.

- gur

______________________________________________________________________
   Gur Kimchi
   Corporate Director, Advance Technologies, Research and Standards
   VocalTec Communications Ltd
   web: http://www.vocaltec.com

-------- On 04/16/99 03:50 PM GMT  Mike Buckley <mikebuckley at ATTMAIL.COM>
wrote:



Thanks for the clarification Tom.  This is exactly what I meant.
I agree that caps exchange will generally be a registration process.
However I
would pose a question whether there might not be a need for a caps exchange
after registration to identify resources temporarily unavailable (traffic
loading etc)
or unavailable in a specific set of circumstances.  Also is there a role
for a caps
exchange to change parameters during a session? This might be particularly
important in multimedia situations.
Mike
____________________ Begin Original Message
___________________________
Date: Fri Apr 16 09:24:57 -0400 1999
From: internet!NORTELNETWORKS.COM!taylor (Tom-PT Taylor)
Subject: H.245 vs. SDP
To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO
Content-Type: Generic-Text
Content-Length: 4210
I would like to clarify the issue of H.245 vs. SDP.  First off, what we are
talking about here is NOT capability negotiation.  The latter is handled by
signalling between MGCs.  A given MGC obtains the information needed to
support its end of the negotiation through use of the Audit command.
Megaco/H.GCP has the action to ensure that responses to Audit commands
convey the necessary information.
That said, the question becomes one of SDP vs. the H.245 OpenLogicalChannel
(OLC) and OLC Ack structures.  I think what Mike is saying is that there
are
two issues in this discussion: content, and ordering of that content.
On content, I think we can get general agreement that if the H.245 OLC can
request something, the Media Gateway control protocol should be able to
propagate that request to the MG.  Thus there is no argument in general
over
content, leaving aside housekeeping items like the H.245 logical channel
number which may be irrelevant to the MG.
The contentious point is therefore one of how the individual parameters
should be ordered.  What I suggest is that we see through example how they
are used, then decide on ordering.  We will probably find that there is a
dependency here on how we use contexts to represent multimedia.  A
single-medium context corresponds to one (bidirectional) or two
unidirectional H.245 logical channels.  There is an issue here: how does
the
MGC correlate the second logical channel with the first one?  Do we end up
with a separate context for each H.245 logical channel?   A multimedia
context corresponds to a number of logical channels, but the correlation
rules are simpler: all logical channels associated with the same call
(H.323
definition) are grouped together.
> -----Original Message-----
> From: Kumar, Vineet [SMTP:vineet.kumar at INTEL.COM]
> Sent: Thursday, April 15, 1999 4:37 PM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      Re: H.GCP draft uploaded
>
> I agree with Mike in using H.245 between MGC and MG. SDP is essentially
> used
> for advertising loosely coupled sessions, so it does not have the
> functionality necessary to be considered in H.GCP. Also, H.GCP must
re-use
> H.323 components whenever possible.
>
> vineet
>
> -----Original Message-----
> From: Mike Buckley [mailto:mikebuckley at ATTMAIL.COM]
> Sent: Wednesday, April 14, 1999 7:04 PM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: H.GCP draft uploaded
>
>
> Bryan,
>
> I don't know whether this is the right place to comment on the Draft.  I
> have also
> copied some of these comments to the megaco list.
>
> I would like to see the use of SDP between the MGC and MG added to the
> issues list.  My understanding is that the symantics and syntax of SDP
are
> different from H.245OLC.  Use of SDP in H.gcp will therefore involve a
> reordering
> of the information sent in H.245 between endpoints.  This will add
> transcoding
> complexity and latency.  In addition, all the features of H.245 I believe
> cannot be
> presently supported in SDP.  For maximum efficiency and flexibility
> therefore
> I think the mechanism used to convey capabilities should mirror the
> semantics
> and syntax of H.245OLC.  I don't believe there is any extra overhead in
> adopting this approach over SDP.  The coding used may be different from
> PER
> or
> BER.
>
> I think this also fits in with the list of H.gcp requirements where it is
> stated that
> all the features of H.245 should be supported.
>
> Mike
>
> ____________________ Begin Original Message
> ___________________________
> Date: Tue Apr 13 08:57:37 -0400 1999
> From: internet!VIDEOSERVER.COM!bhill (Bryan Hill)
> Subject: H.GCP draft uploaded
> To: internet!MAILBAG.INTEL.COM!ITU-SG16
> Content-Type: Text
> Content-Length: 367
>
> Mr. Okubo,
> Please find a version of HGCP.doc and HGCP.zip that I have uploaded into
> the
> ptel incoming site.  These are drafts of the contribution I am preparing
> for
> Santiago.
>
> Best Regards,
> Bryan Hill
> _________________________________________________________
> Bryan Hill
> VideoServer Inc.
> (781) 505-2159
> bhill at videoserver.com <mailto:bhill at videoserver.com>



More information about the sg16-avd mailing list