headers
Christian Groves | 1 Aug 2007 04:51

Re: Megaco support for RFC 2833

Hello Raphael,

To my knowledge nothing has been defined that allows volume control 
associated with the tones packages in H.248.1 Annex E. The closest work 
would be in H.248.9 and H.248.7 which allows volume control of 
announcements. Also H.248.19 allows volume control in mixing.

Is there an interest on the Megaco list to have a volume parameter 
associated with tones?

Regards, Christian

Raphael Tryster wrote:
>
> Judging by the lack of replies in the last 4 years and 5 days, there 
> probably wasn’t much interest in this then. I am wondering if anything 
> has changed in the meantime. It seems that digit duration could be 
> communicated quite easily using basic Megaco. To generate a DTMF tone 
> with a given duration, just use the SigDuration parameter of the 
> Signals descriptor. To report a tone detected with a given duration, 
> use tonedet/etd with the dur parameter in ObservedEvents. But what 
> about requesting or reporting tone volume? Has anything been defined 
> to support this?
>
> Raphael Tryster
>
> ------------------------------------------------------------------------
>
> *From:* Ed Luff [mailto:ed.luff <at> newport-networks.com]
> *Sent:* Thursday, July 10, 2003 10:36 PM
(Continue reading)

Permalink | Reply | 0 comments |
headers
Schwarz Albrecht | 1 Aug 2007 15:08
Picon
Favicon

RE: Error in H.248.9 Amd. 1; RE: Conflicting parameterID and ABNF token

Thanks!
Just saw that the Last Call is starting today:
http://www.itu.int/ITU-T/aap/AAPRecDetails.aspx?AAPSeqNo=1467

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves <at> nteczone.com] 
> Sent: Dienstag, 31. Juli 2007 08:39
> To: Schwarz Albrecht
> Cc: Syed Mohd Mujahid; megaco <at> ietf.org; linyangbo <at> huawei.com
> Subject: Re: Error in H.248.9 Amd. 1; RE: [Megaco] 
> Conflicting parameterID and ABNF token
> 
> Hello Albrecht amd Syed,
> 
> The use of "st" is not forbidden but as has been pointed out 
> it complicates the parsing of messages. Thus I think it would 
> be worthwhile updating H.248.9 Amendment 1 to use a different 
> parameter name. I'll make sure this is updated during the 
> last call process.
> 
> Regards, Christian
> 
> Schwarz Albrecht wrote:
> > Syed, right, you are correct in my understanding!
> > I did overlook the possiblity of optional StreamID parameter in a 
> > Signals Descriptor.
> > The general framework is: the Descriptor is somehow 
> orthogonal to the 
> > Stream Descriptors (because different Signals in the Signals 
> > Descriptor may have a Stream-individual scope).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Groves | 3 Aug 2007 03:50

Results of the July Q.3/16 H.248/Megaco meeting

Hello all,

The results of the ITU Q.3/16 meeting on H.248 issues are now publicly 
available.

The meeting report for Q.3 concerning H.248 items can be found in:
http://ftp3.itu.int/av-arch/avc-site/2005-2008/0706_Gen/WP2_report_070706.zip

All the output documents can be found at:
http://ftp3.itu.int/av-arch/avc-site/2005-2008/0706_Gen/0706_Gen.html

N.B. Please note that the outputs are designated with their 
recommendation/work id number rather than their TD number.

If you have trouble with access:
         Site:      ftp3.itu.int/
         User ID:   avguest
         Password:  Avguest (Note the uppercase 'A')
         Directory: avc-site/2005-2008/0706_Gen/

Regards, Christian
Permalink | Reply | 0 comments |
headers
Christian Groves | 3 Aug 2007 03:57

Liaison on H.248.resman Resource Management packages

Hello all,

As Q.3/16 Rapporteur it was agreed that I would communicate a liaison on 
a new work item H.248.resman "Resource Management" to the MEGACO mailing 
list for comment. The liaison can be found in: 
http://ftp3.itu.int/av-arch/avc-site/2005-2008/0706_Gen/WP2_liaison_statements_070706.zip 
.

Below is the text from the liaison.

Comments are welcome.

Regards, Christian (with my Q.3/16 Rapporteur hat on)

Start
----------------------

INTERNATIONAL TELECOMMUNICATION UNION

	

*STUDY GROUP 16*

*TELECOMMUNICATION
STANDARDIZATION SECTOR*

STUDY PERIOD 2005-2008
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Groves | 6 Aug 2007 07:36

Re: Error in H.248.9 Amd. 1; RE: Conflicting parameterID and ABNF token

Just as a follow up. I checked and there's already guidance in H.248.1 
section 12.2:

12.2 Guidelines to defining parameters to events and signals
Parameter Name: only descriptive
ParameterID: is an identifier. The textual ParameterID of parameters to 
events and signals shall not start with "EPA" and "SPA", respectively. 
The textual ParameterID shall also not be "ST", "Stream", "SY", 
"SignalType", "DR", "Duration", "NC", "NotifyCompletion", "KA", 
"KeepActive", "EB", "Embed", "DM", "DigitMap", "SPADI", "SPADirection", 
"SPARQ" or "SPARequestID".

Cheers, Christian

Schwarz Albrecht wrote:
> Syed, right, you are correct in my understanding!
> I did overlook the possiblity of optional StreamID parameter in a 
> Signals Descriptor.
> The general framework is: the Descriptor is somehow orthogonal to the 
> Stream Descriptors (because different Signals in the Signals 
> Descriptor may have a Stream-individual scope).
> This indicates a general design rule for packages: e.g. "token names 
> of possible sigParameter codepoints shall not be re-used for 
> signals/parameters definitions by package definitions".
> => if my conclusion is correct, then we should include this as an 
> explicit statement in § 12.1.4/H.248.1.
> Concerning the aastts package:
> There are two parameter names (with 'st') in aastts:
> aastts/playsid/st (segment type)
> aastts/playscript/st (script type)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arvind Charanyan | 8 Aug 2007 11:38
Favicon

RE: Reg Property and Event IDs of H323 Bearer Control Pkg which extends H245 Package

Hi,

 

Does any body have any idea about how to proceed about in the case of the H323 BCP Package since the property/event IDs of properties/events in that package overlap with those of H245 Package which it extends?

 

Like in the case of most other extended packages, is it ok to proceed with the H323 BCP Package by assigning the properties and events IDs consecutively after the IDs of the base package?

 

Thanks and Regards,

Arvind 

From: Arvind Charanyan
Sent: Monday, July 02, 2007 4:36 PM
To: megaco <at> ietf.org
Cc: Arvind Charanyan
Subject: Reg Property and Event IDs of H323 Bearer Control Pkg which extends H245 Package

 

Hi,

 

The specification for the H323 Bearer Control Package indicates that it extends H245 Package version 1. But the property IDs and the Event IDs are overlapping for the packages. Shouldn’t the property and event IDs of the H323 Bearer Control Package be continuation of that of the Base H245 Package?

 

Can anybody throw some light on this issue?

 

Thanks and Regards,

Arvind

 

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 501 comments |
headers
Tamar Nemet | 9 Aug 2007 11:04

Emergency property

Hi All,
 
Can somebody explain what is the meaning of sending ADD command to  a physical termination into a context with the emergency attribute set ?
 
Does it mean that this ADD command should be treated before others or something else ?
 
Does anybody implement/use  this ?
 
Thanks,
Tamar
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 2 comments |
headers
Claudio Fontana | 9 Aug 2007 15:59
Picon

context creation failure: correct reply structure

Hello,

sorry for the basic question, but I could not find the answer in the
RFC or in the list archives.
I'd need some help in understanding the correct behaviour of the MGW
whenever it is unable to create a new context.

Suppose that the MGC requests creation of a new context with
an addRequest with contextID=CHOOSE, and the MGW is unable to
satisfy the request,

at which level should the MGW put the error descriptor in the reply?
If at the command or action level, which ContextID should be written
in the reply?

Thank you for your help,

Claudio Fontana
Permalink | Reply | 1 comment |
headers
Krishna Prasad Kalluri (TN/EAB | 9 Aug 2007 16:44
Picon
Favicon

RE: context creation failure: correct reply structure

Hi,

It depends on in which level the error has occurred.

If the error occurred while processing the commands then MGW should
indicate the error descriptor in the command level. If the MGW is not
able process the context ID or other context related attributes MGW
should indicated the error in the action level.

Regarding the context Id to use,
If the context has no terminations left then it means no resources are
reserved and the controller need not subtract any thing later. So the
context ID received (in this case CHOOSE) can be used.

Regards
Krishna 

-----Original Message-----
From: Claudio Fontana [mailto:claudio.fontana <at> gmail.com] 
Sent: den 9 augusti 2007 15:59
To: megaco <at> ietf.org
Subject: [Megaco] context creation failure: correct reply structure

Hello,

sorry for the basic question, but I could not find the answer in the RFC
or in the list archives.
I'd need some help in understanding the correct behaviour of the MGW
whenever it is unable to create a new context.

Suppose that the MGC requests creation of a new context with an
addRequest with contextID=CHOOSE, and the MGW is unable to satisfy the
request,

at which level should the MGW put the error descriptor in the reply?
If at the command or action level, which ContextID should be written in
the reply?

Thank you for your help,

Claudio Fontana

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 0 comments |
headers
Gopalarathnam Sambasivan | 9 Aug 2007 16:49
Picon

Mapping of SIP with megaco

Hi All,
Is there a document/standard which maps the megaco happenings with the related SIP messages,
for a complete registartion and basic call??
 
orig side digits received context created -------- INVITE sent ----------> INVITE received ---------> context created ringing
                                                                                                                                    &nb sp;            |
       SG{cg/rt} ringback tone modify<---------------180 received    -----      180 ringing <--------------------------
 
Some staright forward cases that are not clear
1) When the modify has to happen for providing ringing / ringback tone in case of PRACK scenario ??
should this be PRACK and its 200 OK ???
 
2) When is modify the RTP be open for speech be done - 200 OK sending or reception of ACK ???
 
3) How to handle re-answer scenario (called party onhook and offhook) - just a internal treatment of timer
and then a BYE - or some SIP inbetween?
 
4) SDP negotiations ???????????????????????????????
 
Please let me know some standard for SIP-Megaco interworking and let me also know your opinion.
 
Thanks & Best Regards,
Gopalarathnam.
 
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 4 comments |

Gmane