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@INTEL.COM] Sent: Thursday, April 15, 1999 4:37 PM To: ITU-SG16@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@ATTMAIL.COM] Sent: Wednesday, April 14, 1999 7:04 PM To: ITU-SG16@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@videoserver.com mailto:bhill@videoserver.com
Dear sirs,
In the document
RTP Profile for Audio and Video Conferences with Minimal Control
There are description for several codecs, among them, GSM. But in H323 Version1/ V245 Version 2, there is no way to choose this codec.
¿Is there any way to work withs RTP "standard" codecs but H323-NON-standard codecs.
Thanks a lot,
Juan C Uribe G
Juan,
I think you will find that the three GSM codecs are included in later versions of H.323 and H.245. Other codecs presently covered in RTP and not specified in H.323 can be signalled using the non-standards information fields in H.245.
Regards,
Mike Buckley
____________________ Begin Original Message ___________________________ Date: Fri Apr 16 10:37:04 -0500 1999 From: internet!ALPHA.TELECOM-CO.NET!juribe (Juan C Uribe G) Subject: A non-standard codec To: internet!MAILBAG.INTEL.COM!ITU-SG16 Content-Type: Generic-Text Content-Length: 361
Dear sirs,
In the document
RTP Profile for Audio and Video Conferences with Minimal Control
There are description for several codecs, among them, GSM. But in H323 Version1/ V245 Version 2, there is no way to choose this codec.
¿Is there any way to work withs RTP "standard" codecs but H323-NON-standard codecs.
Thanks a lot,
Juan C Uribe G
participants (2)
-
Juan C Uribe G
-
Mike Buckley