headers
Christian Groves | 1 Jul 2004 07:38
Picon
Favicon

Re: Which error to use for errors in Topology descriptor?

Hello Aleksandr,

How about:
Additional to H.248.8:

4.2.5x	Error Code #: 522 Name: Invalid Topology
Definition: The MG was unable execute the action as it was unable to apply the 
requested context topology.
Package: –
Reference: –
Error Text in the error Descriptor: <TBD>
Comment: –

Do people want something to be returned in the Error descriptor? ie. the triple 
that caused the problem. I tend to think that as the "topology" is the group of 
triple its enough not to have anything. Thoughts?

Regards, Christian

Aleksandr Ryabin wrote:

> Hi Christinan,
> 
> Can we agree on the error code number now and the document this is to 
> added?
> Can the editor of the appropriate document (i.e. IG, or H.248.8 update) 
> please assign the number?
> 
> Thanks
>         Aleks
(Continue reading)

Permalink | Reply | 1 comment |
headers
Aleksandr Ryabin | 1 Jul 2004 16:00

Re: Which error to use for errors in Topology descriptor?

Hi Christian,

Sounds good.
Error can contain one, or more triples that caused the problem, i.e:

Error Text in the error Descriptor: invalid triples

Regards,
         Aleks

At 01:38 AM 7/1/2004, Christian Groves wrote:
>Hello Aleksandr,
>
>How about:
>Additional to H.248.8:
>
>4.2.5x  Error Code #: 522 Name: Invalid Topology
>Definition: The MG was unable execute the action as it was unable to apply 
>the requested context topology.
>Package: ­
>Reference: ­
>Error Text in the error Descriptor: <TBD>
>Comment: ­
>
>Do people want something to be returned in the Error descriptor? ie. the 
>triple that caused the problem. I tend to think that as the "topology" is 
>the group of triple its enough not to have anything. Thoughts?
>
>Regards, Christian
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kalleitner Franz | 1 Jul 2004 21:29
Picon

AW: RE : AW: telephony event defintion

Hello Christian,

it would be great if we could continue the discussion on that threat.
Based on NGN discussions I assume that sending codelists to a MG will be a
common handling in the future, since MGC does not know at inital offer, via
which interface the answerer will be connected(
wireline,wireless,wi-fi,....)and deploying sofistictated features. Isn't it
?

I think it become very important to handle or negosiate codeclists between
MGC and MG.
Since ACodec is defind as "single codec" there is no chance to implement
such a behaviour
(except using SDP equivalents or text based encoding)
thanks in advance, 

regards, Franz

-----Ursprüngliche Nachricht-----
Von: Kalleitner Franz 
Gesendet: Freitag, 25. Juni 2004 11:27
An: 'CHATRAS Bruno FTRD/DAC/ISS'; Christian Groves 
Cc: BELLING THOMAS; megaco <at> ietf.org
Betreff: AW: RE : AW: [Megaco] telephony event defintion

Of course, its possible to use SDP equivalents and it seems to be the only
way out to solve this problem.

Yes, the question is related to 3GPP TS 29.332. 
So if there is the necessity to use the SDP equivalents, its not possible to
(Continue reading)

Permalink | Reply | 501 comments |
headers
Christian Groves | 6 Jul 2004 13:46
Picon
Favicon

Re: AW: RE : AW: telephony event defintion

Hello Franz,

A agree that sending codec lists is something useful. H.248 allows you to send 
multiple codec value, reserve values and reserve groups so I believe it copes 
for all situations. I don't think using Acodec limits this.

The issue as far as I see is the support of DTMF (RFC2833). I guess there are 
several solutions.
1. Update Q.765.5 Acodec values to include a code points for:
      audio          telephone-event                        [RFC2833]
      audio          tone                                   [RFC2833]
    This could be proposed to ITU SG11.
2. Introduce a new property to Annex C for the code points above. It could 
either be specific for the above code points or generic as per rtpmap for fmtp. 
This would be done in ITU SG16.
3. Use SDP=a as proposed by Bruno below.

Thoughts?

Regards, Christian

Kalleitner Franz wrote:

> Hello Christian,
> 
> it would be great if we could continue the discussion on that threat.
> Based on NGN discussions I assume that sending codelists to a MG will be 
> a common handling in the future, since MGC does not know at inital 
> offer, via which interface the answerer will be connected( 
> wireline,wireless,wi-fi,....)and deploying sofistictated features. Isn't
(Continue reading)

Permalink | Reply | 501 comments |
headers
Balasubramanian Pitchandi | 10 Jul 2004 14:38

ABNF encoding of Boolean Values

Hello,

RFC3525 has two contradicting sections (A.1.2 & B.2) with respect to the
encoding of boolean values.

A.1.2 states that ObservedEvents parameter should be encoded as

init = false

whereas the section B.2 clearly states that all boolean values should be
encoded as either "on" or "off", which would mean that the same would be
encoded as

init = off

Which one of this is correct?

Thanks
Bala
Permalink | Reply | 0 comments |
headers
Kevin Boyle | 10 Jul 2004 18:06

RE: ABNF encoding of Boolean Values

Appendix A is binary encoding, not text encoding.  Appendix B is text
encoding.  The sections are not contradictory.

Kevin 

-----Original Message-----
From: Balasubramanian Pitchandi [mailto:bs <at> utstar.com] 
Sent: Saturday, July 10, 2004 8:39 AM
To: megaco <at> ietf.org
Cc: wei.zhao <at> utstar.com; tiger.pi <at> utstar.com
Subject: [Megaco] ABNF encoding of Boolean Values

Hello,

RFC3525 has two contradicting sections (A.1.2 & B.2) with respect to the
encoding of boolean values.

A.1.2 states that ObservedEvents parameter should be encoded as

init = false

whereas the section B.2 clearly states that all boolean values should be
encoded as either "on" or "off", which would mean that the same would be
encoded as

init = off

Which one of this is correct?

Thanks
(Continue reading)

Permalink | Reply | 2 comments |
headers
Balasubramanian Pitchandi | 11 Jul 2004 15:39

Problem with the andisp/dwa example

Hello,

In H248.23, Section 6.5, there is a small problem with the example given.
The example data is given as:

Signals{andisp/dwa{ddb=802001083035313831363135020A3931393535353030303007084
A6F686E20446F65D5,pattern=1}}

Here, the Checksum (the last byte) is incorrectly specified as D5, whereas
the actual checksum is D8.

Can this be corrected in a future revision of the document?

Thanks
Bala
Permalink | Reply | 0 comments |
headers
Kevin Boyle | 12 Jul 2004 06:37

RE: Problem with the andisp/dwa example

This was already corrected in H.248.23 Corrigendum 1 (03/2004).

Kevin 

-----Original Message-----
From: Balasubramanian Pitchandi [mailto:bs <at> utstar.com] 
Sent: Sunday, July 11, 2004 9:40 AM
To: megaco <at> ietf.org
Subject: [Megaco] Problem with the andisp/dwa example 

Hello,

In H248.23, Section 6.5, there is a small problem with the example given.
The example data is given as:

Signals{andisp/dwa{ddb=802001083035313831363135020A3931393535353030303007084
A6F686E20446F65D5,pattern=1}}

Here, the Checksum (the last byte) is incorrectly specified as D5, whereas
the actual checksum is D8.

Can this be corrected in a future revision of the document?

Thanks
Bala

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

Permalink | Reply | 0 comments |
headers
atto | 13 Jul 2004 07:25

答复: [Megaco] ABNF encoding of Boolean Values

hi, kevin,

I am confused by some conflict in rfc3525.

by B.2 comment, the text encoding boolean should be "on"/"off", 

but by definition of  cd/on{init}, the value of boolean is  "true"/"false".

	ObservedEventsDescriptor parameters
		Initial State
		ParameterID: init (0x0002)
		Type: Boolean
		Possible values:
		"True" means that the event was reported because the line was already on-hook when the events descriptor
containing this event was activated;
		"False" means that the event represents an actual state transition to on-hook.

and some examples of cd/on{init} also show  that "true"/"false" should be used. (in rfc3525 page 186/191/193)

MEGACO/1 [125.125.125.111]:55555 Transaction = 50008 {
      Context = 5000 {
          Notify = A5555 {ObservedEvents =1235 {
             19990729T24020002:al/on(init=false)}
          }
      } }

is it a mistake of rfc3525? 
or the boolean can be either on/off or true/false, just according by the definition?

thanks
(Continue reading)

Permalink | Reply | 1 comment |
headers
Csaba Koppany | 14 Jul 2004 15:34

Add command with NULL context

Hi List,

can someone clarify hat would be the correct answer to message below?

 
MEGACO/2 [123.123.123.4]:55555
Transaction = 10003 {
    Context = - {
       Add = $ {
          ....
       }
    }
}  

I guess using NULL context in an add command is an error, independently
the value of the termination Id.
It is written hat if the ROOT termination is addressed the 410
"Incorrect identifier" Shall be returned, but what are the error codes
in case of using a specific, CHOOSE or ALL wildcards? 

It is also my question if this error description should be on the
command or Action level, as by the syntax it is possible to include an
error descriptor inside the ActioReply with an empty list of command.

Thank you for any suggestions!
Best regards,
  Csaba Koppany
Permalink | Reply | 0 comments |

Gmane