January 2006 - sg16-avd - lists.packetizer.com

Re: many-to-many relationship in H.248
by Christian Groves 25 Jan '06

25 Jan '06

Hello Sasha, As Albrecht says typically there's only one control association between an MGC-MG pair. An MG can be split into several Virtual MGs which in effect allow one physical MG to have a relationship with multiple MGCs. What scenario / functionality are you looking at? There may be another way via H.248 to achieve want you want. Regards, Christian Albrecht.Schwarz(a)alcatel.de wrote: >Sasha, > >guess this is impossible due to the Control Association concept in H.248. >There's only a single Control Association between a MGC-MG pair. >Regards, > >Albrecht > > >PS >You should Cc "megaco(a)ietf.org" for H.248 specific questions. > > > > > "Sasha Ruditsky" > <sasha@RADVISION To: <itu-sg16(a)external.cisco.com> > .COM> cc: > Subject: many-to-many relationship in H.248 > 25.01.2006 21:22 > > > > > >Hi > > >In H.248 single MGC normally works with several MGs. However a particular >MG works with a single MGC in any given moment of time. > > >In a particular setup with which we are working it is necessary that an MGC >instructs an MG to give notifications to a different MGC. > > >Does somebody know a way to achieve this in current H.248? > > >Do you think such way should be defined? > > >Thanks, >Sasha > > > >

1 0

Re: many-to-many relationship in H.248
by Albrecht.Schwarz＠alcatel.de 25 Jan '06

25 Jan '06

Sasha, guess this is impossible due to the Control Association concept in H.248. There's only a single Control Association between a MGC-MG pair. Regards, Albrecht PS You should Cc "megaco(a)ietf.org" for H.248 specific questions. "Sasha Ruditsky" <sasha@RADVISION To: <itu-sg16(a)external.cisco.com> .COM> cc: Subject: many-to-many relationship in H.248 25.01.2006 21:22 Hi In H.248 single MGC normally works with several MGs. However a particular MG works with a single MGC in any given moment of time. In a particular setup with which we are working it is necessary that an MGC instructs an MG to give notifications to a different MGC. Does somebody know a way to achieve this in current H.248? Do you think such way should be defined? Thanks, Sasha

1 0

many-to-many relationship in H.248
by Sasha Ruditsky 25 Jan '06

25 Jan '06

Hi In H.248 single MGC normally works with several MGs. However a particular MG works with a single MGC in any given moment of time. In a particular setup with which we are working it is necessary that an MGC instructs an MG to give notifications to a different MGC. Does somebody know a way to achieve this in current H.248? Do you think such way should be defined? Thanks, Sasha

1 0

FW: [AVT] I-D ACTION:draft-ietf-avt-rfc2032-bis-13.txt --> RTP Payload Format for H.261 Video Streams
by simao.campos＠ITU.INT 25 Jan '06

25 Jan '06

Dear experts, For your information. Best regards, Simão -----Original Message----- From: avt-bounces(a)ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Internet-Drafts(a)ietf.org Sent: 24 January 2006 00:50 To: i-d-announce(a)ietf.org Cc: avt(a)ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rfc2032-bis-13.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for H.261 Video Streams Author(s) : R. Even Filename : draft-ietf-avt-rfc2032-bis-13.txt Pages : 24 Date : 2006-1-23 This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. The memo also describes the syntax and semantics of the SDP parameters needed to support the H.261 video codec. A media type registration is included for this payload format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2032-bis-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request(a)ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rfc2032-bis-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rfc2032-bis-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

1 0

RE: T310 timer and PROGRESS
by Horvath, Ernst 24 Jan '06

24 Jan '06

Paul, In QSIG, which is essentially a symmetrical variant of Q.931, T310 is stopped on receipt of a PROGRESS message with progress indication 1 or 8. This behaviour is useful for a number of supplementary services where expiry of T310 could terminate the call attempt too soon. Regards, Ernst ________________________________ From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Monday, January 23, 2006 11:51 PM To: itu-sg16(a)external.cisco.com Subject: T310 timer and PROGRESS Experts, Recently, I asked what should happen when an endpoint receives a PROGRESS message indicating that there are in-band tones and announcements. Should the T310 timer be stopped? H.225.0 seems to be silent on this, but it would certainly seem that it should be stopped. Should we stop the timer or should the timer continue to run? It will expire in short order (assuming a default value), which suggests the timer ought to be terminated and T301 started. I would appreciate your input on this. Paul

1 0

RE: T310 timer and PROGRESS
by Paul E. Jones 24 Jan '06

24 Jan '06

Christian, Thanks for pointing this out to me. It would seem reasonable that we should probably bring over comparable wording to H.323 or, at the very least, list PROGRESS as one of the messages that stops the T310 timer. I suppose the further qualification would be that the PROGRESS message must contain a PI #8 or #1. Would this sound reasonable? If so, I'll draft such a contribution for the next meeting. Paul > -----Original Message----- > From: Christian Groves [mailto:cngroves@bigpond.net.au] > Sent: Monday, January 23, 2006 6:11 PM > To: Paul E. Jones > Cc: itu-sg16(a)external.cisco.com > Subject: Re: T310 timer and PROGRESS > > G'Day Paul, > > I had a look at Q.931 as the precurser to H.225 to see what the > intention was there. Whilst not in the core specification there was a > description of the behaviour in an annex described Private Network > interconnection. > > > "M.6.3.1.3 In-band information provided to the physical > PINX at the originating interface > > Any progress indications shall be conveyed towards the physical PINX at > the originating interface. > > On receipt of the Progress description No. 1 or No. 8 in the PROGRESS or > ALERTING message, the physical PINX at the originating interface shall > switch through in the backward direction to the allocated B-channel in > order to enable transfer of in-band tones/information, and stop timer > T310, if running." > > > M.6.3.2.3 In-band information provided by the physical PINX > at the destination interface > > During call establishment, after the first message received in response > to the SETUP message, on receipt of a Progress indicator information > element with a Progress description No. 1 or No. 8 in the PROGRESS or > ALERTING message, the public network shall switch through in the > backward direction to the allocated B channel in order to enable in-band > tones/information provided from the physical PINX at the destination > interface to the calling user, stop timer T310, if running, and if > progress description No. 1 or No. 8 was received in the PROGRESS message > while T310 was running, restart timer T310. > > The public network shall transfer the Progress indicator information > element towards the preceding PINX." > > > Cheers, Christian > > Paul E. Jones wrote: > > > Experts, > > > > > > > > Recently, I asked what should happen when an endpoint receives a > > PROGRESS message indicating that there are in-band tones and > > announcements. Should the T310 timer be stopped? H.225.0 seems to be > > silent on this, but it would certainly seem that it should be stopped. > > > > > > > > Should we stop the timer or should the timer continue to run? It will > > expire in short order (assuming a default value), which suggests the > > timer ought to be terminated and T301 started. > > > > > > > > I would appreciate your input on this. > > > > > > > > Paul > > > > > > >

1 0

T310 timer and PROGRESS
by Paul E. Jones 23 Jan '06

23 Jan '06

Experts, Recently, I asked what should happen when an endpoint receives a PROGRESS message indicating that there are in-band tones and announcements. Should the T310 timer be stopped? H.225.0 seems to be silent on this, but it would certainly seem that it should be stopped. Should we stop the timer or should the timer continue to run? It will expire in short order (assuming a default value), which suggests the timer ought to be terminated and T301 started. I would appreciate your input on this. Paul

2 1

FW: RFC 4351 on Real-Time Transport Protocol (RTP) Payload for TextConversation Interleaved in an Audio Stream
by simao.campos＠itu.int 23 Jan '06

23 Jan '06

Dear colleagues FYI Cheers, Simão -----Original Message----- From: ietf-announce-bounces(a)ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of rfc-editor(a)rfc-editor.org Sent: 12 January 2006 02:59 To: ietf-announce(a)ietf.org Cc: avt(a)ietf.org; rfc-editor(a)rfc-editor.org Subject: RFC 4351 on Real-Time Transport Protocol (RTP) Payload for TextConversation Interleaved in an Audio Stream A new Request for Comments is now available in online RFC libraries. RFC 4351 Title: Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream Author(s): G. Hellstrom, P. Jones Status: Historic Date: January 2006 Mailbox: gunnar.hellstrom(a)omnitor.se, paulej(a)packetizer.com Pages: 20 Characters: 44405 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-audio-t140c-00.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4351.txt This memo describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140. One payload format is described for transmitting audio and text data within a single RTP session. This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. This document is a product of the Audio/Video Transport Working Group of the IETF. This memo defines a Historic Document for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST(a)IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST(a)RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info(a)RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info(a)RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager(a)RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR(a)RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs.

1 0

FW: ITU-ATIS workshop: Spotlight on NGN - Starting 19 March 2006, Las Vegas.
by simao.campos＠ITU.INT 20 Jan '06

20 Jan '06

FYI > ==== > What: Next Generation Network Technology and Standardization > - A joint ITU-T/ATIS workshop at the kind invitation of ATIS - > This free workshop will be held in conjunction with the ATIS Annual > Meeting of its Committees, ATIS TechThink (www.techthink.org) and > Telecom NEXT (www.telecom-next.com). > When: Starting Sunday 19 March 2006 > Where: Mandalay Bay Convention Centre, Las Vegas, USA > Who: Aimed at all who need to know where NGN is going next. > Why: A particular emphasis of the workshop will be NGN requirements > and standards objectives from a North American perspective and how > these can be optimally taken into account in global NGN > standardization in the ITU-T. > Next Generation Network (NGN) standardization is now well underway in > ITU-T and ATIS (as well as other standards organizations.) NGN aims to > increase quality and service features for users, independent of the > underlying transport technology. Following the success of these two > organizations to identify and react to industry's need for NGN > standards, and in continuing their commitment to achieve interoperable > global standards, this workshop will build on the existing > relationship between the two organizations to: > * examine the status of the work in both organizations > * identify standards work needed to support ongoing viable > businesses for all parties as NGN becomes reality, and > * enhance and extend ITU-T and ATIS cooperation to further > coordinate regional and global NGN standardization > For more information please visit: > www.itu.int/ITU-T/worksem/ngn/200603/index.html > Register for this workshop online: > www.itu.int/cgi-bin/htsh/edrs/ITU-T/scripts/edrs.ITU-T.workshops.form? > _eventid=17. >

1 0

FW: ITU-ATIS workshop: Spotlight on NGN - Starting 19 March 2006, Las Vegas.
by simao.campos＠itu.int 20 Jan '06

20 Jan '06

FYI > ==== > What: Next Generation Network Technology and Standardization > - A joint ITU-T/ATIS workshop at the kind invitation of ATIS - > This free workshop will be held in conjunction with the ATIS Annual > Meeting of its Committees, ATIS TechThink (www.techthink.org) and > Telecom NEXT (www.telecom-next.com). > When: Starting Sunday 19 March 2006 > Where: Mandalay Bay Convention Centre, Las Vegas, USA > Who: Aimed at all who need to know where NGN is going next. > Why: A particular emphasis of the workshop will be NGN requirements > and standards objectives from a North American perspective and how > these can be optimally taken into account in global NGN > standardization in the ITU-T. > Next Generation Network (NGN) standardization is now well underway in > ITU-T and ATIS (as well as other standards organizations.) NGN aims to > increase quality and service features for users, independent of the > underlying transport technology. Following the success of these two > organizations to identify and react to industry's need for NGN > standards, and in continuing their commitment to achieve interoperable > global standards, this workshop will build on the existing > relationship between the two organizations to: > * examine the status of the work in both organizations > * identify standards work needed to support ongoing viable > businesses for all parties as NGN becomes reality, and > * enhance and extend ITU-T and ATIS cooperation to further > coordinate regional and global NGN standardization > For more information please visit: > www.itu.int/ITU-T/worksem/ngn/200603/index.html > Register for this workshop online: > www.itu.int/cgi-bin/htsh/edrs/ITU-T/scripts/edrs.ITU-T.workshops.form? > _eventid=17. >

1 0