Re: Selection of media (m=) at MG

El 01/12/2011 15:22, Bhattacharjee, Arindam (Arindam) escribió:
> 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.

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
> 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 protected]]
> Sent: Thursday, December 01, 2011 5:03 AM
> To: [email protected]
> Cc: Bhattacharjee, Arindam (Arindam)
> Subject: Re: [Megaco] Selection of media (m=) at MG
>
> 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 protected] [mailto:[email protected]] On Behalf Of Javi Muñoz
>> Sent: Wednesday, November 30, 2011 1:31 PM
>> To: [email protected]
>> 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 protected]]
>>>>> Sent: Mittwoch, 30. November 2011 18:13
>>>>> To: [email protected]
>>>>> 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 protected]
>>> https://www.ietf.org/mailman/listinfo/megaco
>>>
>> _______________________________________________
>> Megaco mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/megaco
>>
>