Subject: AW: RE : AW: [Megaco] telephony event defintion

From: Kalleitner Franz <[email-masked]>
Date: Thu, 1 Jul 2004 21:29:32 +0200

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; [email-masked]
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
align the BICC procedure with the IMS(SIP) procedures.

Franz

-----Ursprüngliche Nachricht-----
Von: CHATRAS Bruno FTRD/DAC/ISS [mailto:[email-masked]]
Gesendet: Freitag, 25. Juni 2004 11:01
An: Kalleitner Franz; Christian Groves 
Cc: BELLING THOMAS; [email-masked]
Betreff: RE : AW: [Megaco] telephony event defintion

Why not using the code point for SDP_A defined in Annex C.11 of H.248.1?

Is this question related to 3GPP TS 29.332?

Regards,
Bruno

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de
Kalleitner Franz
Envoyé : vendredi 25 juin 2004 09:58
À : 'Christian Groves '; Kalleitner Franz
Cc : BELLING THOMAS; [email-masked]' '
Objet : AW: AW: [Megaco] telephony event defintion

Hello Christian,

thanks a lot for you answer.
You are right, for BICC networks its possible to use the tunneling solution.
However, we need to find a solution to manage the interworking between SIP
and ISUP networks Q.1912.5 or RFC3398 as well the 3GPP 29.163, specifying a
SIP-BICC interworking as well. As you proposed, for the BICC interface we
want to use the methods defined in Q1950 and Q765.5 but its not possible to
use them for the SIP interface. SIP doesn't offer any tunneling in a similar
way. Nevertheless its necessary to configure an IP termination connected to
a SIP network via H248. 

So that's the background, why I'm asking these questions concerning DTMF
codec and codeclists, because we want to reuse h248 basics as much as
possible to implement the interworking between SIP and ISUP/BICC networks.

Do you think there is a chance to solve these two items within H248
standardization?

kind regards
Franz

-----Originalnachricht-----
Von: Christian Groves
An: Kalleitner Franz
Cc: [email-masked]'; BELLING THOMAS
Gesendet: 25.06.04 04:16
Betreff: Re: AW: [Megaco] telephony event defintion

Hello Franz,

For BICC networks (where the Acodec is defined in Q.765.5) sending DTMF as
per 
RFC2833 is not needed across Q.1950(H.248). The actual SDP parameters used
for 
the connection are transmitted via IPBCP (Q.1970).

There is a parameter in H.248.1 annex C 0x100F "Payload Type" that may be of

some use.

Regards, Christian

Kalleitner Franz wrote:

> I wonder if anybody could respond on that threat!
> Without a codepoint for DTMF, the functionality of RFC2833 cannot be
applied
> for
> network configuration specifing DTMF as an ACodec i.e for codec
negosiation
> purposes!
> A solution for text encoded H248 is available but not for binary.
> 
> Many thanks in advance
> Franz
> 
> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]Im
Auftrag
> von Kalleitner Franz
> Gesendet: Donnerstag, 17. Juni 2004 13:21
> An: [email-masked]'
> Betreff: [Megaco] telephony event defintion
> 
> 
> Hello megaco-list members,
> 
> I didn't manage to transfer the media description of the
telephone-event
> (defined in RFC 2833) as a media attribute into ASN.1 format. In SDP 
> its easily done via a dynamically payload type definition, plus 
> fmtp,rtpmap for the codec definition Using ASN.1 encoding the payload 
> attribute is defined in H248.1 Annex
C.
> However, an reference pointing to the codec definition is not
available,
> therefore I scanned ITU-T and 3GPP references, but I didn't found any 
> definition for the telephone-event.
> 
> Probably another had the same problem, with more success than I'm and
may
> send a reply to this threat.
> Many thanks in advance!
> 
> Franz
> 
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
> 
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
> 

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Christian Groves <[email-masked]>
Date: Tue, 06 Jul 2004 21:46:43 +1000

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:

> 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.
> Of course, its possible to use SDP equivalents and it seems to be the 
> only way out to solve this problem.
> 
> So if there is the necessity to use the SDP equivalents, its not 
> possible to align the BICC procedure with the IMS(SIP) procedures.
> 
> Franz
> 
> De : [email-masked] [mailto:[email-masked]] De la part 
> de Kalleitner Franz
> You are right, for BICC networks its possible to use the tunneling 
> solution. However, we need to find a solution to manage the interworking 
> between SIP and ISUP networks Q.1912.5 or RFC3398 as well the 3GPP 
> 29.163, specifying a SIP-BICC interworking as well. As you proposed, for 
> the BICC interface we want to use the methods defined in Q1950 and 
> Q765.5 but its not possible to use them for the SIP interface. SIP 
> doesn't offer any tunneling in a similar way. Nevertheless its necessary 
> to configure an IP termination connected to a SIP network via H248.
> 
> For BICC networks (where the Acodec is defined in Q.765.5) sending DTMF 
> as per
> RFC2833 is not needed across Q.1950(H.248). The actual SDP parameters 
> used for