August 1999 - sg16-avd - lists.packetizer.com

[Fwd: Re: Transport layer interface]
by Christian Groves 20 Aug '99

20 Aug '99

Hello, For those interested there are some discussions on the IETF Megaco list about removing/modifying the sections added in Berlin in H.248 on non-IP signalling transport. My response is below. Cheers, Christian -------- Original Message -------- Subject: Re: Transport layer interface Date: Thu, 19 Aug 1999 17:36:13 +1000 From: Christian Groves <Christian.Groves(a)ERICSSON.COM> Reply-To: Christian Groves <Christian.Groves(a)ERICSSON.COM> To: MEGACO(a)STANDARDS.NORTELNETWORKS.COM References: <21565C751365D211BB2D0060089624CC112B65@TERRA> G'Day all, Seeing my name was mentioned several times I guess I better speak up on this issue. There were a number of points: 1. A contribution was made to be able to use H.248 across non-IP transport technologies 2. The rational is that if you have a gateway with ATM, AAL2 etc you may not want an IP signalling transpport. 3. The layered approach was introduced as a way of doing this. 4. I recognise that IP is the current and primary means of deploying H.248 I wanted to document H.248 a way that allows continued developed of the protocol without having to delay it whilst adding seperate transport technologies. 5. We wanted the H.248/Megaco specification NOT to be tied to an IP transport technology that is why we proposed the changes to the document structure to allow the actual protocol (procedures & symantics) to be separated from the transport issues. 6. ALF is tied to IP and is not suitable to other transport technologies this I think is reflected in the specification 7. I think it was agreed in the Berlin meeting (the italics section) of the document that ALF and TCP transport sections should be re-written to make them sound like a protocol document rather than a educational peice of writing. We suggested some headings. 8. We made no attempt to change the technical parts of the ALF and TCP sections the changes we proposed were to aid clarity. 9. I was not at the Oslo meeting however I understand that there was still discussion of the transport issues after this meeting as the outcome was not clear. 10. If we don't do this then another device control protocol will be defined for ATM based MGs and we'll end up with the situation where we have 2 procedurally and symantically different media gateway control protocols. This will cost. Its better to have to have the same protocol. Therefore I feel strongly that the sections regarding non-IP transport should remain. Hopefully I've captured most of the points from this thread. Cheers, Christian Brian Rosen wrote: > > I'll point out again that the layer is not appropriate for > ALF under non IP transport. So it would have to be something like: > > "The following section illustrates a possible way to define the interface > between the protocol implementation and a non-IP > transport where Application Level Framing does not need to > interact with the order messages are actually sent. This > section is informative and implementations need not follow it" > > Given that, it has no business taking up space in the document. > > Brian > > > -----Original Message----- > > From: Hong Liu [mailto:lhong@RESEARCH.TELCORDIA.COM] > > Sent: Thursday, August 19, 1999 10:26 AM > > To: MEGACO(a)standards.nortelnetworks.com > > Subject: Re: Transport layer interface > > > > > > Rex, > > > > I think what Tom meant by "consensus" was from all the > > participants in the Oslo > > meeting. In that sense, it was a consensus from that meeting. > > Of course, > > Christian Grove was not in that meeting, and his contribution > > in Berlin reflects > > a different opinion in this topic. > > > > I remember that the transport issue was indeed discussed in > > Berlin around 4:00am. > > Instead of debating the pros and cons then, the group decided > > to just put the > > text in for further discussion on the list. In other words, > > the intent was not to > > reflect any agreement reached in Berlin, rather it was to > > capture the issue. > > Maybe Nancy or John can comment on this. > > > > Chip made the point a number of times in the meeting that the > > proposed sublayer, > > if added, shall be put in a separate session for "non-IP" > > transport. I think this > > is a reasonable proposal for compromise. It seems to me that > > this is also what > > the many people think from the emails I read along this thread. > > > > --Hong > > > > Rex Coldren wrote: > > > > > Tom, > > > The one thing you would see that indicates that Oslo > > didn't capture > > > consensus is the proposal from Christian Groves and the reaction to > > > it in Berlin. The discussion went on for a while. > > Unfortunately I don't > > > remember the exact outcome. Working all night tends to blur things. > > > Perhaps Christian can summarize for us what was agreed or wasn't > > > agreed to at that meeting before we kill the idea on the list. > > > > > > Rex > > > > > > Tom-PT Taylor wrote: > > > > > > > I kind of agree that this one is surplus to requirements. > > It's main point > > > > would be to provide a hook for transport evolution (e.g. > > to Sigtran), if we > > > > saw that in our future, but we should probably let the > > future take care of > > > > itself. This was an issue over which we took > > considerable pains at Oslo, > > > > and I haven't seen anything on the list to make me think > > Oslo failed to > > > > capture consensus. > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [SMTP:brosen@ENG.FORE.COM] > > > > > Sent: Wednesday, August 18, 1999 5:51 PM > > > > > To: megaco(a)standards.nortelnetworks.com > > > > > Subject: Transport layer interface > > > > > > > > > > Berlin inserted a concept that was discussed and discarded > > > > > in the IETF process; defining a transport independent interface > > > > > to the transport layer. The layer defines a set of primitives > > > > > to be used between the protocol implementation and any transport > > > > > layer. The goal is to maximize interoperability, and to permit > > > > > transport over non-IP networks. > > > > > > > > > > One of the major benefits of ALF is that it allows the > > application > > > > > to make dynamic decisions on sending of messages in the face of > > > > > congestion. You could, for example, queue a message, discover > > > > > there was congestion, and decide to send > > > > > another message before the enqueued message. You could even > > > > > decide to not send the message at all. The application > > > > > may make these decisions. Layered interfaces that only have > > > > > simple "transfer" primitives cannot provide this kind of > > > > > reaction to congestion. > > > > > > > > > > For that reason, I question an attempt to provide a transport > > > > > independent layer. The current wording is not sufficient, as > > > > > the comments point out, and there are no submissions that > > > > > would get us to a complete description. > > > > > > > > > > The sections on transport using ALF and transport using TCP > > > > > are, I think, satisfactory without the extra layer. Any > > > > > additional transports, IP based or not, could be defined in > > > > > subsequent editions, or in separate documents without a layer > > > > > definition. Since there is not any claimed desire to be able to > > > > > have a literal "plug this protocol code into that > > transport code", > > > > > I don't think we will miss it. > > > > > > > > > > > > > > > What to do? > > > > > > > > > > Brian > > > > > ------------ > > > > > Brian Rosen, Principal Engineer > > > > > FORE Systems, 1000 FORE Drive, Warrendale, PA 15086 > > > > > (724) 742-6826 mailto:brosen@eng.fore.com > >

1 0

H.245 CommunicationModeCommand question
by pjh 19 Aug '99

19 Aug '99

Hi everyone in multipoint conference, when the terminal joining the conference has received the H.245 CommunicationModeCommand from MC, Should we open logical channels using the OpenLogicalChannel-OpenLogicalChannelAck sequence? Best Regards Jihye Park(Miss) Nada Research Co., Ltd. Seoul 137-070 , Korea Tel: 82-2-525-3941 Fax: 82-2-525-3945 pjh(a)deskview.nada.co.kr <mailto:pjh@deskview.nada.co.kr>

1 0

H.245 CommunicationModeCommand question
by pjh 19 Aug '99

19 Aug '99

Hi everyone in multipoint conference, when the terminal joining the conference has received the H.245 CommunicationModeCommand from MC, Should we open logical channels using the OpenLogicalChannel-OpenLogicalChannelAck sequence? Best Regards Jihye Park(Miss) Nada Research Co., Ltd. Seoul 137-070 , Korea Tel: 82-2-525-3941 Fax: 82-2-525-3945 pjh(a)deskview.nada.co.kr <mailto:pjh@deskview.nada.co.kr>

1 0

None
by Jangi, Shrirang 18 Aug '99

18 Aug '99

"subscribe"

1 0

From H.245 tunneling to separate connection?
by Paul Long 17 Aug '99

17 Aug '99

Why would an EP ever want to switch from H.245 tunneling to a separate H.245 connection? What possible use could there be in such a thing? Paul Long Smith Micro Software, Inc.

3 2

CallId/ConfId in LRQ
by Manoj Paul 16 Aug '99

16 Aug '99

Hi, Presently, when a GK needs to resolve some aliasaddress, it sends LRQ to another GK which has a co-located Border Element (BE). This BE may need to generate an Access Request (according to H.225 Annex G), to another BE. It might be mandatory for the requesting BE to include callInformation (callId/ConfId) in this Access Request (depending on the address template it holds). But LRQ message does not have a callId field in it. How can the requesting BE then derive callInformation for Access Request message? Any help will be appreciated. regards Manoj.

2 1

CallId/ConfId in LRQ.
by Manoj Paul 16 Aug '99

16 Aug '99

Hi, Presently, when a GK needs to resolve some aliasaddress, it sends LRQ to another GK which has a co-located Border Element (BE). This BE may need to generate an Access Request (according to H.225 Annex G), to another BE. It might be mandatory for the requesting BE to include callInformation (callId/ConfId) in this Access Request (depending on the address template it holds). But LRQ message does not have a callId field in it. How can the requesting BE then derive callInformation for Access Request message? Any help will be appreciated. regards Manoj.

1 0

Re: RTP question!!
by Aparna Saha 13 Aug '99

13 Aug '99

Hello Deepak, RTP states that in case a source changes its source transport address, it must also choose a new SSRC identifier . ( Refer to the last line of the description of SSRC as a field of the RTP Header. Section A.5.1, H.225 ). Hence, no SSRC collision will be registered. After changing the DSP (also resulting in change of IP address - assuming that it is associated with a different NIC), the source transport address as well as the SSRC changes as a result of which the receiver perceives this participant to be a new member in the session. Due to the soft-state approach of RTP, the information about the old transport address and the old SSRC would be removed subsequently (as it would no longer register any activity). If the application requires a correlation between the new SSRC and the older one, the same can be achieved through the CNAME item. The CNAME item in the RTCP packets generated would be the same for both the sources. However, as one cannot wait for an RTCP packet to arrive to correlate, this is not fool-proof. The above scenario is also the one seen in IPv6 mobility, wherein the IP address of the sender changes. Regards, Aparna. Deepak Jaiswal <djai(a)sasi.com> on 08/13/99 12:15:14 PM Please respond to Deepak Jaiswal <djai(a)sasi.com> To: rakeshj(a)wipinfo.soft.net (rakesh jain) cc: vittaln(a)agcs.com, h323implementors(a)imtc.org (bcc: Aparna Saha/HSS) Subject: Re: RTP question!! > Deepak, > Hi. > If after changing DSP you are sending RTP/RTCP packets from new > IP address that is IP address of new card, than i think, at > receiver end it will be source conflict, because IP adress is > different than the Old one. As a result the packets from the > new card will be discarded. > Pls let me know, if I am wrong. > rakesh Hello Rakesh, You need to open a multicast channel where in a receiver can recieve packets from multiple sources. With Regards, -- Deepak Jaiswal Multimedia Codecs Group djai(a)sasi.com Silicon Automation Systems Ltd. http://www.sasi.com #5, Corporation Division #67, HAL 3rd Stage, Tel: +91-80-5281461 x4115 Jeevan Bhima Nagar, Bangalore 560 075, India. Fax: +91-80-5276125 ------------------------------------------------------------------------- for list subscription instructions, send email to h323implementors-request(a)imtc.org with text "info"

2 1

H.248 proposed changes being discussed
by Nancy-M Greene 12 Aug '99

12 Aug '99

Based on the msg I sent out after Berlin entitled "Results from the ITU SG16 Berlin mtg", I have just sent out a series of msgs to the megaco list proposing actual edits to Megaco/H.248 to incorporate the changes suggested in Berlin. If you would like to be a part of this discussion, it would be a good idea to join the megaco mailing list. If you would just like to see what is being discussed, you can go to the Megaco archive at http://standards.nortelnetworks.com. I don't think this should be seen as "going back on what was decided on in Berlin". On the contrary, I see it as a way to make progress in a public forum so that we have a complete and reviewed Megaco/H.248 protocol by October. In any case the discussion on the Megaco mailing list does not preclude any contributions being brought into the October meeting. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

Re: H.245v6 ASN.1 tree?
by Paul Long 12 Aug '99

12 Aug '99

Mike, Oh, yeah, you're right! I gotta get used to genericCapabilities. Without looking closely at the other TDs, I thought they introduced new syntax. Thanks. So even though H.323v3 is Decided, we may modify the syntax for H.245v6, based on SG8's response regarding T.38? Paul Long Smith Micro Software, inc. -----Original Message----- From: mike.nilsson(a)BT.COM To: ITU-SG16(a)MAILBAG.INTEL.COM Sent: 8/12/99 1:56 AM Subject: Re: H.245v6 ASN.1 tree? Paul, The only change to the syntax for V6 that I am aware of is the change given below (from TD69/PLEN of Santiago), where ** is used to label additions. MediaTransportType ::=CHOICE { ip-UDP NULL, ip-TCP NULL, atm-AAL5-UNIDIR NULL, -- virtual circuits used as unidirectional atm-AAL5-BIDIR NULL, -- virtual circuits used as bidirectional ..., ** atm-AAL5-compressed SEQUENCE ** { ** variable-delta BOOLEAN , ** ... ** } } At the Berlin meeting there were discussion regarding the T.38 fax codepoints - we had received a liaison from SG8 that showed that there were differences between T.38 Annex B and H.245 V5. We replied to them suggesting a syntax addition to H.245 (V6) to allow the additional fields in T.38 Annex B to be signalled. I am assuming that we will not include these changes in H.245 until we have received a response from SG8. I have not made a new syntax - it did not seem worth the effort - and I am not aware of anyone else doing so. Best regards Mike

1 0