Subject: [Megaco] forcing T.38 MGC transitioning method

From: "Raphael Tryster" <[email-masked]>
Date: Tue, 2 Jan 2007 16:12:28 +0200

In the examples in T.38 Appendix III, the MGC tries to find out if the
MG supports autonomous transitioning or not, and behaves accordingly.
But there is potentially a third case that is not illustrated - where
the MG supports autonomous transitioning, but the MGC wants to control
the transition itself anyway.  How does the MGC indicate this
unambiguously?  Is it by the absence of an "m=image" line in the remote
descriptor?

If so, how does the MGC cause this line to be absent?  Clearly, it can
remove it if it received it from the other MG.  Can it also cause the
other MG not to supply it by setting ReservedGroup=Off?  When an MG sees
a local descriptor with both audio and image components, and
ReservedGroup=Off, how does it decide whether to return only audio or
only image?
 
Raphael Tryster
**********************************************************************************************
This e-mail contains confidential, privileged or proprietary information to VocalTec Communications.
If you received this messege by mistake, please inform us and then delete the original and all copies.
*** eSafe scanned this email for viruses, vandals, and malicious content. ***
**********************************************************************************************

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 02 Jan 2007 09:28:38 -0500

Can you really have a local descriptor with both audio and image 
components? I would expect that this would require multiple m= lines, 
and hence apply to multiple streams.

---

From: "Raphael Tryster" <[email-masked]>
Date: Tue, 2 Jan 2007 16:37:28 +0200

Multiple m= lines, but same stream, as in this example from T.38.  This
is standard Megaco, isn't it?

MEGACO/1 [123.123.123.4]:55555
Transaction = 11 {
  Context = $ {
    Add = DS0/1/1 {
      Events = 1 {al/on, ctyp/dtone }
        },  ; SCN termination prepared to listen for tones
    Add = $ {
      Media { 
        Stream = 1 { 
          LocalControl { Mode=ReceiveOnly, ReservedGroup=On,
ReservedValue=On},
          Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 18 0
v=0
c=IN IP4 $
m=image $ udptl t38
           }; IP termination for audio     
         }                  
       }
     }    
  }
}  

Raphael Tryster

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]] 
Sent: Tuesday, January 02, 2007 4:29 PM
To: Raphael Tryster
Cc: [email-masked]
Subject: Re: [Megaco] forcing T.38 MGC transitioning method

> ReservedGroup=Off, how does it decide whether to return only audio or
************************************************************************
**********************
> *** eSafe scanned this email for viruses, vandals, and malicious
content. ***
************************************************************************
**********************

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 02 Jan 2007 10:59:26 -0500

Yes. I wasn't thinking about alternative session descriptions.

Back to your original question: how about setting the port to zero in 
the unwanted session?

---

From: "Raphael Tryster" <[email-masked]>
Date: Tue, 2 Jan 2007 18:40:33 +0200

Tom,

Are you referring to this?

"Also, because MG1 does not support the T.38 Autonomous Transitioning
method for transitioning between VoIP and FoIP, it omits the image media
descriptor line all together (alternatively, it could have set the T.38
port to 0)".

Do you mean that MG1 could send a local descriptor with m=image 0 udptl
t38 to the MGC, and the MGC could pass that line on to MG2 in the remote
descriptor?  Presumably, MG2 should then behave the same as if the
m=image line were absent. But both these methods seem to suffer from the
disadvantage that the MGC does not learn whether MG2 supports T.38
Autonomous Transitioning.  That's why I suggested that the MGC might
want to send both m=audio and m=image with ReserveGroup=Off.  But on
second thoughts, that wouldn't yield the desired information either.
 
My interest in this is from the MG side.  That is, I assume there is
some other formulation that the MGC would use to discover if the second
MG supports T.38 Autonomous Transitioning, and I would like to know what
it is so I can handle it properly.
 
Raphael Tryster

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 02 Jan 2007 13:57:45 -0500

You are doomed, I think. Because the MGC is in control and can 
manipulate the signalling, MG1 has no idea what MG2 signalled. And what 
I meant in my previous message was that the MGC would set the port to 0 
in its signalling while sending both the audio and the image sessions. 
At a later time it could activate the transition by sending a CHOOSE for 
the port.

---

From: [email-masked]
Date: Wed, 3 Jan 2007 11:59:05 +0100

Like to go back to the initial problem:
   How may be BOTH T.38 TRANSITIONING METHODs supported at an H.248 Control
   Association?
   (-> means that the MG and/or MGC is able to support both modes)

The method negotiation/determination could be done on
a) LD/RD level with correspondent SDP settings, or
b) as a behavioural specification within a profile (i.e. dedicated
procedures).

The possible solution for (a) is discussed so far in this thread.
I'd like to remind that (b) was also already investigated within the
attempt of an aligned 3GPP/TISPAN TGW profile (= H.248 Mn profile(s)).

   [Background: prefered method for TISPAN is autonomous transitioning, and
   prefered method for 3GPP is MGC-strict controlled. Both methods could be
   merged by using autonomous as default method plus an additional
   notification of the MGC, allowing the MGC to "overwrite" the default
   method. You may find more details in TISPAN docs on WI03047 between
   TISPAN#8 and #9 meetings. E.g. 08TD241 "H.248 Trunking GW Profile -
   Voiceband Data (VBD) Service", or ACWG3-H248 TD08 "H.248 Trunking GW
   Profile - Progress on § 5.17.2.3 VBD Procedures"]

- Albrecht

                      "Tom-PT Taylor"                                                                                                   
                      <[email-masked]         To:      Raphael Tryster <[email-masked]>                                  
                      om>                      cc:      [email-masked]                                                                 
                                               Subject: Re: [Megaco] forcing T.38 MGC transitioning method                              
                      02.01.2007 19:57

---

From: "John Wainwright" <[email-masked]>
Date: Fri, 5 Jan 2007 15:11:24 -0600

Is there any activity going on in the open-source world regarding a
Megaco MG or MGC protocol stack that anyone is aware of ( apart from
erlang ).

Any recommendations as a good starting point for the development of a
Megaco MG ?

Thanks
John

---

From: "Arturo Martin De Nicolas \(AC/EDD\)" <[email-masked]>
Date: Mon, 8 Jan 2007 16:45:01 +0100

Hello,

I have a question concerning a multiplexing termination, i.e. a
termination with a mux descriptor. In the H.248.1 model (see 6.2) the
multiplexing termination is connected on one side to the bearer
termination or terminations representing the multiplexed stream, and on
the other side to the bearer termination or terminations representing
the demultiplexed (separated) streams, e.g. audio and video.

My question is: in addition to these connections, may the multiplexing
termination be also connected to some monitoring terminations, i.e. via
one-way connections?

Example:

Context C1 with audio stream S1, video stream S2, and multiplexed stream
S0.

Multiplexed stream:  T1 -> Stream S0  

Multiplexing termination: Tmux (muxdescriptor=H.223{T1}) -> Stream S0,
S1 and S2

Demultiplexed streams:  T3  ->  Stream S1 and S2

Is it possible to add T1b to the context with the following topology?

Topology {(*, T1b, Isolate), (Tmux, T1b, oneway)}, Add (T1, Stream S0)

As I see it, this could in principle work. However, as the multiplexing
termination is special, I wonder if this resulting context is legal. 

Regards,
Arturo

---

From: Christian Groves <[email-masked]>
Date: Wed, 10 Jan 2007 12:03:27 +1100

Hello All,

Perhaps H.248.2 provides some methods for the determination of who does 
the transitioning ?
e.g. clause 8.1.7    MG Responsible for Call Discrimination Signalling

Regards, Christian

[email-masked] wrote:
>>> Multiple m= lines, but same stream, as in this example from T.38.
>>>       
>> This
>>     
>>>> In the examples in T.38 Appendix III, the MGC tries to find out if
>>>>         
>> the
>>     
>>>> the MG supports autonomous transitioning, but the MGC wants to
>>>>         
>> control
>>     
>>>> unambiguously?  Is it by the absence of an "m=image" line in the
>>>>         
>>> remote
>>>       
>>>> descriptor?
>>>>
>>>> If so, how does the MGC cause this line to be absent?  Clearly, it
>>>>         
>> can
>>     
>>>> other MG not to supply it by setting ReservedGroup=Off?  When an MG
>>>>         
>>> sees
>>>       
>>>> This e-mail contains confidential, privileged or proprietary
>>>>         
>>> information to VocalTec Communications.
>>>       
>>>> If you received this messege by mistake, please inform us and then
>>>>         
>>> delete the original and all copies.
>>>       
>>>> *** eSafe scanned this email for viruses, vandals, and malicious
>>>>         
>>> content. ***
>>>
>>>       
>>> This e-mail contains confidential, privileged or proprietary
>>>       
>> information to VocalTec Communications.
>>     
>>> If you received this messege by mistake, please inform us and then
>>>       
>> delete the original and all copies.
>>     
>>> *** eSafe scanned this email for viruses, vandals, and malicious
>>>       
>> content. ***
>> This e-mail contains confidential, privileged or proprietary information
>>     
> to VocalTec Communications.
>   
>> If you received this messege by mistake, please inform us and then delete
>>     
> the original and all copies.
>   
>> *** eSafe scanned this email for viruses, vandals, and malicious content.
>>     
> ***
>

---

From: <[email-masked]>
Date: Wed, 10 Jan 2007 16:09:48 -0600

Hi All,

I have a question with regards to service change from MG to MGC. If a
termination T1 is in context C1 (non-NULL) and MG sends ServiceChange(Out Of
Service) for this termination T1 to MGC then does the MG remove the
termination from context C1 or is it the responsibility of MGC to remove the
termination from C1. Here is the call flow:

MGC			MG

	Add(T1) -->
	Add_Resp(C1) <--
	...
	ServiceChange(T1) <--

At this point does MG remove T1 from C1? Or it relies upon MGC to remove T1
from C1?

Regards,
Ashok Khuntia
Mavenir Systems

---

From: Veeraraghavan Selvam <[email-masked]>
Date: Wed, 10 Jan 2007 16:29:42 -0600 (CST)

Ashok,

I believe it is the responsibility of the MGC to remove the termination T1
from context C1.

Please refer section 7.2.8 of rfc3525.

Best Regards,
Selva.

  Alcatel USA, Inc.                  Internet:<sveeragh>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

---

From: [email-masked]
Date: Wed, 17 Jan 2007 15:08:29 +0100

Sorry for late reply.

Yes, an Event for H.248.2 was considered ("think it was H.248.2

>    Profile - Progress on § 5.17.2.3 VBD Procedures"]

Briefly:
1. MG enabled for autonomous mode per default
2. MG may start in voice mode
2. Successfully detected VBD and/or fax event leads to
   2.1 autonomous state transitioning in the MG AND
   2.2 notification of the MGC (based on H.248.2)
3. Possible MGC actions:
   3.1 None ("MG mode remains unmodified")
   3.2 Mode modification ("strict control scenario ...")
...

Like to note that above scenario is NOT yet documented in any profile
specification.

- Albrecht

                      Christian Groves                                                                                                   
                      <Christian.Groves@nt         To:      [email-masked]                                           
                      eczone.com>                  cc:      [email-masked], [email-masked]                 
                                                   Subject: Re: [Megaco] forcing T.38 MGC transitioning method                           
                      10.01.2007 02:03                                                                                                   

Hello All,

Regards, Christian

>> If you received this messege by mistake, please inform us and then
delete
>> *** eSafe scanned this email for viruses, vandals, and malicious
content.