Subject: RE: [Megaco] Reporting actual codec used in a call

From: "Raphael Tryster" <[email-masked]>
Date: Sun, 2 Sep 2007 15:31:42 +0300

Thank you, Christian.  rtp/pltrans looks like a good way to report a
change in codec, but what about the initial value?  Is there an
assumption here that the initial codec is the first one listed in the
SDP, and therefore an MG receiving rtp/pltrans in Events that chooses
another codec to start with should immediately notify rtp/pltrans?
 
Raphael Tryster

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2007 3:09 AM
To: Raphael Tryster
Cc: megaco ietf
Subject: Re: [Megaco] Reporting actual codec used in a call

Hello Raphael,

There's to payload transition event in the RTP package that can be used,

however its not linked to a subtract (end of call).

Regards, Christian

Raphael Tryster wrote:
>
> Is there any package that allows the MG to report to the MGC at the 
> end of a call, which codec was actually used for the call?  (As 
> opposed to codec negotiation at the start of a call, which may produce

> a list of codecs, not all of which are actually used in the call).
>
>  
>
> Raphael Tryster
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> 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, 04 Sep 2007 11:01:21 +1000

Hello Raphael,

I agree that it is not really specified what the initial value would be. 
I think your suggestion is a pragmatic one to define the behaviour when 
a codec has not been already selected. An alternative is to say that the 
MGC should not set the rtp/pltrans event until an initial codec is used 
but the MGC wouldn't know when this was.

This might be a candidate for an IG item.

Regards,  Christian

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Tue, 4 Sep 2007 07:39:13 +0200

Like to note that there are further aspects when using RTP payload/packet type codepoint (PT) as information for used codec in a call:
1) codec changes
2) multiple PTs in use e.g. due to telephone events for RFC 4733 packets
3) multiple PTs in use e.g. due to voiceband data services (V.152, T.38, V.150.1, V.151)

> >> opposed to codec negotiation at the start of a call, which may 

I could see two ways:

A) H.248.1 V3 & H.248.39 (see e.g. § 8.1 "Individual auditing of Local and Remote SDP was introduced in H.248.1 Version 3")
	=> auditing of SDP "m=" and/or "a=" lines

B) New H.248 Statistic "Used codec(s) in a IP call/RTP session"
	=> ordered list of media formats used (the first list item indicates the last codec used) 

-Albrecht

> From: Christian Groves [mailto:[email-masked]] 
> Sent: Dienstag, 4. September 2007 03:01
> To: Raphael Tryster
> Cc: megaco ietf
> I think your suggestion is a pragmatic one to define the 
> behaviour when a codec has not been already selected. An 
> alternative is to say that the MGC should not set the 
> rtp/pltrans event until an initial codec is used but the MGC 
> wouldn't know when this was.
>

---

From: "Raphael Tryster" <[email-masked]>
Date: Tue, 4 Sep 2007 09:14:06 +0300

Is B) something that doesn't exist yet and you are proposing it for Megaco version 4?

Raphael Tryster

-----Original Message-----
From: Schwarz Albrecht [mailto:[email-masked]] 
Sent: Tuesday, September 04, 2007 8:39 AM
To: Christian Groves; Raphael Tryster
Cc: megaco ietf
Subject: RE: [Megaco] Reporting actual codec used in a call

I could see two ways:

-Albrecht

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Tue, 4 Sep 2007 20:01:26 +0200

'B' does not yet exist.
Such a statistic should be a package issue, i.e. not related to a specific H.248.1 protocol version.

[Please note that I wouldn't see here a Context-level statistic (which could mean V4), it should be on H.248 Termination- and/or Stream-level (due to possible media conversion between Stream-/Terminations, e.g. voice transcoding). As ususual for existing H.248 statistics.] 

-Albrecht

> From: Raphael Tryster [mailto:[email-masked]] 
> Sent: Dienstag, 4. September 2007 08:14
> To: Schwarz Albrecht; Christian Groves
> Cc: megaco ietf
> Like to note that there are further aspects when using RTP 
> payload/packet type codepoint (PT) as information for used 
> codec in a call:
> 1) codec changes
> A) H.248.1 V3 & H.248.39 (see e.g. § 8.1 "Individual auditing 
> of Local and Remote SDP was introduced in H.248.1 Version 3")
> > I agree that it is not really specified what the initial 
> value would 
> > be.
> > I think your suggestion is a pragmatic one to define the behaviour 
> > when a codec has not been already selected. An alternative 
> is to say 
> > that the MGC should not set the rtp/pltrans event until an initial 
> > codec is used but the MGC wouldn't know when this was.
> > 
> > > There's to payload transition event in the RTP package 
> that can be 
> > > used,
> > >

---

From: Christian Groves <[email-masked]>
Date: Wed, 05 Sep 2007 09:26:34 +1000

Hello Raphael,

I tend to agree with Albrecht. H.248.1v4 wouldn't be needed for this. 
However the statistic would probably be closely related to H.248.1v3 
which allows statistics at a stream level.

Regards, Christian

Schwarz Albrecht wrote:
>>>>> Is there any package that allows the MG to report to the
>>>>>           
>>> MGC at the
>>>       
>>>> Thank you, Christian.  rtp/pltrans looks like a good way to
>>>>         
>>> report a
>>>       
>>>> assumption here that the initial codec is the first one
>>>>         
>>> listed in the
>>>       
>>>> SDP, and therefore an MG receiving rtp/pltrans in Events
>>>>         
>>> that chooses
>>>       
>>>>> Is there any package that allows the MG to report to the
>>>>>           
>>> MGC at the
>>>       
>>>>> a list of codecs, not all of which are actually used in 
>>>>>           
>> the call).
>>     
>>>>>  
>>>>>
>>>>> Raphael Tryster
>>>>>
>>>>>
>>>>>     
>>>>>           
>> ----------------------------------------------------------------------
>>     
>>>> --
>>>>   
>>>>