Subject: Multiple SDPs in INVITE necessary to support H.323 interop ?

From: Eirik Maus <[email-masked]>
Date: Wed, 19 Aug 1998 12:09:47 +0200

Hi

I'm writing a little piece on possibilities for H.323 and SIP
interoperation. 
I would very much appreciate if anyone bothered to confirm the
statements about SIP / SDP below:

H.323 media capability negotioations consist of AlternativeCapabilitySet
structures listing a set of formats among which you are allowed to
choose one. This corresponds to the format list in the SDP m= ....<fmt
lst> field. 

The AlternativeCapSets are wrapped inside SimultaneousCapabilities
structures to express that a terminal is capable of simultaneously
render one of these {...} and one of these {...}. 
This is equal to have several m= <media> fields in the SDP capabilities
in SIP format negotioations.

In H.323 the capability negotioation packages "CapabilityDescriptor" may
consist of several SimultaneousCaps for you to choose among. The H.323
standard (v2) provides the following example of what you may express:

Either:
{
	Simultaneously:
	{
		One of: {G.711 or G.723.1 or G.728}
	And
		One of: {H.261 or H.263}
	And	
		One of: {H.261}
	}
Or
	Simultaneously:
	{
		One of: {H.262}
	And
		One of: {G.711}
	}
}

Statements:

a) 
You cannot express the equivalence of several simultaneous capability
sets in a single SDP message. You can merge all simultaneous capabilites
into one set by inserting a lot m=<media> fields. But this is an
incorrect translation. 

b)
The only way to preserve the intent is to have one SDP message for each
of the simultaneous capabilities. But there is no way of expressing that
you only are allowed to choose one of these. 
This is however a less bad solution than merging all SimCap sets or
omitting all but the first SimCap set. 

c)
You cannot create a 100% conformant gateway between SIP and H.323
without being able to translate media negotiations back and forth. The
only way to support full SIP - H.323 interoparation is to have end
systems being able to agree on setting up the call/session using one or
the other standard. Both/all end systems have to support both standards
to a certain extent (at least to be able to say "lets switch to the
other standard"). 

d)
There are two ways of dealing with this problem inside SIP. Neither may
work on systems not prepared for them. 

d-1) Embed several SDPs in the INVITE (or ACK, as H.323 negotiate media
after the equivalence of 200 OK is received). There is no expected
support for Content-Type multipart, and no header for defining the
border between the different parts. The SDP parser will have to discover
that the content consist of several SDP messages. SDP parsers that are
not prepared for several consecutive SDP messages in the same text will
think that the text contains a malformed SDP message and probably return
Error. 

d-2)
Create several SDP messages. Send several INVITE's in parallell each
with a different Call-Id and SDP message. This is a unelegant and stupid
solution, but it might work. This may result in several parallell
sessions between the two hosts, but that is a minor problem. Unless
bandwidth reservation is messed up. 

Please tell me H.323 and SIP interoperation is possible. 
BR

Eirik Maus
Norwegian Computing Center

---

From: Mark Handley <[email-masked]>
Date: Wed, 19 Aug 1998 11:10:43 -0400

>		One of: {G.711 or G.723.1 or G.728}

I haven't spent a lot of time thinking about SIP/H.323 interaction,
but now that SIP is no longer a moving target, I think it would be
good to look at these issues, and possibly write an internet draft or
two on the issues.

One approach would be using SIP to do H.323 call initiation, (in place
of Q.931 and possibly H.245) but that isn't what you're asking about
here.

The other approach is SIP/H.323 gateways, which is the context in
which you raise this issue.  I should say I'm not an H.323 expert, so
please correct me if I've misunderstood H.323 mechanisms.

It doesn't seem that there is a problem with a SIP request being
gatewayed to an H.323 terminal.  The request passes through unchanged,
a capability set is returned from the H.323 terminal.  If the set of
media is the same and the set of formats can form a subset of those in
the request, then the gateway returns 200 OK, and informs the H.323
terminal of subset the gateway chose.

When the gateway is relaying an H.323 call to a SIP terminal, there is
(currently) insufficient expressiveness in SDP to express H.245
negotiation in one request as you say.  However, I assume the ordering
of the capabilities is in the caller's prefered order (or there's some
other information to decide this) otherwise an H.323 callee can't make
an informed decision.  If this is the case, the gateway simply chooses
the first of the alternative sets in the H.245 message, and puts that
in the SIP INVITE request.  Either the SIP terminal can participate,
and returns 200 OK, or it can't and returns 408 Unacceptable.  If it's
the latter, the gateway looks at the response, and if it can find a
common subset, it sends another INVITE request with a new SDP
description matching the best match from the other H.245 alternatives.
This is standard SIP negotiation - send a request, get it refused,
look at the response, and send a modified request.

Thus the gateway has to be active not passive (there's not a
one-to-one mapping of messages), but it seems like this should be
possible without changes to H.323, SIP or SDP.

Of course SIP can also carry other session description formats, but it
doesn't seem necessary in this case.

Cheers,
	Mark

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Aug 1998 12:58:43 -0400

> statements about SIP / SDP below:

The issues you identify are primarily SDP issues, not really SIP issues.

We have not currently identified MIME multipart messages for SIP, but
PINT is proposing to use these already, so that may be an easy
alternative.

Given that most existing H.323 systems are not using the H.245
capabilities (as far as I know) beyond a single list, it might be
sufficient to put this item on the list of extensions for the next
(draft-standard) version of SIP.

Obviously, there's also been the suggestion (by Philip Hoschka) of
extending SMIL for this purpose. It has a somewhat richer set of ways of
expressing conjuctions and disjunctions of capabilities.

Your 'd-2' suggestion can be done in sequence, assuming that the list of
alternatives is not likely to be large.

---

From: Christoph Reichert <[email-masked]>
Date: Wed, 19 Aug 1998 19:09:26 +0200

> look at the response, and send a modified request.

And this will take its time.
H.323 has been reworked (H.323v2) this year, with the following in mind:

1. Open a TCP connection
2. Do Q.931 signalling 
3. Do H.245 Master-slave-negotiation
4. Do H.245 Capability exchange
5. Open the logical channels (i.e. start the applications)

This results in many handshakes, and it will take a while until you see
or hear your partner.  So, one improvement in H.323v2 was that most of
the various PDUs are gathered and transmitted in one "jumbo paket".

Generally, I think it would be better to use a kind of multicast capable
session control protocol (SCP???), announce it as a normal application
in the SDP-record, and let it do the job after the invitee has joined
the session.  This also makes it possible to renegotiate the capabilities,
for example, when another member joins the session.

Every member should announce its capabilities, and every member should
intersect these capability sets of all other members. The common subset
can be used for interoperable communication. If the subset is empty, you
loose.  Renegotiation can be done easily and fully distributed: Multicast
the new capability set, and everybody recomputes the subset. This takes
only one message.

Also, one of these capabilities should be a (sub)set of the available
port numbers on a member's host. I tried to setup a session via sdr,
and vic could not be lauched on the other host, because the port number
was already in use.  I don't talk about sessions in the order like
IETF-Meetings, I talk about just TWO members :-)

cheers, chris

---

From: Christian Huitema <[email-masked]>
Date: Wed, 19 Aug 1998 14:18:34 -0400 (EDT)

As Henning points out, this is really a question about matching SDP and
H.245, not so much SIP and H.323.  I studied the SDP/H.245 matching as
part of the analysis of SGCP; you can find the result in:
	http://sgcp.bellcore.com/SGCPf323.html
Note that this study assumes that the H.323 "fast start" procedure is
used. In one direction, the SDP announcement is translated in a list of
openLogicalChannel proposals, assuming that the encodings on the "m=" line
are listed by order of preference.  In the other direction, the same is
done with the first proposition.

If the fast start fails, one has indeed to fall back to the full H.245
exchange.

-- 
Christian Huitema

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Aug 1998 15:29:11 -0400

> for example, when another member joins the session.

Hmm. This sort of sounds like the original H.323v1 approach of first
doing the signaling, and then the capabilities exchange later via a
separate protocol. As you mention, this costs round trip times, which is
why Fast Start has been proposed for v2. Why go back to it? 

> the new capability set, and everybody recomputes the subset. This takes

This is not quite so easy. It requires reliable multicast in general,
and as the conference state is not explicitly transmitted, late joining
members don't see the full spectrum of capabilities, and thus won't
compute the same intersection. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Christoph Reichert <[email-masked]>
Date: Wed, 19 Aug 1998 22:33:10 +0200

> why Fast Start has been proposed for v2. Why go back to it? 

As you should  do authentication/key exchange etc befor you can decrypt the
the capablity sets.

> This is not quite so easy. It requires reliable multicast in general,

Yes, it requires reliable multicast of the same way as the wb-tool 
requires it, i.e. normally small packets with potential large intervalls.
SRM could be used to carry SCP messages.

> compute the same intersection. 

This is another reason for first joining the session.
Since every member got all other capability sets, one of these members
can send him the session state including the capsets. On the other side,
the new member announces its capset.

Yes, there are probably to much capsets to hold by each member :-(

cheers, chris

---

From: Christian Huitema <[email-masked]>
Date: Wed, 19 Aug 1998 17:38:59 -0400 (EDT)

Frankly, I don't think that we should get polarized on the "capability set"
problem.  The idea that everything can be negotiated to death was one of
the prime feature of the OSI model, and did not help these protocols
to succeed.

In practice, we will only get interoperability if we manage to find a 
common set of acceptable capabilities, that most stations in a conference
are likely to support.  The negotiation, if any, will only occur in phases
of transition.

Also, one should recognize the fact that H.323 is based on the very
rigid conference controls defined in H.320, while SDP and SIP are based
on a much looser model.  There is certainly no need to go overboard in
trying to match the two sets.

-- 
Christian Huitema