Tom-PT Taylor | 1 May 01:01 2002

RE: Access To Megaco Documents

I see a typo in the URL I gave -- not sure how, since it was a
cut-and-paste.  Anyway, the right URL is
ftp://ftp <at> standards.nortelnetworks.com/megaco/docs/

-----Original Message-----
From: Balasubramanian Pitchandi [mailto:bs <at> utstar.com]
Sent: Tuesday, April 30, 2002 6:55 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]; megaco <at> ietf.org
Cc: 'Seong-Ho Jeong'; 'Blatherwick, Peter'; 'Marcello Pantaleo (EED)';
Pugh, John [NC1:6L24:EXCH]
Subject: RE: [Megaco] Access To Megaco Documents

Tom,

The URL does not seem to work. Is this a new server? 

Because the URL used to be:

ftp://standards.nortelnetworks.com/megaco/docs/

You have mentioned below that the URL is

ftp://ftp <at> stadards.nortelnetworks.com/megaco/docs/

Anyways, I have tried both. No luck.

Thanks,
Bala

-----Original Message-----
(Continue reading)

Christian Groves | 1 May 08:01 2002
Picon

Re: [MMUSIC] FW: I-D ACTION:draft-taylor-mmusic-sdp-tdm-01.txt

G'Day Tom,

I don't think 1 information element is such a burden. Irrespective of how its
coded it will support the same functionality and be used in the legacy
environment.

Regards, Christian

Tom-PT Taylor wrote:
> 
> The whole point of the draft is to relieve MGs of the necessity to understand
> legacy telephony signalling protocols.  I will allow the WGs to comment on
> whether this is the right approach, since your proposal is obviously a
> workable alternative.
> 
> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves <at> ericsson.com.au]
> Sent: Monday, April 29, 2002 9:46 PM
> To: Taylor, Tom-PT [CAR:B800:EXCH]
> Cc: 'megaco <at> ietf.org'; 'mmusic <at> ietf.org'
> Subject: Re: [MMUSIC] FW: I-D ACTION:draft-taylor-mmusic-sdp-tdm-01.txt
> 
> G'Day Tom,
> 
> I've been having a look at the TDM draft and my main comment is regarding
> mainly
> section 4 TDM attributes although it may have some flow on effects. Whilst the
> 
> list of attributes is rather comprehensive it seems to me that this is a
> duplication of already defined values. All of the values can be represented by
(Continue reading)

Dana.Herskowitz | 1 May 14:02 2002

Mode in LocalControl ***

Hello,
In the 3015 RFC there is an example of sending the Mode to both physical
and ephemeral terminations?
What should be done if only one of them receives a "Mode" parameter?
What should be done if there are two different Modes for the physical and
ephemeral terminations?

MEGACO/1 [123.123.123.4]:55555
   Transaction = 50003 {
       Context = $ {
          Add = A5555  { Media {
               Stream = 1 {
                    LocalControl {Mode = SendReceive} }},
                Events=1234{al/of},
               Signals {al/ri}
               },
          Add  = $ {Media {
               Stream = 1 {
                    LocalControl {
                       Mode = SendReceive,
                       nt/jit=40 ; in ms
                    },
                    Local {
   v=0
   c=IN IP4 $
   m=audio $ RTP/AVP 4

   a=ptime:30
                    },
                    Remote {
(Continue reading)

Tom-PT Taylor | 1 May 14:14 2002

RE: Mode in LocalControl ***

The default value for Mode is inactive.  That means you MUST set it on all terminations through which you want media to flow.

-----Original Message-----
From: Dana.Herskowitz <at> ecitele.com [mailto:Dana.Herskowitz <at> ecitele.com]
Sent: Wednesday, May 01, 2002 8:03 AM
To: megaco <at> ietf.org
Subject: [Megaco] Mode in LocalControl ***


Hello,
In the 3015 RFC there is an example of sending the Mode to both physical
and ephemeral terminations?
What should be done if only one of them receives a "Mode" parameter?
What should be done if there are two different Modes for the physical and
ephemeral terminations?

MEGACO/1 [123.123.123.4]:55555
   Transaction = 50003 {
       Context = $ {
          Add = A5555  { Media {
               Stream = 1 {
                    LocalControl {Mode = SendReceive} }},
                Events=1234{al/of},
               Signals {al/ri}
               },
          Add  = $ {Media {
               Stream = 1 {
                    LocalControl {
                       Mode = SendReceive,
                       nt/jit=40 ; in ms
                    },
                    Local {
   v=0
   c=IN IP4 $
   m=audio $ RTP/AVP 4

   a=ptime:30
                    },
                    Remote {
   v=0
   c=IN IP4 124.124.124.222
   m=audio 2222 RTP/AVP 4
   a=ptime:30
                    } ; RTP profile for G.723 is 4
                }
             }
         }
      }
   }


Regards,

Dana H.
SW Engineer
NGTS ECI Telecom



_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

Tom-PT Taylor | 1 May 15:33 2002

H.248 Renumbering

I mentioned in the past that the ITU-T is renumbering H.248 and its annexes.
The correspondence between old and new numbering will be made clear on the
ITU-T web page, but I'll show the table here for your general information:

Previous numbering	New numbering	Title

H.248 (Main text 	      H.248.1 (06/2000)	Gateway control protocol
+ Annexes A to E)

Note: This version 1 of H.248.1 is considered to be that of H.248 (Main text
+ Annexes A to E) of 06/2000, updated with an "Amd1 to H.248.1" of 02/2002
which brings changes, clarifications and corrections but no new
functionality. Available for sale but superseded by H.248.1 of 02/2002

	                  H.248.1 (02/2002)	Gateway control protocol
Note: This version 2 of H.248 (Main text + Annexes A to E) has additional
functionality compared to version 1 of 06/2000.

H.248, Annex F	      H.248.2           Facsimile, text conversation and
call
                                          discrimination packages

H.248, Annex G	      H.248.3           User interface elements and action
packages

H.248, Annex H	      H.248.4	      Transport over SCTP

H.248, Annex I	      H.248.5	      Transport over ATM

H.248, Annex J	      H.248.6	      Dynamic tone definition package

H.248, Annex K	      H.248.7	      Generic announcement package

H.248, Annex L	      H.248.8	      Error codes and service change reason
                                          description

H.248, Annex M.1 	      H.248.9	      Advanced media server packages

H.248, Annex M.2	      H.248.10	      Media gateway resource
congestion
                                          handling package
H.248, Annex M.3	      H.248.11          (not yet available)
(not yet available)
	
H.248, Annex M.4	      H.248.12	      H.248 packages for H.323 and
H.324
                                          interworking

H.248, Annex M.5 	      H.248.13	      Quality alert ceasing package

H.248, Annex M.6 	      H.248.14	      Inactivity timer package

H.248, Annex N	      H.248.15	      SDP H.248 package 

Tom Taylor
taylor <at> nortelnetworks.com
Ph. +1 613 736 0961 (ESN 396 1490)
John Stock | 2 May 00:45 2002

"Error tone" specification

Can anyone say where I can find a specification for "error tone" listed in
draft-boyle-megaco-alerting-03.txt?  I can't seem to find it.

Thanks.

John Stock
Systems Engineer
Advanced Fibre Communications
1465 N. McDowell Blvd.
Petaluma, CA 94954
Tel. 707-792-6249
Tom-PT Taylor | 2 May 01:08 2002

RE: "Error tone" specification

Looking at the document, I would guess this would be defined by local
practice.  I'm not sure I've ever experienced a tone like this -- the only
data input situations I can think of involved announcements.  For something
where you wanted to abort a session, of course, you could use reorder tone.
I expect you'd want to make that signal type OO rather than brief.

-----Original Message-----
From: John Stock [mailto:John.Stock <at> afc.com]
Sent: Wednesday, May 01, 2002 6:46 PM
To: 'megaco <at> ietf.org'
Subject: [Megaco] "Error tone" specification

Can anyone say where I can find a specification for "error tone" listed in
draft-boyle-megaco-alerting-03.txt?  I can't seem to find it.

Thanks.

John Stock
Systems Engineer
Advanced Fibre Communications
1465 N. McDowell Blvd.
Petaluma, CA 94954
Tel. 707-792-6249

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
Kevin Boyle | 2 May 16:57 2002

RE: "Error tone" specification

In NA, VSLE features have an error tone that is used in conjection with an error display on the screen.  See GR-1436-CORE.  There may be similar applications in other localities.

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:B800:EXCH]
Sent: Wednesday, May 01, 2002 7:09 PM
To: 'John Stock'; 'megaco <at> ietf.org'
Subject: RE: [Megaco] "Error tone" specification


Looking at the document, I would guess this would be defined by local
practice.  I'm not sure I've ever experienced a tone like this -- the only
data input situations I can think of involved announcements.  For something
where you wanted to abort a session, of course, you could use reorder tone.
I expect you'd want to make that signal type OO rather than brief.

-----Original Message-----
From: John Stock [mailto:John.Stock <at> afc.com]
Sent: Wednesday, May 01, 2002 6:46 PM
To: 'megaco <at> ietf.org'
Subject: [Megaco] "Error tone" specification


Can anyone say where I can find a specification for "error tone" listed in
draft-boyle-megaco-alerting-03.txt?  I can't seem to find it.

Thanks.

John Stock
Systems Engineer
Advanced Fibre Communications
1465 N. McDowell Blvd.
Petaluma, CA 94954
Tel. 707-792-6249



_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

Christer Holmberg | 3 May 08:44 2002
Picon
Picon

Re: Mode in LocalControl ***

 
Hi,

A while ago there was a discussion about the use of mode in "internal" terminations, eg a MUX termination. It was then said that mode can be used even for such terminations, to describe the media flow.

However, chapter 6.1.1 very cleary says that MODE is used for the media flow of the media at the ingress/egress of the media gateway, and that TOPOLOGY is used for media between terminations within a context. By reading that text one DOES get the understanding that mode is not needed for the mux termination, so my question is if some clarifications are needed?

Regards,

Christer Holmberg
Ericsson Finland
 
 
 
 
 
 

Tom-PT Taylor wrote:

 

The default value for Mode is inactive.  That means you MUST set it on all terminations through which you want media to flow.

-----Original Message-----
From: Dana.Herskowitz <at> ecitele.com [mailto:Dana.Herskowitz <at> ecitele.com]
Sent: Wednesday, May 01, 2002 8:03 AM
To: megaco <at> ietf.org
Subject: [Megaco] Mode in LocalControl ***

Hello,
In the 3015 RFC there is an example of sending the Mode to both physical
and ephemeral terminations?
What should be done if only one of them receives a "Mode" parameter?
What should be done if there are two different Modes for the physical and
ephemeral terminations?

MEGACO/1 [123.123.123.4]:55555
   Transaction = 50003 {
       Context = $ {
          Add = A5555  { Media {
               Stream = 1 {
                    LocalControl {Mode = SendReceive} }},
                Events=1234{al/of},
               Signals {al/ri}
               },
          Add  = $ {Media {
               Stream = 1 {
                    LocalControl {
                       Mode = SendReceive,
                       nt/jit=40 ; in ms
                    },
                    Local {
   v=0
   c=IN IP4 $
   m=audio $ RTP/AVP 4

   a=ptime:30
                    },
                    Remote {
   v=0
   c=IN IP4 124.124.124.222
   m=audio 2222 RTP/AVP 4
   a=ptime:30
                    } ; RTP profile for G.723 is 4
                }
             }
         }
      }
   }

Regards,

Dana H.
SW Engineer
NGTS ECI Telecom
 

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

Tom-PT Taylor | 3 May 15:14 2002

RE: Mode in LocalControl ***


I suppose one could rephrase 6.1.1 to say that MODE controls the flow of
media THROUGH an individual termination, while topology controls the flow of
media across the centre of the context.

-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg <at> lmf.ericsson.se]
Sent: Friday, May 03, 2002 2:44 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: 'Dana.Herskowitz <at> ecitele.com'; megaco <at> ietf.org
Subject: Re: [Megaco] Mode in LocalControl ***

  
Hi, 
A while ago there was a discussion about the use of mode in "internal"
terminations, eg a MUX termination. It was then said that mode can be used
even for such terminations, to describe the media flow.

However, chapter 6.1.1 very cleary says that MODE is used for the media flow
of the media at the ingress/egress of the media gateway, and that TOPOLOGY
is used for media between terminations within a context. By reading that
text one DOES get the understanding that mode is not needed for the mux
termination, so my question is if some clarifications are needed? 
Regards, 
Christer Holmberg 
Ericsson Finland 

  

  

  
Tom-PT Taylor wrote: 

The default value for Mode is inactive.  That means you MUST set it on all
terminations through which you want media to flow. 
-----Original Message----- 
From: Dana.Herskowitz <at> ecitele.com [mailto:Dana.Herskowitz <at> ecitele.com] 
Sent: Wednesday, May 01, 2002 8:03 AM 
To: megaco <at> ietf.org 
Subject: [Megaco] Mode in LocalControl *** 
Hello, 
In the 3015 RFC there is an example of sending the Mode to both physical 
and ephemeral terminations? 
What should be done if only one of them receives a "Mode" parameter? 
What should be done if there are two different Modes for the physical and 
ephemeral terminations? 
MEGACO/1 [123.123.123.4]:55555 
   Transaction = 50003 { 
       Context = $ { 
          Add = A5555  { Media { 
               Stream = 1 { 
                    LocalControl {Mode = SendReceive} }}, 
                Events=1234{al/of}, 
               Signals {al/ri} 
               }, 
          Add  = $ {Media { 
               Stream = 1 { 
                    LocalControl { 
                       Mode = SendReceive, 
                       nt/jit=40 ; in ms 
                    }, 
                    Local { 
   v=0 
   c=IN IP4 $ 
   m=audio $ RTP/AVP 4 
   a=ptime:30 
                    }, 
                    Remote { 
   v=0 
   c=IN IP4 124.124.124.222 
   m=audio 2222 RTP/AVP 4 
   a=ptime:30 
                    } ; RTP profile for G.723 is 4 
                } 
             } 
         } 
      } 
   } 
Regards, 
Dana H. 
SW Engineer 
NGTS ECI Telecom 

_______________________________________________ 
Megaco mailing list 
Megaco <at> ietf.org 
https://www1.ietf.org/mailman/listinfo/megaco

Gmane