Re: [SIP] SIP - H.323 - INVITE - No media line.

Vladislav Zubarev <vladis@vovida.com> Tue, 14 November 2000 21:41 UTC

Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09250 for <sip-archive@odin.ietf.org>; Tue, 14 Nov 2000 16:41:02 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8E15744341; Tue, 14 Nov 2000 15:41:07 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from pigeon.vovida.com (a98.vovida.com [209.237.8.98]) by lists.bell-labs.com (Postfix) with ESMTP id 7E3264433D for <sip@lists.bell-labs.com>; Tue, 14 Nov 2000 15:40:57 -0500 (EST)
Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com (Netscape Messaging Server 4.15) with ESMTP id G41AE400.VT7; Tue, 14 Nov 2000 13:30:04 -0800
Message-ID: <3A11B160.9AADB401@vovida.com>
From: Vladislav Zubarev <vladis@vovida.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: en, ru
MIME-Version: 1.0
To: Maddux Michel <Michel.Maddux@COMPAQ.com>
Cc: sip@lists.bell-labs.com, Lawhorn Tom <Tom.Lawhorn@COMPAQ.com>, Byrne Sam <Sam.Byrne@COMPAQ.com>, Hurlbert John <john.hurlbert@COMPAQ.com>
Subject: Re: [SIP] SIP - H.323 - INVITE - No media line.
References: <202F03744BDCD31194270000F803CA9E770111@cxoexc2.cxo.dec.com>
Content-Type: multipart/alternative; boundary="------------76858BE3241BF9867A9908A9"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 14 Nov 2000 13:40:48 -0800

The annswers to most of your question in developing such a gateway you
can find in:

http://search.ietf.org/internet-drafts/draft-singh-sip-h323-01.txt

Have fun. :)

"Maddux, Michel" wrote:

> In constructing a gateway connecting Sip to 323, the process of signalling a
> call and then negotiating channels, for a Sip caller to 323 callee, is
> relatively straightforward. Only one temporizing step is required, and that
> is to not provide an RTCP address in opening channels from gateway (actually
> Sip) to 323 callee.
>
> The reverse case, of implementing 323 caller to Sip callee, is not so
> straightforward. Signalling is tractable, but media channel negotiation is
> murky. Two models occur:
>
> 1) When 323 calls, wait until it opens first media channel. Then issue the
> INVITE, noting only a media line of that media type but with a phony port.
> When Sip replies (200 OK presumed), complete the 323 media channel being
> negotiated, giving it the Sip's media port. Then negotiate the reverse
> channel with 323, saving its port, which is then transmitted to Sip via an
> ACK with a message body correcting the 323 media port. If the 323 caller
> then opens another media channel, repeat the above process via re-INVITE,
> and continue to do so as long as 323 requests media channels.
>
> 2) Depend upon language from the 2543 spec, particularly section B.4 and the
> ACK section, which state that an INVITE could be sent with NO media lines,
> upon receipt of which the Sip callee would respond with a list of its
> supported media (AND presumably providing a port for each of these). In this
> scenario, an INVITE devoid of media would be issued immediately on receipt
> of call from the 323 caller. The resulting 200 OK media list would then be
> used to negotiate the media channels with the 323 caller, and would be
> returned in final form in the message body of the ACK. [It is possible that
> this model would devolve to the first model since it is not known when the
> 323 caller is through opening channels. Should a mid-call media change be
> initiated by the 323 caller, the re-INVITE process would need be used,
> anyway.]
>
> We are interested in a recommendation as to how to do this. Are either of
> the above models viable, or does a better model exist? What is the spec
> status of section B.4?
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

--
Vladislav Zubarev        mailto:vladis@vovida.com
Software Engineer
Vovida Networks, Inc.    http://www.vovida.com