gmane.ietf.megaco

Re: 3GPP RTP header extension

Schwarz, Albrecht (Albrecht — 2013-06-03T08:10:10

The subject was also on the agenda of 3GPP CT4 at last meeting.

It may be noted that RFC 5285 is special with regards to the definition of two capabilities of
a) IP data path (RTP header extension; clause 4/RFC 5285) and
b) IP signaling path (SDP signalling; ; clauses 5&6/RFC 5285)
in a single RFC. Both capabilities could be also defined in separated RFCs.

The tight coupling of both capabilities in a single RFC may be interpreted in the following: the network should not forward RTP packets with extended headers in case of missing SDP "a=extmap:" signalling or/and failed SDP O/A.

E.g., an interim RTP translator (RTP transport translator or RTP media translator) would block RTP packets with extension headers (dependent on above SDP O/A ...).

Conclusion:
there seems to be some implicit semantics in RFC 5285 in my understanding.

Regards,
Albrecht


From: mmusic-bounces< at >ietf.org [mailto:mmusic-bounces< at >ietf.org] On Behalf Of Christer Holmberg
Sent: Freitag, 24. Mai 2013 12:06
To: mmusic< at >ietf.org
Subject: [MMUSIC] 3GPP RTP header extension

Hi,

In the virtual interim meeting yesterday, I was requested to look into the RTP header extension(s) defined by 3GPP.

3GPP SA4 has defined a header extension for "Coordination of Video Orientation" purpose (may be of interest for CLUE btw, but that's a separate story). The length of the extension is 1 byte.

For more information, see section 7.4.5 of 3GPP TS 24.114 :)

http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-c10.zip

Regards,

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

Biggest Fake Conference in Computer Science

2013-04-27T17:39:56

Biggest Fake Conference in Computer Science


We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 


We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See 
http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the 
conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of
http://sites.google.com/site/dumpconf for comments from well-known researchers 
about WORLDCOMP. 


The status of your WORLDCOMP papers can be changed from scientific
to other (i.e., junk or non-technical) at any time. Better not to have a paper than 
having it in WORLDCOMP and spoil the resume and peace of mind forever!


Our study revealed that WORLDCOMP is a money making business, 
using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing 
out a small chunk of that money (around 20 dollars per paper published 
in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) 
who publicizes WORLDCOMP and also defends it at various forums, using 
fake/anonymous names. The puppet uses fake names and defames other conferences
to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to 
threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). 
That is, the puppet does all his best to get a maximum number of papers published 
at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. 


Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has 
refused to provide the venue for WORLDCOMP’13 because of the fears of their image 
being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 
is taking place at a different resort. WORLDCOMP will not be held after 2013. 


The draft paper submission deadline is over but still there are no committee 
members, no reviewers, and there is no conference Chairman. The only contact 
details available on WORLDCOMP’s website is just an email address! 

Let us make a direct request to Prof. Hamid arabnia: publish all reviews for 
all the papers (after blocking identifiable details) since 2000 conference. Reveal 
the names and affiliations of all the reviewers (for each year) and how many 
papers each reviewer had reviewed on average. We also request him to look at 
the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 


Sorry for posting to multiple lists. Spreading the word is the only way to stop 
this bogus conference. Please forward this message to other mailing lists and people. 


We are shocked with Prof. Hamid Arabnia and his puppet’s activities 
http://worldcomp-fake-bogus.blogspot.com   Search Google using the 
keyword worldcomp fake for additional links.

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

2013-06 Meeting (H.248.TLS): DTLS vs TLS?

Schwarz, Albrecht (Albrecht — 2013-04-16T09:29:01

Ref.: H.248.TLS "Living list related to DTLS and DTLS-SRTP"

FYI, we did further evaluate H.248-controlled DTLS security sesssions, coming to the preliminary conclusion that there are not any significant differences between TLS and DTLS control, FROM MGC perspective ("a result, which is also not really surprising due to the tight alignment of DTLS with TLS"). 

We are therefore still in favour of option #2 (see H.248.TLS, Appendix IV.3), - due to the additional DTLS-SRTP topic.
The separate H.248.DTLS Rec would then mainly provide the following information:
a) applicability statements of H.248 TLS packages as well for DTLS
b) DTLS-SRTP 
c) MG bearer plane differences of DTLS to TLS

Did anyone else already study the DTLS subject too?

Albrecht

2013-06 Meeting: New wildcard proposal "~"

Schwarz, Albrecht (Albrecht — 2013-04-15T15:21:29

Dear All!
We'd like to early point out to one proposal for coming meeting, concerning the discussion of a new (SDP limited) H.248 wildcard method.
The draft contributions are uploaded to the Exchange directory:

http://ifa.itu.int/t/2013/sg16/exchange/wp1/q03/2013-06%20Meeting/Pre-meetingDiscussions/ 
ifa.itu.int - /t/2013/sg16/exchange/wp1/q03/2013-06 Meeting/Pre-meetingDiscussions/

[To Parent Directory]

 4/15/2013  5:12 PM        37066 AVD-4370_H.248.39_ExtendedSDPWildcarding_Ed02.docx
 4/15/2013  5:12 PM        33002 AVD-4371_H.248.39_fingerprint_Ed02.docx

AVD-4370 motivates and defines the wildcard.
AVD-4171 provides a first example use case.

We've identified so far at least two application areas:

a) NAT-T
e.g., a=ssrc:~ cname:~

b) TLS and DTLS basec Transport security:
e.g., a=fingerprint:~ ~

Early feedback would be appreciated,
Albrecht


__________________________________________________
Dr. Albrecht Schwarz
Alcatel-Lucent
Albrecht.Schwarz< at >alcatel-lucent.com

Re: H.248 Mode property vs. signals/events

Christian Groves — 2013-03-28T01:19:24

Hello Mark,

If there's no signal and the streammode is RecvOnly/Inactive then I 
agree no packets should be sent.

Regards, Christian

On 27/03/2013 8:31 PM, Mark Overton wrote:

Re: H.248 Mode property vs. signals/events

Mark Overton — 2013-03-27T09:31:33

Christian, Albrecht,

I've been thinking about this some more and have a question about the implementation of stream mode for RTP terminations in particular.

We've established so far that signals/events are unaffected by Mode: in my original example, if the Mode is RecvOnly and an external Signal is requested (e.g. a tone), it should be played; so we're sending RTP packets containing the tone waveform.

So what about RecvOnly/Inactive RTP terminations where there's no Signal requested? Should I be sending RTP packets (assuming I've a remote descriptor) or not? (And if I should, what do they contain?) Per my original trail, I'd assumed no packets should be sent...

Thanks,

Mark

-----Original Message-----
From: megaco-bounces< at >ietf.org [mailto:megaco-bounces< at >ietf.org] On Behalf Of Christian Groves
Sent: 13 March 2013 10:14
To: Deepak Bissa
Cc: megaco< at >ietf.org
Subject: Re: [Megaco] H.248 Mode property vs. signals/events

Hello Deepak,

The spec says "Signals are unaffected by mode". This text has been there since 1999. I decided to have a look through the mail archives to see if it had been discussed previously. It had, in the context of TDM termination.
("Re: LocalControl Descriptor" 25/04/2000)[Attached].
"        1) Since the MG2 TDM termination mode is inactive, does a ct 
signal get send to CO?
      The answer should be yes since "Signals and Events are not affected by mode.".

The MGC is the master, so if it sets the mode to "Inactive" and it doesn't want a tone or announcement played out of the MG it shouldn't send the signal.

Regards, Christian

On 7/03/2013 5:00 PM, Deepak Bissa wrote:

Re: H.248 Mode property vs. signals/events

Christian Groves — 2013-03-13T10:14:27

Hello Deepak,

The spec says "Signals are unaffected by mode". This text has been there 
since 1999. I decided to have a look through the mail archives to see if 
it had been discussed previously. It had, in the context of TDM termination.
("Re: LocalControl Descriptor" 25/04/2000)[Attached].
"        1) Since the MG2 TDM termination mode is inactive, does a ct 
signal get send to CO?
      The answer should be yes since "Signals and Events are not 
affected by mode.".

The MGC is the master, so if it sets the mode to "Inactive" and it 
doesn't want a tone or announcement played out of the MG it shouldn't 
send the signal.

Regards, Christian

On 7/03/2013 5:00 PM, Deepak Bissa wrote:

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

Re: Usage of silence suppression in Local ConnectionOptions

Christian Groves — 2013-03-07T06:18:55

Hello Sumant,

This is a list for Megaco/H.248 not MGCP.

Regards, Christian

On 7/03/2013 4:55 PM, Sumant Gupta wrote:

Re: H.248 Mode property vs. signals/events

Deepak Bissa — 2013-03-07T06:00:59

Hello Christian,

The signal is played via media stream in this case and is dependent on local/remote descriptor.
The stream mode should decide the flow of media stream in my view. The rules on media stream should apply here even if a signal is played via media stream.
What if the stream mode is set as Inactive? Will the signal will still be played?


Regards,
Deepak Bissa


-----Original Message-----
From: megaco-bounces< at >ietf.org [mailto:megaco-bounces< at >ietf.org] On Behalf Of Christian Groves
Sent: Thursday, March 07, 2013 11:12 AM
To: megaco< at >ietf.org
Subject: Re: [Megaco] H.248 Mode property vs. signals/events

Hello Mark,

The main sentence here is from 7.1.7 "signals and events are not affected by the mode property". 6.1.1 just contrasts the behaviour of stream mode from the topology descriptor.

Even if Streammode = recv is set, if a signal is applied on a Termination/Stream in the outgoing direction it will be sent (the tone will get played). Of course if you haven't set up media in the local/remote descriptor then nothing will get sent.

Regards, Christian

On 5/03/2013 10:00 PM, Mark Overton wrote:

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




===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================

Usage of silence suppression in Local Connection Options

Sumant Gupta — 2013-03-07T05:55:51

Hi,

Silence suppresion can be turned "on" via the "s:on" parameter in
Local connection options specified by Call Agent in MGCP.
Example :

CRCX 1006 aaln/1< at >rx.com MGCP 1.0 NCS 1.0
C: 0
L: p:20, a:PCMU, s:on, sc-rtp:60/50, sc-rtcp:80/70
M: recvonly
X: 0123456789AC
R: hu

1. In 200 Ok of this above request how does client specify that it
supports silence suppresion?

2. During silence period the client would send the comfort noise
packts(CN,paylaod 13) to the remote party.
How does remote party decode the CN(comfort noise) packets?

Looking forward for some help in this issue.

Regards
Sumant

Re: H.248 Mode property vs. signals/events

Christian Groves — 2013-03-07T05:42:16

Hello Mark,

The main sentence here is from 7.1.7 "signals and events are not 
affected by the mode property". 6.1.1 just contrasts the behaviour of 
stream mode from the topology descriptor.

Even if Streammode = recv is set, if a signal is applied on a 
Termination/Stream in the outgoing direction it will be sent (the tone 
will get played). Of course if you haven't set up media in the 
local/remote descriptor then nothing will get sent.

Regards, Christian

On 5/03/2013 10:00 PM, Mark Overton wrote:

Re: H.248 Mode property vs. signals/events

Schwarz, Albrecht (Albrecht — 2013-03-06T08:48:16

Hello Mark,

H.248.1, clause 6: model aspects
H.248.1, clause 7: protocol syntax & semantics

Thus, clause 7.1.7 takes precedence over clause 6.1.1 in my understanding.
If you want to refer topology descriptor, then clause 7.1.18 ("would consider 6.1.1 as a high-level model").

Further: correct MG behaviour arround StreamMode was again frequently discussed in the last two study periods (also in the context of loopback, H.248.85), leading to a number of IG updates.
Looks like that your are not refering the latest text of H.248.1 ("e.g. text about statistics was added, which is missing in your quote").

Latest text of H.248.1: a new release had to be prepared (at 2013-01 meeting) with the end of the 2009-2012 period, which contains all consolidated IG items.
Status: http://www.itu.int/ITU-T/aap/AAPRecDetails.aspx?AAPSeqNo=2714
Thus, not yet published due to ongoing AAP, but you may use the LC text (http://www.itu.int/ITU-T/aap/dologin_aap.asp?id=T0102000A9A0701MSWE.docx&group=16 ).

You may note that also clarifications to events (7.1.9) and signals (7.1.11) were added.

Further like to add following StreamMode model, which we've used in H.248 clarifications. The model should be correct and consistent with H.248.1:

H.248 StreamMode model:
[cid:image004.png< at >01CE1A4F.A82F6520]

I'm not sure whether your physical model ("real resource components like DSP") is consistent with the H.248 model, hm? At least not with above StreamMode model.

Regards,
Albrecht

PS
I've to note that above StreamMode model was not added to H.248.1, rather only pure textual clarifications as IG items ...


From: megaco-bounces< at >ietf.org [mailto:megaco-bounces< at >ietf.org] On Behalf Of Mark Overton
Sent: Dienstag, 5. März 2013 12:01
To: megaco< at >ietf.org
Subject: [Megaco] H.248 Mode property vs. signals/events

Hi,

Can someone please help me understand the interaction between the H.248 Mode property and Signals/Events? We're testing MGC-MG interop, and aren't quite agreeing over a Modify request for a termination with a single stream that

·         sets the Mode to RecvOnly

·         plays an external tone.

The key bits of H.248.1 text up for discussion seem to be:

·         from 7.1.7:

The allowed values for the Mode Property are "SendOnly", "RecvOnly", "SendRecv", "Inactive"
and "LoopBack". "SendOnly", "RecvOnly" and "LoopBack" are with respect to the exterior of the
context, so that, for example, a stream set to mode = "SendOnly" does not pass received media into
the context. When a stream is set to "LoopBack" on a termination, media received (Local
Descriptor) on the termination will be looped back to the sending side (Remote Descriptor) of the
termination and no media is passed between that termination and other terminations in the context.
The looped back media shall be sent according to the Remote Descriptor. The default value for the
Mode Property is "Inactive". Signals and events are not affected by the Mode Property. The
LocalControl Mode Property takes precedence over any mode specified in the Local and Remote
Descriptors.


·         From 6.1.1:

* The Topology Descriptor (who hears/sees whom).
The topology of a context describes the flow of media between the terminations within a
context. In contrast, the Mode Property of a termination ("SendOnly"/"RecvOnly"/...)
describes the flow of the media at the egress/ingress of the media gateway.

So I think we've both interpreted the Mode property differently:

·         One view treats the Mode property as absolute: that is, RecvOnly means absolutely no media is sent out to this termination, SendOnly means any and all received media is absolutely ignored. Setting the mode doesn't affect the Signals and Events that are programmed on a given termination, neither does it affect any subsequent programming - but it can and does affect the result of the programming. So in this case a Mode of RecvOnly combined with an external tone means the tone gets played in the DSP but absolutely no media is sent out to that termination.

Another way to explain our implementation is in this picture:
[MG egress/ingress]<--- flow affected by Mode property --->[termination including DSP for signals/events]<--- flow affected by Topology descriptor --->[context media mixpoint]


·         The other (that expects to see the tone played to the termination) effectively says that the Mode property affects the flow of media between the termination and the context media mixpoint:
[MG egress/ingress]<------>[termination including DSP for signals/events]<--- flow affected by Mode and Topology --->[context media mixpoint]

What's the right answer here? The first view seems to go against the text from 7.1.7, and the second view seems to go against that from 6.1.1.

Please don't hesitate to get back to me if any of this is unclear. Many thanks in advance,

Mark

----
Mark Overton
Project Manager, Carrier Systems Division
Metaswitch Networks

mark.overton< at >metaswitch.com<mailto:mark.overton< at >metaswitch.com>
+44 20 8366 1177
www.metaswitch.com<http://www.metaswitch.com/>

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

H.248 Mode property vs. signals/events

Mark Overton — 2013-03-05T11:00:35

Hi,

Can someone please help me understand the interaction between the H.248 Mode property and Signals/Events? We're testing MGC-MG interop, and aren't quite agreeing over a Modify request for a termination with a single stream that

* sets the Mode to RecvOnly

* plays an external tone.

The key bits of H.248.1 text up for discussion seem to be:

* from 7.1.7:

The allowed values for the Mode Property are "SendOnly", "RecvOnly", "SendRecv", "Inactive"
and "LoopBack". "SendOnly", "RecvOnly" and "LoopBack" are with respect to the exterior of the
context, so that, for example, a stream set to mode = "SendOnly" does not pass received media into
the context. When a stream is set to "LoopBack" on a termination, media received (Local
Descriptor) on the termination will be looped back to the sending side (Remote Descriptor) of the
termination and no media is passed between that termination and other terminations in the context.
The looped back media shall be sent according to the Remote Descriptor. The default value for the
Mode Property is "Inactive". Signals and events are not affected by the Mode Property. The
LocalControl Mode Property takes precedence over any mode specified in the Local and Remote
Descriptors.

* From 6.1.1:

* The Topology Descriptor (who hears/sees whom).
The topology of a context describes the flow of media between the terminations within a
context. In contrast, the Mode Property of a termination ("SendOnly"/"RecvOnly"/...)
describes the flow of the media at the egress/ingress of the media gateway.

So I think we've both interpreted the Mode property differently:

* One view treats the Mode property as absolute: that is, RecvOnly means absolutely no media is sent out to this termination, SendOnly means any and all received media is absolutely ignored. Setting the mode doesn't affect the Signals and Events that are programmed on a given termination, neither does it affect any subsequent programming - but it can and does affect the result of the programming. So in this case a Mode of RecvOnly combined with an external tone means the tone gets played in the DSP but absolutely no media is sent out to that termination.

Another way to explain our implementation is in this picture:
[MG egress/ingress]<--- flow affected by Mode property --->[termination including DSP for signals/events]<--- flow affected by Topology descriptor --->[context media mixpoint]

* The other (that expects to see the tone played to the termination) effectively says that the Mode property affects the flow of media between the termination and the context media mixpoint:
[MG egress/ingress]<------>[termination including DSP for signals/events]<--- flow affected by Mode and Topology --->[context media mixpoint]

What's the right answer here? The first view seems to go against the text from 7.1.7, and the second view seems to go against that from 6.1.1.

Please don't hesitate to get back to me if any of this is unclear. Many thanks in advance,

Mark

----
Mark Overton
Project Manager, Carrier Systems Division
Metaswitch Networks

mark.overton< at >metaswitch.com<mailto:mark.overton< at >metaswitch.com>
+44 20 8366 1177
www.metaswitch.com<http://www.metaswitch.com/>

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

Re: Draft H.248.80; FW: [MMUSIC] RFC 6871 on Session Description Protocol (SDP) Media Capabilities Negotiation

Christian Groves — 2013-03-01T01:05:54

Hello Albrecht,

Yes I saw this was finalised. Good to be able to finalise H.248.80.

I see also draft-westerlund-avtcore-rtp-topologies-update-02.txt has 
been updated to better describe middlebox/translator topologies that 
would be applicable for H.248.RTPTOPO.

Regards, Christian

On 28/02/2013 7:09 PM, Schwarz, Albrecht (Albrecht) wrote:

Draft H.248.80; FW: [MMUSIC] RFC 6871 on Session Description Protocol (SDP) Media Capabilities Negotiation

Schwarz, Albrecht (Albrecht — 2013-02-28T08:09:52

Hello Chrisitian,
guess you noted as well the publication of RFC 6871, which allows to finalize draft H.248.80.
Regards,
Albrecht

-----Original Message-----
From: mmusic-bounces< at >ietf.org [mailto:mmusic-bounces< at >ietf.org] On Behalf Of rfc-editor< at >rfc-editor.org
Sent: Mittwoch, 27. Februar 2013 20:35
To: ietf-announce< at >ietf.org; rfc-dist< at >rfc-editor.org
Cc: mmusic< at >ietf.org; rfc-editor< at >rfc-editor.org
Subject: [MMUSIC] RFC 6871 on Session Description Protocol (SDP) Media Capabilities Negotiation

A new Request for Comments is now available in online RFC libraries.

        RFC 6871

        Title:      Session Description Protocol (SDP) Media 
                    Capabilities Negotiation 
        Author:     R. Gilman, R. Even,
                    F. Andreasen
        Status:     Standards Track
        Stream:     IETF
        Date:       February 2013
        Mailbox:    bob_gilman< at >comcast.net, 
                    roni.even< at >mail01.huawei.com, 
                    fandreas< at >cisco.com
        Pages:      55
        Characters: 124829
        Updates:    RFC5939

        I-D Tag:    draft-ietf-mmusic-sdp-media-capabilities-17.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6871.txt

Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP.
The base framework defines only capabilities for negotiating transport protocols and attributes.  This documents extends the framework by defining media capabilities that can be used to negotiate media types and their associated parameters.

This document updates the IANA Considerations of RFC 5939.

This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.  Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor< at >rfc-editor.org.  Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

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

Re: H.248.TCP & H.248.TLS related contributions

Schwarz, Albrecht (Albrecht — 2013-01-10T08:06:04

fyi, we've prepared an overview on the structure and relations between the submitted contributions:

ftp://ifa.itu.int/t/2009/sg16/exchange/wp2/q03/Structure_of_Contributions_H.248.TCP_and_H.248.TLS_Ed01.pdf

Primary scope at this meeting is to fix the package design baselines for TCP and TLS.
The evaluation and discussion of principles, general concepts and control methods is subject of the "1) ..." indicated contributions.

-Albrecht


From: megaco-bounces< at >ietf.org [mailto:megaco-bounces< at >ietf.org] On Behalf Of Schwarz, Albrecht (Albrecht)
Sent: Donnerstag, 13. Dezember 2012 11:13
To: megaco< at >ietf.org
Subject: [Megaco] H.248.TCP & H.248.TLS related contributions

fyi, we've already uploaded a couple of TCP and TLS related contributions,
see http://www.itu.int/md/T13-SG16-130114-C/en

The high level order is C-2, 3, 4, 43 and the overviews C-13 (TCP) and C-14 (TLS).

__________________________________________________
Dr. Albrecht Schwarz
Alcatel-Lucent
Albrecht.Schwarz< at >alcatel-lucent.com


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

Re: Creation new TID in MGC

Behar Aldana, Ronald (Ronald — 2012-12-26T22:27:44

You should send a servicechange an after the reply a modify enabling events and tones over the line, unles you are using profiles to handle this.

Regards

RB - Sent from my iPhone

El 12/26/2012, a las 17:50, "ISIK, NECAT (NECAT)" <necat.isik< at >alcatel-lucent.com<mailto:necat.isik< at >alcatel-lucent.com>> escribió:

Hi all,
When MG has some terminations in out of service state, which are not registered in MGC, MG is sending “service change” message to MGC for each TID’s as seen;

MEGACO/1 [10.10.10.10] Transaction=31582{Context=-{ServiceChange=P25{Services{Method=Restart,Reason="900 Service Restored",20121217T08144897}}}}

Because of not created termination ID’s MGC returns error message, like the one below;

!/1 [100.100.100.100]:2944 P=31582{C=-{SC=P25{ER=430{"Unknown TrmID"}}}}

It is clear. I wonder that;

What message must be sent from MGC to MG just after creating new termination at MGC?
Must it be “service change” message to put TID in service state, or
“modify” message to connect TID to null context as seen below;

!/1 [100.100.100.100]:2944 T=456731602{C=-{MF=P25{E=2600571907{al/*},SG{}}}}

If the service change message is true, what type of mesage format will be sent?

Best Regards,
M. NECAT ISIK

_______________________________________________
Megaco mailing list
Megaco< at >ietf.org<mailto: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

Creation new TID in MGC

ISIK, NECAT (NECAT — 2012-12-26T21:50:21

Hi all,
When MG has some terminations in out of service state, which are not registered in MGC, MG is sending "service change" message to MGC for each TID's as seen;

MEGACO/1 [10.10.10.10] Transaction=31582{Context=-{ServiceChange=P25{Services{Method=Restart,Reason="900 Service Restored",20121217T08144897}}}}

Because of not created termination ID's MGC returns error message, like the one below;

!/1 [100.100.100.100]:2944 P=31582{C=-{SC=P25{ER=430{"Unknown TrmID"}}}}

It is clear. I wonder that;

What message must be sent from MGC to MG just after creating new termination at MGC?
Must it be "service change" message to put TID in service state, or
"modify" message to connect TID to null context as seen below;

!/1 [100.100.100.100]:2944 T=456731602{C=-{MF=P25{E=2600571907{al/*},SG{}}}}

If the service change message is true, what type of mesage format will be sent?

Best Regards,
M. NECAT ISIK

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

H.248.TCP & H.248.TLS related contributions

Schwarz, Albrecht (Albrecht — 2012-12-13T10:13:06

fyi, we've already uploaded a couple of TCP and TLS related contributions,
see http://www.itu.int/md/T13-SG16-130114-C/en

The high level order is C-2, 3, 4, 43 and the overviews C-13 (TCP) and C-14 (TLS).

__________________________________________________
Dr. Albrecht Schwarz
Alcatel-Lucent
Albrecht.Schwarz< at >alcatel-lucent.com


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

Re: Megaco/Mgcp Digitmap

Schwarz, Albrecht (Albrecht — 2012-10-11T07:37:07

List megaco< at >ietf.org<mailto:megaco< at >ietf.org> is for H.248/MEGACO, but not for MGCP.
I'm not aware of any email exploder for MGCP, guess you got to google ...

From: megaco-bounces< at >ietf.org [mailto:megaco-bounces< at >ietf.org] On Behalf Of Abhijit Dutta
Sent: Donnerstag, 11. Oktober 2012 04:26
To: megaco< at >ietf.org
Subject: [Megaco] Megaco/Mgcp Digitmap

Hi,

Sorry for using the forum for the following help, however since its urgent and am strapped for time, I thought of posting it.

1.       Need to implement and integrate MGCP digitmap - is there any open source available for it which can be used.

2.       Is there any other references apart from RFC, form where I can get more details.

~Thanx
Abhijit

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

Megaco/Mgcp Digitmap

Abhijit Dutta — 2012-10-11T02:25:36

Hi,

Sorry for using the forum for the following help, however since its urgent and am strapped for time, I thought of posting it.


1.       Need to implement and integrate MGCP digitmap - is there any open source available for it which can be used.

2.       Is there any other references apart from RFC, form where I can get more details.

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