Media Gateway Control (megaco)

headers Raphael Tryster | 15 Jun 2010 09:26

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco

I go for interpretation 2.

Raphael Tryster wrote:
> Megaco stipulates that detection of an event should stop any signal that
> is playing.  Does an existing hook state, reported immediately with
> init=true because the MGC requested strict=state, count as an event for
> the purpose of stopping signals?
> 
>  
> 
> If the answer is yes, then we could have the following scenario:
> 
>  
> 
> 1.       MG sends Notify al/of.
> 
> 2.       MGC sends Modify, requesting signal cg/dt, and events
> al/of{strict=state},al/on(strict=state}.
> 
> 3.       MG immediately sends Notify al/of{init=true}, and stops the
> dial tone!
> 
>  
> 
> A variation of the above is when the strict parameter is omitted, but
> the MG decides to assume strict=state because it is working with Megaco
> version 1 or 2, where no default is specified.
> 
>  
> 
> Possible conclusions:
> 
>  
> 
> 1.       This is not a real event and the signal should not be stopped.
> 
> 2.       This is a real event and the MGC is stupid to send such a
> command.
> 
> 3.       This is a real event, and if strict is not specified, the MG
> must assume strict=exact.
> 
>  
> 
> I await the experts' opinion.
> 
>  
> 
> Raphael Tryster
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco

Hello Raphael,

I think it is a real event so the behaviour would be to send the notify 
and stop the dial tone. So I think conclusion 2 is the one to take. 
However I think conclusion 3 is also applicable. Megaco v1, v2, or v3 
really is only for the syntax and procedures surrounding that. In the 
case of the Analog Line Supervision Package (al) the package version has 
remained at v1 for all Megaco versions. Therefore the inclusion of the 
default should be seen as correcting an omission. So the MG should 
assume strict=exact if strict is not specified (unless provisioned 
otherwise  ).

Regards, Christian

On 15/06/2010 5:26 PM, Raphael Tryster wrote:
>
> Megaco stipulates that detection of an event should stop any signal 
> that is playing.  Does an existing hook state, reported immediately 
> with init=true because the MGC requested strict=state, count as an 
> event for the purpose of stopping signals?
>
> If the answer is yes, then we could have the following scenario:
>
> 1. MG sends Notify al/of.
>
> 2. MGC sends Modify, requesting signal cg/dt, and events 
> al/of{strict=state},al/on(strict=state}.
>
> 3. MG immediately sends Notify al/of{init=true}, and stops the dial tone!
>
> A variation of the above is when the strict parameter is omitted, but 
> the MG decides to assume strict=state because it is working with 
> Megaco version 1 or 2, where no default is specified.
>
> Possible conclusions:
>
> 1. This is not a real event and the signal should not be stopped.
>
> 2. This is a real event and the MGC is stupid to send such a command.
>
> 3. This is a real event, and if strict is not specified, the MG must 
> assume strict=exact.
>
> I await the experts' opinion.
>
> Raphael Tryster
>
>
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
>    

Hello,

I start looking to H.248 protocol and studying what it can do and what can't.

I am not able to find any documents related to following topics/questions:

1) RFC2833/RFC2198
  - how the MGC can get RFC2833/RFC2198 capabilities from the MG? (used payload types, list of supported
tones, ...)
  - how the MGC can put peer  RFC2833/RFC2198 capabilities to the MG termination?

2) SRTP/MIKEY
 - is there any document how to use MIKEY within H.248 to negotiate SRTP contexted between the MG and peer
media endpoint ?(can be also H.248 MG but also any other kind of SRTP endpoint)

BTW I would prefer to use binary encoding of H.248 and if I understand it well it can not use SDP equivalent
properties, is it right?

Thanks in advance for any hint.

Best regards,
  Tomas

Thank you, Tom and Christian, for your replies.  The actual case that
prompted my question was one in which conclusion 3 applies.  As you
said, "unless provisioned otherwise" is very relevant, as we have had
interoperations in which it is necessary to assume a default of
strict=state.

Regards,
Raphael

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves <at> nteczone.com] 
Sent: Wednesday, 16 June 2010 2:56 AM
To: Raphael Tryster
Cc: megaco ietf
Subject: Re: [Megaco] Does an event generated by strict=state stop
signals?

Hello Raphael,

I think it is a real event so the behaviour would be to send the notify 
and stop the dial tone. So I think conclusion 2 is the one to take. 
However I think conclusion 3 is also applicable. Megaco v1, v2, or v3 
really is only for the syntax and procedures surrounding that. In the 
case of the Analog Line Supervision Package (al) the package version has

remained at v1 for all Megaco versions. Therefore the inclusion of the 
default should be seen as correcting an omission. So the MG should 
assume strict=exact if strict is not specified (unless provisioned 
otherwise  ).

Regards, Christian

On 15/06/2010 5:26 PM, Raphael Tryster wrote:
>
> Megaco stipulates that detection of an event should stop any signal 
> that is playing.  Does an existing hook state, reported immediately 
> with init=true because the MGC requested strict=state, count as an 
> event for the purpose of stopping signals?
>
> If the answer is yes, then we could have the following scenario:
>
> 1. MG sends Notify al/of.
>
> 2. MGC sends Modify, requesting signal cg/dt, and events 
> al/of{strict=state},al/on(strict=state}.
>
> 3. MG immediately sends Notify al/of{init=true}, and stops the dial
tone!
>
> A variation of the above is when the strict parameter is omitted, but 
> the MG decides to assume strict=state because it is working with 
> Megaco version 1 or 2, where no default is specified.
>
> Possible conclusions:
>
> 1. This is not a real event and the signal should not be stopped.
>
> 2. This is a real event and the MGC is stupid to send such a command.
>
> 3. This is a real event, and if strict is not specified, the MG must 
> assume strict=exact.
>
> I await the experts' opinion.
>
> Raphael Tryster
>
>
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
>    

to 1):
- RFC2833 is obsoleted by RFC 4733, ...! 
- just use the SDP elements as defined by the RFCs in the H.248 LD/RD
- it looks fairly strange to use H.248 binary encoding when such
SDP-controlled RTP capabilities are used in the IP domain; do you really
want to translate SDP text encoding at your MGC call control interface
in "SDP binary" format at H.248?

to 2):
- see Draft H.248.77 for H.248-controlled SRTP endpoints
- see 3GPP 23.334 and 29.334 as a first H.248 Profile with SRTP support

> negotiate SRTP contexted between the MG and peer media 
> endpoint ?(can be also H.248 MG but also any other kind of 

You refer to the IP media-path (RFC 5479) related keying methods for
SRTP.
Any procedures at the H.248 MG "IP media-path" interface are per se out
of scope of H.248.
If ... then subject of an H.248 profile specification.

> -----Original Message-----
> From: megaco-bounces <at> ietf.org 
> [mailto:megaco-bounces <at> ietf.org] On Behalf Of Kukosa, Tomas
> Sent: Donnerstag, 17. Juni 2010 10:59
> To: megaco <at> ietf.org
> Subject: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY
> 
> Hello,
> 
> I start looking to H.248 protocol and studying what it can do 
> and what can't.
> 
> I am not able to find any documents related to following 
> topics/questions:
> 
> 1) RFC2833/RFC2198
>   - how the MGC can get RFC2833/RFC2198 capabilities from the 
> MG? (used payload types, list of supported tones, ...)
>   - how the MGC can put peer  RFC2833/RFC2198 capabilities to 
> the MG termination?
> 
> 2) SRTP/MIKEY
>  - is there any document how to use MIKEY within H.248 to 
> negotiate SRTP contexted between the MG and peer media 
> endpoint ?(can be also H.248 MG but also any other kind of 
> SRTP endpoint)
> 
> BTW I would prefer to use binary encoding of H.248 and if I 
> understand it well it can not use SDP equivalent properties, 
> is it right?
> 
> Thanks in advance for any hint.
> 
> Best regards,
>   Tomas
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
> 

Hi,

thanky you for your response.

I would like to avoid SDP as it not my favorit protocol.

But I have not find any possibility how to map H.245 TCS to H.248.
Especially receiveRTPAudioTelephonyEventCapability and mediaPacketizationCapability.

I.e. my question does not come from SDP but from H.245 area.

Best regards,
  Tomas

-----Original Message-----
From: Schwarz Albrecht [mailto:Albrecht.Schwarz <at> alcatel-lucent.com] 
Sent: Thursday, June 17, 2010 2:02 PM
To: Kukosa, Tomas; megaco <at> ietf.org
Subject: RE: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY

to 1):
- RFC2833 is obsoleted by RFC 4733, ...! 
- just use the SDP elements as defined by the RFCs in the H.248 LD/RD
- it looks fairly strange to use H.248 binary encoding when such
SDP-controlled RTP capabilities are used in the IP domain; do you really
want to translate SDP text encoding at your MGC call control interface
in "SDP binary" format at H.248?

to 2):
- see Draft H.248.77 for H.248-controlled SRTP endpoints
- see 3GPP 23.334 and 29.334 as a first H.248 Profile with SRTP support

> negotiate SRTP contexted between the MG and peer media 
> endpoint ?(can be also H.248 MG but also any other kind of 

You refer to the IP media-path (RFC 5479) related keying methods for
SRTP.
Any procedures at the H.248 MG "IP media-path" interface are per se out
of scope of H.248.
If ... then subject of an H.248 profile specification.

> -----Original Message-----
> From: megaco-bounces <at> ietf.org 
> [mailto:megaco-bounces <at> ietf.org] On Behalf Of Kukosa, Tomas
> Sent: Donnerstag, 17. Juni 2010 10:59
> To: megaco <at> ietf.org
> Subject: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY
> 
> Hello,
> 
> I start looking to H.248 protocol and studying what it can do 
> and what can't.
> 
> I am not able to find any documents related to following 
> topics/questions:
> 
> 1) RFC2833/RFC2198
>   - how the MGC can get RFC2833/RFC2198 capabilities from the 
> MG? (used payload types, list of supported tones, ...)
>   - how the MGC can put peer  RFC2833/RFC2198 capabilities to 
> the MG termination?
> 
> 2) SRTP/MIKEY
>  - is there any document how to use MIKEY within H.248 to 
> negotiate SRTP contexted between the MG and peer media 
> endpoint ?(can be also H.248 MG but also any other kind of 
> SRTP endpoint)
> 
> BTW I would prefer to use binary encoding of H.248 and if I 
> understand it well it can not use SDP equivalent properties, 
> is it right?
> 
> Thanks in advance for any hint.
> 
> Best regards,
>   Tomas
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
> 

Sounds like a topic for H.248.12, if H.245-to-H.248 interworking
aspects, right?
Perhaps you need an extension/upversion of the H.248.12 H245 Package.
Do you terminate H.245 at MG or MGC level?
Did you already consider H.248.12?

> -----Original Message-----
> From: megaco-bounces <at> ietf.org 
> [mailto:megaco-bounces <at> ietf.org] On Behalf Of Kukosa, Tomas
> Sent: Freitag, 18. Juni 2010 09:30
> To: megaco <at> ietf.org
> Subject: Re: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY
> 
> Hi,
> 
> thanky you for your response.
> 
> I would like to avoid SDP as it not my favorit protocol.
> 
> But I have not find any possibility how to map H.245 TCS to H.248.
> Especially receiveRTPAudioTelephonyEventCapability and 
> mediaPacketizationCapability.
> 
> I.e. my question does not come from SDP but from H.245 area.
> 
> Best regards,
>   Tomas
> 
> 
> -----Original Message-----
> From: Schwarz Albrecht [mailto:Albrecht.Schwarz <at> alcatel-lucent.com]
> Sent: Thursday, June 17, 2010 2:02 PM
> To: Kukosa, Tomas; megaco <at> ietf.org
> Subject: RE: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY
> 
> to 1):
> - RFC2833 is obsoleted by RFC 4733, ...! 
> - just use the SDP elements as defined by the RFCs in the H.248 LD/RD
> - it looks fairly strange to use H.248 binary encoding when 
> such SDP-controlled RTP capabilities are used in the IP 
> domain; do you really want to translate SDP text encoding at 
> your MGC call control interface in "SDP binary" format at H.248?
> 
> to 2):
> - see Draft H.248.77 for H.248-controlled SRTP endpoints
> - see 3GPP 23.334 and 29.334 as a first H.248 Profile with 
> SRTP support
> 
> > negotiate SRTP contexted between the MG and peer media 
> endpoint ?(can 
> > be also H.248 MG but also any other kind of
> 
> You refer to the IP media-path (RFC 5479) related keying 
> methods for SRTP.
> Any procedures at the H.248 MG "IP media-path" interface are 
> per se out of scope of H.248.
> If ... then subject of an H.248 profile specification.
> 
> 
> > -----Original Message-----
> > From: megaco-bounces <at> ietf.org
> > [mailto:megaco-bounces <at> ietf.org] On Behalf Of Kukosa, Tomas
> > Sent: Donnerstag, 17. Juni 2010 10:59
> > To: megaco <at> ietf.org
> > Subject: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY
> > 
> > Hello,
> > 
> > I start looking to H.248 protocol and studying what it can 
> do and what 
> > can't.
> > 
> > I am not able to find any documents related to following
> > topics/questions:
> > 
> > 1) RFC2833/RFC2198
> >   - how the MGC can get RFC2833/RFC2198 capabilities from the MG? 
> > (used payload types, list of supported tones, ...)
> >   - how the MGC can put peer  RFC2833/RFC2198 capabilities 
> to the MG 
> > termination?
> > 
> > 2) SRTP/MIKEY
> >  - is there any document how to use MIKEY within H.248 to negotiate 
> > SRTP contexted between the MG and peer media endpoint ?(can be also 
> > H.248 MG but also any other kind of SRTP endpoint)
> > 
> > BTW I would prefer to use binary encoding of H.248 and if I 
> understand 
> > it well it can not use SDP equivalent properties, is it right?
> > 
> > Thanks in advance for any hint.
> > 
> > Best regards,
> >   Tomas
> > _______________________________________________
> > Megaco mailing list
> > Megaco <at> ietf.org
> > https://www.ietf.org/mailman/listinfo/megaco
> > 
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
> 

Hello Tomas,

There's no description on how to map H.245 TCS to H.248 as I think that 
it is commonly assumed that the MGC will receive the H.245 TCS directly 
or tunnelled through the MG (as provided by by H.248.12). The MGC will 
apply what ever logic is required and then issue the appropriate H.248 
commands. There is not necessary a 1:1 mapping of the information.

For example "receiveRTPAudioTelephonyEventCapability" broadly maps into 
H.248 ability to set events to detect tones (e.g. H.248.1  annex E.6) 
and to send signals to initiate tones (e.g. H.248.1 annex E.7). The 
method to indicate these is the same whether text or binary is used. The 
payload type can be specified by H.248.1 annex C.1 "rtppayload".

I do note that there have been a number of additions to H.245 in recent 
years to address additions to SDP. Neither H.248.1 Annex C nor H.248.12 
has been updated specifically for these. So any proposals for 
enhancements are welcome.

Regards, Christian

On 19/06/2010 8:11 PM, Schwarz Albrecht wrote:
>
> Sounds like a topic for H.248.12, if H.245-to-H.248 interworking
> aspects, right?
> Perhaps you need an extension/upversion of the H.248.12 H245 Package.
> Do you terminate H.245 at MG or MGC level?
> Did you already consider H.248.12?
>
>    
>> -----Original Message-----
>> From: megaco-bounces <at> ietf.org
>> [mailto:megaco-bounces <at> ietf.org] On Behalf Of Kukosa, Tomas
>> Sent: Freitag, 18. Juni 2010 09:30
>> To: megaco <at> ietf.org
>> Subject: Re: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY
>>
>> Hi,
>>
>> thanky you for your response.
>>
>> I would like to avoid SDP as it not my favorit protocol.
>>
>> But I have not find any possibility how to map H.245 TCS to H.248.
>> Especially receiveRTPAudioTelephonyEventCapability and
>> mediaPacketizationCapability.
>>
>> I.e. my question does not come from SDP but from H.245 area.
>>
>> Best regards,
>>    Tomas
>>
>>
>> -----Original Message-----
>> From: Schwarz Albrecht [mailto:Albrecht.Schwarz <at> alcatel-lucent.com]
>> Sent: Thursday, June 17, 2010 2:02 PM
>> To: Kukosa, Tomas; megaco <at> ietf.org
>> Subject: RE: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY
>>
>> to 1):
>> - RFC2833 is obsoleted by RFC 4733, ...!
>> - just use the SDP elements as defined by the RFCs in the H.248 LD/RD
>> - it looks fairly strange to use H.248 binary encoding when
>> such SDP-controlled RTP capabilities are used in the IP
>> domain; do you really want to translate SDP text encoding at
>> your MGC call control interface in "SDP binary" format at H.248?
>>
>> to 2):
>> - see Draft H.248.77 for H.248-controlled SRTP endpoints
>> - see 3GPP 23.334 and 29.334 as a first H.248 Profile with
>> SRTP support
>>
>>      
>>> negotiate SRTP contexted between the MG and peer media
>>>        
>> endpoint ?(can
>>      
>>> be also H.248 MG but also any other kind of
>>>        
>> You refer to the IP media-path (RFC 5479) related keying
>> methods for SRTP.
>> Any procedures at the H.248 MG "IP media-path" interface are
>> per se out of scope of H.248.
>> If ... then subject of an H.248 profile specification.
>>
>>
>>      
>>> -----Original Message-----
>>> From: megaco-bounces <at> ietf.org
>>> [mailto:megaco-bounces <at> ietf.org] On Behalf Of Kukosa, Tomas
>>> Sent: Donnerstag, 17. Juni 2010 10:59
>>> To: megaco <at> ietf.org
>>> Subject: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY
>>>
>>> Hello,
>>>
>>> I start looking to H.248 protocol and studying what it can
>>>        
>> do and what
>>      
>>> can't.
>>>
>>> I am not able to find any documents related to following
>>> topics/questions:
>>>
>>> 1) RFC2833/RFC2198
>>>    - how the MGC can get RFC2833/RFC2198 capabilities from the MG?
>>> (used payload types, list of supported tones, ...)
>>>    - how the MGC can put peer  RFC2833/RFC2198 capabilities
>>>        
>> to the MG
>>      
>>> termination?
>>>
>>> 2) SRTP/MIKEY
>>>   - is there any document how to use MIKEY within H.248 to negotiate
>>> SRTP contexted between the MG and peer media endpoint ?(can be also
>>> H.248 MG but also any other kind of SRTP endpoint)
>>>
>>> BTW I would prefer to use binary encoding of H.248 and if I
>>>        
>> understand
>>      
>>> it well it can not use SDP equivalent properties, is it right?
>>>
>>> Thanks in advance for any hint.
>>>
>>> Best regards,
>>>    Tomas
>>> _______________________________________________
>>> Megaco mailing list
>>> Megaco <at> ietf.org
>>> https://www.ietf.org/mailman/listinfo/megaco
>>>
>>>        
>> _______________________________________________
>> Megaco mailing list
>> Megaco <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/megaco
>>
>>      
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
> .
>
>    

Hello Christian,

thank you very much for all your hints!

I will look at all mentioned documents and chapters.

Best regards,
  Tomas 

-----Original Message-----
From: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of Christian Groves
Sent: Monday, June 21, 2010 5:53 AM
To: megaco <at> ietf.org
Subject: Re: [Megaco] H.323/H.245 interworking (H.248.12); RE: H.248 using RFC2833/RFC2198 and SRTP/MIKEY

Hello Tomas,

There's no description on how to map H.245 TCS to H.248 as I think that 
it is commonly assumed that the MGC will receive the H.245 TCS directly 
or tunnelled through the MG (as provided by by H.248.12). The MGC will 
apply what ever logic is required and then issue the appropriate H.248 
commands. There is not necessary a 1:1 mapping of the information.

For example "receiveRTPAudioTelephonyEventCapability" broadly maps into 
H.248 ability to set events to detect tones (e.g. H.248.1  annex E.6) 
and to send signals to initiate tones (e.g. H.248.1 annex E.7). The 
method to indicate these is the same whether text or binary is used. The 
payload type can be specified by H.248.1 annex C.1 "rtppayload".

I do note that there have been a number of additions to H.245 in recent 
years to address additions to SDP. Neither H.248.1 Annex C nor H.248.12 
has been updated specifically for these. So any proposals for 
enhancements are welcome.

Regards, Christian

On 19/06/2010 8:11 PM, Schwarz Albrecht wrote:
>
> Sounds like a topic for H.248.12, if H.245-to-H.248 interworking
> aspects, right?
> Perhaps you need an extension/upversion of the H.248.12 H245 Package.
> Do you terminate H.245 at MG or MGC level?
> Did you already consider H.248.12?
>
>    
>> -----Original Message-----
>> From: megaco-bounces <at> ietf.org
>> [mailto:megaco-bounces <at> ietf.org] On Behalf Of Kukosa, Tomas
>> Sent: Freitag, 18. Juni 2010 09:30
>> To: megaco <at> ietf.org
>> Subject: Re: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY
>>
>> Hi,
>>
>> thanky you for your response.
>>
>> I would like to avoid SDP as it not my favorit protocol.
>>
>> But I have not find any possibility how to map H.245 TCS to H.248.
>> Especially receiveRTPAudioTelephonyEventCapability and
>> mediaPacketizationCapability.
>>
>> I.e. my question does not come from SDP but from H.245 area.
>>
>> Best regards,
>>    Tomas
>>
>>
>> -----Original Message-----
>> From: Schwarz Albrecht [mailto:Albrecht.Schwarz <at> alcatel-lucent.com]
>> Sent: Thursday, June 17, 2010 2:02 PM
>> To: Kukosa, Tomas; megaco <at> ietf.org
>> Subject: RE: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY
>>
>> to 1):
>> - RFC2833 is obsoleted by RFC 4733, ...!
>> - just use the SDP elements as defined by the RFCs in the H.248 LD/RD
>> - it looks fairly strange to use H.248 binary encoding when
>> such SDP-controlled RTP capabilities are used in the IP
>> domain; do you really want to translate SDP text encoding at
>> your MGC call control interface in "SDP binary" format at H.248?
>>
>> to 2):
>> - see Draft H.248.77 for H.248-controlled SRTP endpoints
>> - see 3GPP 23.334 and 29.334 as a first H.248 Profile with
>> SRTP support
>>
>>      
>>> negotiate SRTP contexted between the MG and peer media
>>>        
>> endpoint ?(can
>>      
>>> be also H.248 MG but also any other kind of
>>>        
>> You refer to the IP media-path (RFC 5479) related keying
>> methods for SRTP.
>> Any procedures at the H.248 MG "IP media-path" interface are
>> per se out of scope of H.248.
>> If ... then subject of an H.248 profile specification.
>>
>>
>>      
>>> -----Original Message-----
>>> From: megaco-bounces <at> ietf.org
>>> [mailto:megaco-bounces <at> ietf.org] On Behalf Of Kukosa, Tomas
>>> Sent: Donnerstag, 17. Juni 2010 10:59
>>> To: megaco <at> ietf.org
>>> Subject: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY
>>>
>>> Hello,
>>>
>>> I start looking to H.248 protocol and studying what it can
>>>        
>> do and what
>>      
>>> can't.
>>>
>>> I am not able to find any documents related to following
>>> topics/questions:
>>>
>>> 1) RFC2833/RFC2198
>>>    - how the MGC can get RFC2833/RFC2198 capabilities from the MG?
>>> (used payload types, list of supported tones, ...)
>>>    - how the MGC can put peer  RFC2833/RFC2198 capabilities
>>>        
>> to the MG
>>      
>>> termination?
>>>
>>> 2) SRTP/MIKEY
>>>   - is there any document how to use MIKEY within H.248 to negotiate
>>> SRTP contexted between the MG and peer media endpoint ?(can be also
>>> H.248 MG but also any other kind of SRTP endpoint)
>>>
>>> BTW I would prefer to use binary encoding of H.248 and if I
>>>        
>> understand
>>      
>>> it well it can not use SDP equivalent properties, is it right?
>>>
>>> Thanks in advance for any hint.
>>>
>>> Best regards,
>>>    Tomas
>>> _______________________________________________
>>> Megaco mailing list
>>> Megaco <at> ietf.org
>>> https://www.ietf.org/mailman/listinfo/megaco
>>>
>>>        
>> _______________________________________________
>> Megaco mailing list
>> Megaco <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/megaco
>>
>>      
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
> .
>
>    
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco

3	April 2013
10	March 2013
1	February 2013
1	January 2013
3	December 2012
2	October 2012
4	September 2012
13	August 2012
3	July 2012
3	June 2012
3	May 2012
3	March 2012
9	February 2012
7	January 2012
45	December 2011
23	November 2011
21	October 2011
1	September 2011
3	August 2011
11	July 2011
4	June 2011
13	May 2011
6	April 2011
2	March 2011
13	February 2011
4	January 2011
7	December 2010
4	November 2010
6	October 2010
5	August 2010
15	July 2010
14	June 2010
1	May 2010
9	March 2010
22	February 2010
1	January 2010
20	December 2009
6	November 2009
14	October 2009
28	September 2009
17	August 2009
13	July 2009
19	June 2009
32	May 2009
7	April 2009
3	March 2009
12	February 2009
6	January 2009
9	December 2008
15	November 2008
10	October 2008
30	September 2008
21	August 2008
19	July 2008
17	June 2008
24	May 2008
23	April 2008
31	March 2008
38	February 2008
73	January 2008
73	December 2007
16	November 2007
49	October 2007
35	September 2007
38	August 2007
42	July 2007
65	June 2007
45	May 2007
69	April 2007
50	March 2007
61	February 2007
66	January 2007
37	December 2006
41	November 2006
38	October 2006
32	September 2006
60	August 2006
94	July 2006
25	June 2006
76	May 2006
40	April 2006
61	March 2006
94	February 2006
65	January 2006
63	December 2005
86	November 2005
65	October 2005
101	September 2005
73	August 2005
82	July 2005
133	June 2005
50	May 2005
84	April 2005
49	March 2005
40	February 2005
49	January 2005
55	December 2004
77	November 2004
31	October 2004
43	September 2004
51	August 2004
38	July 2004
51	June 2004
42	May 2004
60	April 2004
85	March 2004
61	February 2004
113	January 2004
94	December 2003
87	November 2003
58	October 2003
75	September 2003
44	August 2003
36	July 2003
82	June 2003
68	May 2003
104	April 2003
89	March 2003
58	February 2003
119	January 2003
57	December 2002
106	November 2002
191	October 2002
145	September 2002
153	August 2002
283	July 2002
169	June 2002
300	May 2002
217	April 2002

Does an event generated by strict=state stop signals?

Re: Does an event generated by strict=state stop signals?

Re: Does an event generated by strict=state stop signals?

H.248 using RFC2833/RFC2198 and SRTP/MIKEY

Re: Does an event generated by strict=state stop signals?

Re: H.248 using RFC2833/RFC2198 and SRTP/MIKEY

Re: H.248 using RFC2833/RFC2198 and SRTP/MIKEY

H.323/H.245 interworking (H.248.12); RE: H.248 using RFC2833/RFC2198 and SRTP/MIKEY

Re: H.323/H.245 interworking (H.248.12); RE: H.248 using RFC2833/RFC2198 and SRTP/MIKEY

Re: H.323/H.245 interworking (H.248.12); RE: H.248 using RFC2833/RFC2198 and SRTP/MIKEY

Mon	Tue	Wed	Thu	Fri	Sat	Sun

	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30