Subject: Re: [Megaco] Selection of media (m=) at MG

From: Javi Muñoz <[email-masked]>
Date: Thu, 01 Dec 2011 11:03:02 +0100

Hello Arindam,

El 30/11/2011 21:20, Bhattacharjee, Arindam (Arindam) escribió:
> Hi Javi,
> + call establishment phase: H.248 Command.req for tone/announcement
> control plus media configuration with voice codec
>> You can do that by using reservevalue =ON in Local control and send SDP offer for both G711 and ClearMode.
>> Thus AGW should be able to encode/decode g711 and reserves resource for clearmode.

I understand you mean that I use:

m=audio <puerto> RTP/AVP <PT_dinámico> 0 [8]
a=rtpmap:<PT_dinámico> CLEARMODE/8000

But, how may we indicate to the MG that it uses G.711, and it only 
reserves resources for the CLEARMODE?

Regards,

Javi

> + information phase: H.248 Command.req for modification of the media
> configuration towards CLEARMODE
>> in this phase MGC may send reservevalue =OFF with SDP ClearMode only, releasing G711 resource.
> -Arindam
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Javi Muñoz
> Sent: Wednesday, November 30, 2011 1:31 PM
> To: [email-masked]
> Subject: Re: [Megaco] Selection of media (m=) at MG
>
> An aditional comment,
>
> if, as we said, we admit the following behavior:
>
> + call establishment phase: H.248 Command.req for tone/announcement
> control plus media configuration with voice codec
> + information phase: H.248 Command.req for modification of the media
> configuration towards CLEARMODE
>
>
> The following could happen:
>
> 1º Call starts and command.req for tone/announcement is applied.
>
> 2º When MGC needs to change to the information phase, the MG responds it
> does not support the CLEARMODE due to insufficient resources (MGC may
> audit the MG before the call to check it supports CLEARMODE, but MGC can
> not know how its resources will change during the call).
>
> In that case, it would not be possible to continue a call that has
> already begun, which should not happen. The SDP description should
> ensure to the MGC that the MG reserves the resources needed by the call
> prior to the establishment of it.
>
> If this is true, it would not be valid to use the modify command between
> the establishment and information phases.
>
> Regards,
>
> Javi
>
>
> El 30/11/2011 18:44, Javi Muñoz escribió:
>>> well spotted, thus just a single media configuration ('Clearmode')
>>> would be already sufficient to emulate that ISDN bearer service
>> However, two comments:
>>
>> (a) In the "call establishment phase": what must be created at the
>> MG?: would it be necessary to create a context, or would it be enough
>> to create only an ISDN termination in the null context (which would
>> generate that tone/announcement, and then, MGC would apply a modify
>> command to create the context for the information phase)?
>>
>> (b) I believe, the announcement do not necessarily have to be recorded
>> in AGW, but that may come from an announcement server (I guess this
>> would also be possible for DTMF tones). Could this justify the
>> creation of such IP termination with voice codec G.711 in the
>> establishment phase, or that communication with the announcement
>> server does not belong to the ISDN call and, therefore, it should not
>> be involved in its Megaco context?
>>
>> Regards,
>>
>>
>>
>>> PS
>>> Your previous email was related to ISDN-to-SIP interworking at call
>>> control level, a subject which is out of scope of MEGACO.
>>> Thus, something for SIPPING, SIP-IMPLEMENTERS, ... (or TISPAN WG3
>>> list) in my understanding.
>>>
>>>> -----Original Message-----
>>>> From: Javi Muñoz [mailto:[email-masked]]
>>>> Sent: Mittwoch, 30. November 2011 18:13
>>>> To: [email-masked]
>>>> Cc: Schwarz, Albrecht (Albrecht)
>>>> Subject: Re: [Megaco] Selection of media (m=) at MG
>>>>
>>>> A second comment,
>>>>
>>>> If:
>>>>>>       a) TGW: no impact, because tone/announcement inserted by ISDN
>>>>>> local exchange (terminating Q.931); TGW needs just
>>>> clearmode support
>>>>
>>>> (I agree)
>>>>
>>>> then, why?
>>>>>> E.g., MGC
>>>>>> ->    call establishment phase: IF tones/announcements THEN H.248
>>>>>> Command.req for tone/announcement control plus media configuration
>>>>>> with voice codec
>>>> That "media configuration with voice codec" (G.711) would be
>>>> done at the MeGaCo termination of the IP side of the MG, not
>>>> at the termination of the ISDN side. If tone/announcement is
>>>> inserted (in the UNI ISDN) by this MG, the termination of the
>>>> IP side of the MG would not be used, so that "voice codec"
>>>> would not be relevant (no media would be transported over the
>>>> IP network).
>>>>
>>>> am I wrong?
>>>>
>>>> Regards,
>>>>
>>>> Javi
>>>>
>> _______________________________________________
>> Megaco mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/megaco
>>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/megaco
>

---

From: "Bhattacharjee, Arindam (Arindam)" <[email-masked]>
Date: Thu, 1 Dec 2011 08:22:56 -0600

Hi Javi,
MG will resereve both resources and be able to decode both the codecs. Now if in the remote end the announcement server only uses g711 to send pkts then MG will decode only g711 pkts, but will send g711 pkts since remote sdp is g711 only.
So in this case, phase 1:  local SDP will have both clearmode and g711 and remote SDP will have only G711. Of course MG should make sure that Clearmode DSP resourse is reserved for both encoder/decoder, which is normally implicit in this case. 
In case of phase 2  both local and remote will have Clearmode with reserve value =off.

More elaborate implementation of this scenario is under discussion now on H.248.80. Albrecht will know more about the status of that document.

-Arindam 

-----Original Message-----
From: Javi Muñoz [mailto:[email-masked]] 
Sent: Thursday, December 01, 2011 5:03 AM
To: [email-masked]
Cc: Bhattacharjee, Arindam (Arindam)
Subject: Re: [Megaco] Selection of media (m=) at MG

Hello Arindam,

Regards,

Javi

---

From: Javi Muñoz <[email-masked]>
Date: Thu, 01 Dec 2011 17:49:58 +0100

> So in this case, phase 1:  local SDP will have both clearmode and g711 and remote SDP will have only G711. Of course MG should make sure that Clearmode DSP resourse is reserved for both encoder/dec…

You mean that if we indicate a codec (such as "Clearmode") in the Local 
descriptor (decoder), MG must reserve resources for decoder and encoder 
(although that codec is not specified in the Remote descriptor).

Is that so specified by [H.248.1] or is it part of the Recommendation 
[H.248.80]?

regards,

Javi
> m=audio<puerto>  RTP/AVP<PT_dinámico>  0 [8]

---

From: "Bhattacharjee, Arindam (Arindam)" <[email-masked]>
Date: Thu, 1 Dec 2011 12:27:59 -0600

descriptor (decoder), MG must reserve resources for decoder and encoder 
(although that codec is not specified in the Remote descriptor).
Yes, and this is as per H.248.1: when local descriptor has both codecs g711 and clearmode and g711 in remote MG needs to add only decoders for both and encoder for g711 only, but in practice normally both decoder and encoder is reserved for all the codecs.

You can use another option: have reserve value on and use both g711 and Clearmode on both remote and local SDP and MG will send in g711 only because that has higher preference when G711 appears before CLearMode codec in the list as follows:

 m=audio<puerto>  RTP/AVP 0 [8] <PT_dinámico>  
 a=rtpmap:<PT_dinámico>  CLEARMODE/8000

In H.248.80 is based on draft-ietf-mmusic-sdp-capability-negotiation-12.txt and uses potential and latent configuration, but that's still under discussion, so you have to use those two options for now.
-Arindam   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Javi Muñoz
Sent: Thursday, December 01, 2011 11:50 AM
To: [email-masked]
Cc: Bhattacharjee, Arindam (Arindam)
Subject: Re: [Megaco] Selection of media (m=) at MG

regards,

Javi

---

From: Javi Muñoz <[email-masked]>
Date: Thu, 01 Dec 2011 19:42:41 +0100

Arindam,

>   m=audio<puerto>   RTP/AVP 0 [8]<PT_dinámico>

When the Remote descriptor has several audio codecs in the line "m=":

  m=audio<puerto>   RTP/AVP 0 [8]<PT_dinámico>   

I understand that:

1º First codec in the line is used if it is possible.

2º In case that codec may not be used (for an error, for example), the 
second codec would be tried (I understand this is the reaseon why the 
Remote descriptor may have several audio codecs in the same line "m=).

If it is so, and we use:

  m=audio<puerto>   RTP/AVP 0 [8]<PT_dinámico>   

What would happen if when MG needs to send the tone/ann., the codecs "0" 
and "8" may not be used?. MG would try to send the tone/ann. to the 
terminal using CLEARMODE, when terminal is not ready to receive that.

Javi

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 1 Dec 2011 16:15:04 -0600

> What would happen if when MG needs to send the tone/annc., the 
> codecs "0" 
> and "8" may not be used?. MG would try to send the tone/annc. to the 

The codec used on IP term side do not impact the data format sent on ISDN term.
(but it impacts the content due to use of lossy or lossless codec on IP).

CLEARMODE only tells the GW to turn off any encoding/decoding/echo-cancellation/DTMF etc.
and send the received data as is on either side. 

In fact, when a signal (tone/annc) is played on one termination (signal going outside of the context),
the termination is temporarily "disconnected oneway" (so it won't receive any data, but can send) from 
the other terminations (as if the termination has "oneway" topology to others).

-Raju

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Javi Muñoz
> Sent: Thursday, December 01, 2011 12:43 PM
> To: [email-masked]
> > You can use another option: have reserve value on and use 
> both g711 and Clearmode on both remote and local SDP and MG 
> will send in g711 only because that has higher preference 
> when G711 appears before CLearMode codec in the list as follows:
> >

---

From: Javi Muñoz <[email-masked]>
Date: Fri, 02 Dec 2011 13:08:54 +0100

Albrecht,

I complete my comment "(b)":

[ETSI TS 183 002 Clause 7.1.4]
Access Gateways may be able to store recorded announcements and shall 
support the generic announcement package. Generic Announcement (ITU-T 
Rec. H.248.7 [18]): mandatory if local announcements are available.
When the announcement to be delivered is not available in the gateway 
and cannot be autonomously retrieved by the gateway from a remote 
repository, the MGC shall initiate a connection to an external 
announcement machine, by temporarily adding a termination into the 
context. Instructions to play announcements are sent directly from the 
MGC to the server. The announcement server may itself be implemented as 
an MG, controlled using the H.248 protocol. However, this interface is 
outside the scope of the present document. In an originating MG, the 
context topology and the termination modes shall be configured in such a 
way that in-band information can be received from the remote side before 
the called party's answer. This setting shall occur not later than the 
receipt of the ACO message (or an equivalent message from another 
signalling protocol that ISUP).

Regards,

Javi

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Sat, 3 Dec 2011 10:09:10 +0100

yes, (b) is the media server scenario.
E.g. an IMS media server, called MRFP, control via "H.248 Mp profile" (3GPP 29.333)

> Sent: Freitag, 2. Dezember 2011 13:09
> To: [email-masked]
> Access Gateways may be able to store recorded announcements 
> and shall support the generic announcement package. Generic 
> Announcement (ITU-T Rec. H.248.7 [18]): mandatory if local 
> announcements are available.
> When the announcement to be delivered is not available in the 
> gateway and cannot be autonomously retrieved by the gateway 
> from a remote repository, the MGC shall initiate a connection 
> to an external announcement machine, by temporarily adding a 
> termination into the context. Instructions to play 
> announcements are sent directly from the MGC to the server. 
> The announcement server may itself be implemented as an MG, 
> controlled using the H.248 protocol. However, this interface 
> is outside the scope of the present document. In an 
> originating MG, the context topology and the termination 
> modes shall be configured in such a way that in-band 
> information can be received from the remote side before the 
> called party's answer. This setting shall occur not later 
> than the receipt of the ACO message (or an equivalent message 
> from another signalling protocol that ISUP).
> 
> Regards,
> 
> Javi
> >
> >>> That "media configuration with voice codec" (G.711) would 
> be done at 
> >>> the MeGaCo termination of the IP side of the MG, not at the 
> >>> termination of the ISDN side. If tone/announcement is 
> inserted (in 
> >>> the UNI ISDN) by this MG, the termination of the IP side 
> of the MG 
> >>> would not be used, so that "voice codec"
> >>> would not be relevant (no media would be transported over the IP 
> >>> network).
> >>>
> >>> am I wrong?
> >>>
> >>> Regards,
> >>>
> >>> Javi
> >>>
> >
> 
>

---

From: Javi Muñoz <[email-masked]>
Date: Mon, 12 Dec 2011 12:31:37 +0100

Raju,
> the other terminations (as if the termination has "oneway" topology to others).
When a signal is played by the MG, does the MG automatically applied 
that "oneway" topology, or it should be explicitly indicated by the MGC 
in the configuration of the termination?(it would be on the Stream, 
rather than on the termination, since it migth be a multistream termination)

Javi

---

From: Javi Muñoz <[email-masked]>
Date: Mon, 12 Dec 2011 13:11:03 +0100

Raju,

In addition, [TS 183 002/Clause 7.1.4] indicates that if announcement 
are remote to MG, "the MGC shall initiate a connection to an external 
announcement machine (MRF), by
temporarily adding a termination into the context.".

I understand that this context should be the same that contains the 
termination play announcements. For example, in:

TE <--->  MG <--->  MRF

MG must ge the announcements from MRF and play them to TE. For that, I 
understand MGC must create the next contexto in the MG:

TE <-- [Termination A (codec PCMU)] -- *  -- [Termination B (codec 
PCMU)] --> MRF

So, termination B is used to get the announcements, and termination A is 
used to play them.

But, if "when a signal (tone/annc) is played on one termination, the 
termination is temporarily disconnected oneway", then while termination 
A playing a announcement, it can not continue to receive announcement 
that continue to get the termination B.

Javi

El 12/12/2011 12:31, Javi Muñoz escribió:
> that "oneway" topology, or it should be explicitly indicated by the 
> MGC in the configuration of the termination?(it would be on the 
> Stream, rather than on the termination, since it migth be a 
> multistream termination)
>
> Javi
>>

---

From: Javi Muñoz <[email-masked]>
Date: Mon, 12 Dec 2011 18:40:50 +0100

Raju,
> the other terminations (as if the termination has "oneway" topology to 
A more.

What document or Recommendation defines exactly this behavior of a 
termination for sending tones / announcements?

Regards,

Javi

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 12 Dec 2011 16:32:15 -0600

Javi,

> Raju,
> > In fact, when a signal (tone/annc) is played on one 
> termination (signal going outside of the context),
> > the termination is temporarily "disconnected oneway" (so it 
> won't receive any data, but can send) from
[Raju] I just gave "topology" example to make it clear.
MGC won't include such a topology while playing a signal.
On MG it is implicit that when it is playing a signal, which
actually sends data on a termination, any other data that needs to 
be sent to be stopped/dropped temporarily until signal is completed
(else MG has to mix the two data together.. Which won't work
always due to the special nature of signals. For example
when MG is playing a DTMF tone signal, other voice data can't be mixed
with DTMF).

Regards
Raju

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 12 Dec 2011 16:42:49 -0600

Javi,
 
> > the other terminations (as if the termination has "oneway" 
> topology to 
> > others).
> >>
> A more.
> 
[Raju] I could not find any explicit mention of such procedure in H.248.1.
As I explained in other mail, I believe it is implicit by "playing the
signal (no mixing)" we just want the signal to be delivered to the
termination (if the signal is of nature which actually sends, like tone/annc,
data to the termination as opposed to some signals, like ipnapt/latch signal which
won't send any data to the termination).

You may search MEGACO lists or implementers guide to find relevant discussions.
http://www.itu.int/rec/T-REC-H.Imp248-201007-I/en

Regards
Raju

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 12 Dec 2011 16:46:45 -0600

Javi,

> that continue to get the termination B.
[Raju] In this case where MRF is playing announcement, there is no signal
played either on Termination A or B. MRF sends the announcement RTP bearer
packets to termination B which in turn forwards them to A and then to UE.
Terminations A and B are not aware of the actual contents of the bearer,
it could be a tone, announcement or a some other media.

Regards
raju

> topology 
> >> to others).

---

From: Christian Groves <[email-masked]>
Date: Tue, 13 Dec 2011 10:21:40 +1100

Hello Javi and Raju,

The sending of signals is defined in H.248.1 clause 7.1.11. i.e. 
"Signals are defined as proceeding from the termination towards the 
exterior of the context unless otherwise specified."

Tones/Announcements are just one type of signal.

With regards to "disconnected oneway", there isn't any change in the 
Streammode or Topology descriptor as a result of a signal.

Regards, Christian