Subject: RE: [Megaco] Fax call Flow for discussion and comments required

From: "Miao, Kai" <[email-masked]>
Date: Mon, 8 Oct 2001 11:30:15 -0400

Anwar,
 
I have the following questions regarding your FaxFlow example:
 
1) Is the Faxtone either CNG or CED? Or it goes by CED only?
 
2) If Redundancy has to be considered, do we need to use RED in your
example?
 
3) Modify is used to change from RTP to UDPTL. How is the TDM termination
(for exampe, EC, TG, etc.) modified? Done under the hood?
 
4) What about teardown? Could you include that also in your example?
 
Kai Miao
Intel  

-----Original Message-----
From: Zahid Anwar [mailto:[email-masked]]
Sent: Monday, October 08, 2001 3:19 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Megaco] Fax call Flow for discussion and comments required

In reply to the message posted asking about fax callflow. I propose the
following callflow. But there are a few confusions for example exchange of
SDP formats, sequence of messages and about the fax package id which is not
specified in the RFC. Comments on the following callflow is requested from
all. Any help would be greatly appreciated.

Messages Exchanged between MGC and Gatways in order to establish Fax call
between GW1 and GW2. It is assumed that both gatways are registered, codecs
have been exchanged and a normal call has been established and both
terminations are in on-hook state at this point. 

The caller termination at MG1 detects a fax tone and notifies the MGC. 

MG1 to MGC 

MEGACO/1 [125.125.125.111]:55555 
Transaction = 50005 { 
Context = 1 { 
Notify = Phy/1 {ObservedEvents =1234 { 
19990729T22020002:faxpkg/faxtone}}}} 

The MGC sends a notify reply. 

MGC to MG1 

MEGACO/1 [123.123.123.4]:55555 
Reply = 50005 { 
Context = 1 {Notify = Phy/1}} 

MGC sends a modify to the caller sending it the fax codec in the local of
the the media descriptor. 

MGC to MG1: 
MEGACO/1 [123.123.123.4]:55555 
Transaction = 50006{ 
Context = 1{Modify = Eph/1{Media{ 
Stream = 1{ 
Local{ 
v=0 
c=IN IP4 0.0.0.0 
m=audio 3456 RTP! /AVP 0 
a=ptime:30 
}}}}}} 

MG1 sends a reply filling the attributes of its particular fax codecs in the
local descriptor 

MG1 to MGC: 
MEGACO/1 [124.124.124.222]:55555 
Reply = 50006 { 
Context = 1 { 
Modify= Eph/1{Media { 
Stream = 1 { 
Local { 
v=0 
o=faxgw1 2890846 2890846 IN IP4 ift.here.com 
c=IN IP4 125.125.125.111 
m=image 15002 udptl t38 
a=T38FaxVersion:0 
a=T38maxBitRate:14400 
a=T38FaxFillBitRemoval:0 
a=T38FaxMaxBuffer:72 
}}}}}} 

MGC sends a modify signal to GW2 to ask it to play fax tone 

MGC to MG2 
MEGACO/1 [123.123.123.4]:55555 
Transaction = 50007 { 
Context = 1{ 
Modify = phy/2 { 
Signals {faxpkg/faxtone}}}} 

MG2 sends a modify reply 

MG2 to MGC 

MEGACO/1 [123.123.123.4]:55555 
Reply = 50007 { 
Context = 1 {Modify = Phy/2}} 

Now the MGC asks MG2 for its codes filling the codes of the caller in the
remote 

MGC to M! G2: 
MEGACO/1 [123.123.123.4]:55555 
Transaction = 50008{ 
Co ntext = 1{ 
Modify = Eph/1{Media{Stream = 1 { 
Local{ 
v=0 
c=IN IP4 0.0.0.0 
m=audio 3456 RTP/AVP 0 
a=ptime:30 
}Remote{ 
v=0 
o=faxgw1 2890846 2890846 IN IP4 ift.here.com 
c=IN IP4 125.125.125.111 
m=image 15002 udptl t38 
a=T38FaxVersion:0 
a=T38maxBitRate:14400 
a=T38FaxFillBitRemoval:0 
a=T38FaxMaxBuffer:72 
}}}}}} 

MG2 sends a reply 

MG2 to MGC: 
MEGACO/1 [124.124.124.222]:55555 
Reply = 50008 { 
Context = 1 { 
Modify= Eph/2{Media { 
Stream = 1 {Local { 
v=0 
o=faxgw1 2890846 2890846 IN IP4 ift.here.com 
c=IN IP4 125.125.125.111 
m=image 15002 udptl t38 
a=T38FaxVersion:0 
a=T38maxBitRate:14400 
a=T38FaxFillBitRemoval:0 
a=T38FaxMaxBuffer:72 
}}}}}} 

MGC sends the codes of MG2 to MG1 

MGC to MG1: 
MEGACO/1 [124.124.124.222]:55555 
Transaction = 50009 { 
Context = 1 { 
Modify= Eph/1{Media { 
Stream = 1 { 
Remote 
{ 
v=0 
o! =faxgw1 2890846 2890846 IN IP4 ift.here.com 
c=IN IP4 125.125.125.111 
m=image 15002 udptl t38 
a=T38FaxVersion:0 
a=T38maxBitRate:14400 
a=T38FaxFillBitRemoval:0 
a=T38FaxMaxBuffer:72 

}}}}}} 

MG1 replies to MGC 

MEGACO/1 [124.124.124.222]:55555 
Reply = 50009 { 
Context = 1 { Modify = Eph/2}} 

Regards

Zahid Anwar.

-- 

_______________________________________________
Sign-up for your own FREE Personalized E-mail at
<http://www.mail.com/?sr=signup> Mail.com

Have you downloaded the latest calling software from Net2Phone?
<http://www.net2phone.com/cgi-bin/adforward.cgi?p_key=NH211JK&url=http://com
mcenter.net2phone.com/> Click here to get it now! 

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

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

---

From: James Rafferty <[email-masked]>
Date: Thu, 11 Oct 2001 13:08:37 -0400

Terry,  

Thanks for pointing out the existence of Annex E of T.38.    

Glenn Parsons and I wrote it while working in parallel on H.248 
Annex F as you noted.   It was also reviewed and accepted by
both the ITU fax community in SG8 (now SG16) and the H.248
question within SG16 in the ITU.  

Anwar, please review the Annex E of T.38 and see if you
have any comments on it.  There should be no need to 
create a totally different set of Megaco call flows for fax, unless
they are illustrating different cases.   

James Rafferty

At 11:14 AM 10/9/2001 -0400, Terry L Anderson wrote:
T.38 Annex E (in T.38 Amendment 3, 11/2000) H.248 Call Establishment
Procedures gives detailed call flows including flow diagrams and
sample H.248 messages, use of H.248 Annex F packages for tone detection and
fax state signaling, use of other H.248 packages, etc.  My
problem with it is that the messages have some syntax errors which I
reported to the editor.

The fact that it is not mentioned in in RFC 3015 or recommendation H.248
should not be an issue.  H.248 packages can be developed and
standardized by any standards body and this T.38 annex was written by some
of the some folks that co-authored H.248 Annex F so there has
been a cooperation between the H.248 and the T.38 folks from the beginning
on this.  There could be other definitions of how to interwork
H.248 and T.38 but certainly T.38's own standard will be considered the
normative standard by most.  I think we should get it fixed rather
than try to ignore it.

---

From: "Zahid Anwar" <[email-masked]>
Date: Mon, 15 Oct 2001 14:16:19 +0800

Hello

Thankyou very much for referring me to the document T.38 Amendment 3 (11/2000). It certainly clears up a lot of confusions regarding the fax callflow.

Regards,

Zahid Anwar

Design Engineer,

CET.

-----Original Message-----
From: Terry L Anderson
Date: Tue, 09 Oct 2001 11:14:33 -0400
To: Zahid Anwar
Subject: Re: [Megaco] Fax call Flow for discussion and comments required

> T.38 Annex E (in T.38 Amendment 3, 11/2000) H.248 Call Establishment Procedures gives detailed call flows including flow diagrams and
> sample H.248 messages, use of H.248 Annex F packages for tone detection and fax state signaling, use of other H.248 packages, etc. My
> problem with it is that the messages have some syntax errors which I reported to the editor.
>
> The fact that it is not mentioned in in RFC 3015 or recommendation H.248 should not be an issue. H.248 packages can be developed and
> standardized by any standards body and this T.38 annex was written by some of the some folks that co-authored H.248 Annex F so there has
> been a cooperation between the H.248 and t!
he T.38 folks from the beginning on this. There could be other definitions of how to interwork
> H.248 and T.38 but certainly T.38's own standard will be considered the normative standard by most. I think we should get it fixed rather
> than try to ignore it.
>
> Zahid Anwar wrote:
>
> > Thankyou.
> > But the T.38 does not give details of call flows and does not indicate the fax packages for CNG and nither is it mentioned in rfc3015.
> >
> > Regards
> > Zahid Anwar
> > Design Engineer
> > CET
> > From: Terry L Anderson
> > Date: Mon, 08 Oct 2001 11:33:54 -0400
> > To: Zahid Anwar
> > Subject: Re: [Megaco] Fax call Flow for discussion and comments required
> >
> > > Annexes to T.38 already specify callflows for H.248 (and H.323, SIP,!

> > > etc) in a fair amount of detail including details
on fax tone
> > > detection. I believe that there are some problems with the flow and
> > > have reported these to the editor, but since they are part of T.38 they
> > > have a normative status. It would be more productive to work on getting
> > > any problems in these fixed than to ignore them and begin a parallel
> > > effort.
> > >
> > > Zahid Anwar wrote:
> > >
> > > > In reply to the message posted asking about fax callflow. I propose
> > > > the following callflow. But there are a few confusions for example
> > > > exchange of SDP formats, sequence of messages and about the fax
> > > > package id which is not specified in the RFC. Comments on the
> > > > following callflow is requested from all. Any help would be greatly
> > > > appreciated.
> > > >
>!
; > > > Messages Exchanged between MGC and Gatways in order to establish Fax
> > > > call between GW1 and GW2. It is assumed that both gatways are
> > > > registered, codecs have been exchanged and a normal call has been
> > > > established and both terminations are in on-hook state at this point.
> > > >
!
> > > > MGC sends a modify to the caller sending it the fax codec in the local
> > > > of the the media descriptor.
> > > >
> > > > MGC to MG1:
> > > > MG1 sends a reply filling the attributes of its particular fax codecs
> > > > in the local descriptor
> > > >
> > > > MG1 to MGC:
> > > >!
> > > > M!
odify = phy/2 {
> > > > Signals {faxpkg/faxtone}}}} > > > >
> > > > MG2 sends a modify reply
> > > >
> > > > MG2 to MGC
> > > >
> > > > Now the MGC asks MG2 for its codes filling the codes of the caller in
> > > > the remote
> > > >
> > > > MGC to M! G2:
> > > > o=faxgw1!
2890846 2890846 IN IP4 ift.here.com
> > > > a=T38m!
axBitRate:14400
> > > > a=T38FaxFillBitRemoval:0
&
gt; > > > a=T38FaxMaxBuffer:72
> > > > MG1 replies to!
MGC
> > > > Sign-up for your own FREE Personalized E-mail at Mail.com
> > > >
> > > > Have you downloaded the latest calling software from Net2Phone? Click
> > > > here to get it now!
> > > ------------------------------------------------------------
&g!
t; > > Terry L Anderson mailto:[email-masked]
Tel:908.582.7013 Fax:908.582.6729
> > > Lucent Technologies/INS/Voice Over IP Access Networks
> > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> > > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
> > >
> > >
> >
> > --
> >
> > Sign-up for your own FREE Personalized E-mail at Mail.com
> > http://www.mail.com/?sr=signup
> >
> > Have you downloaded the latest calling software from Net2Phone? Click here to get it now!
> > http://www.net2phone.com/cgi-bin/adforward.cgi?p_key=NH211JK&url=http://commcenter.net2phone.com/
>
> --
>
> ------------------------------------------------------------
> Terry L Anderson mailto:[email-masked]
> Tel:908.582.7013 Fax:908.582.6729
> Lucent Technologies/INS/Voice!
Over IP Access Networks
> Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
>
>

--

Sign-up for your own FREE Personalized E-mail at Mail.com

Have you downloaded the latest calling software from Net2Phone? Click here to get it now!

---

From: "Miao, Kai" <[email-masked]>
Date: Mon, 22 Oct 2001 10:40:59 -0400

Hi, Gunnar:

The following are what I have at this moment:

The conflicts appear mainly in the type of megaco descriptors each property
falls into. For example, the call flow shows T38FaxUdpEC in Local (or
Remote) descriptor whereas H248F's T38capability belongs to Termination
State (Then what would happen if one side desires to use FEC, but the other
side whats to use Redundancy?). 

faxstate in the call flow is in LocalControl, but belongs also to
TerminationState in H248F. 

The T38UDPTL (in IPFaxTransport, another TerminationState property) is in
fact prosposed through "m=image #port udptl t38" in Local or Remote, not
even used as such. Should types like these be consistent to those in MIME?
They apper to be more like media types than TerminationState. 

For T38Version, how can two fax machines communicate with each other through
two T38 gateways with different versions of T38? How can we define
T38Version so that different VERSIONs of the protocol can be communicated.
The way it is defined in H248F does not allow this.     

Regards,
Kai

-----Original Message-----
From: Gunnar Hellstrom [mailto:[email-masked]]
Sent: Sunday, October 21, 2001 2:01 PM
To: Miao, Kai; 'James Rafferty'; 'Terry L Anderson'; 'Zahid Anwar'
Cc: [email-masked]; Glenn Parsons (E-mail)
Subject: RE: [Megaco] Fax call Flow for discussion and comments required

Kai,
I have made a very brief analysis of the correspondence between the
mentioned T.38  properties and H.248 Annex F properties.

Most of them are straightforward.
It would of course be very fruitful to draw more call flows to demonstrate
how T.38 maps to H.248 Annex F. If lacking or conflicting functionality is
then found, proposals for resolution can be made resulting in additions or
modifications in any of the involved documents.

Here is the result of my brief analysis

     T.38 property                  H.248 Annex F property ( mainly in
package ipfax )
----------------------------------------------------------------------------
-------------
T38FaxVersion					T38Version

T38MaxBitRate					Transmission Speed    (also
related to transmission speed
property in the fax package )

T38FaxFillBitRemoval				T.38 Capabilities

T38FaxTranscodingMMR				T.38 Capabilities

T38FaxTranscodingJGIB				T.38 Capabilities

T38FaxRatemanagement				Comes implicitly from
ipfaxtransport

T38FaxMaxBuffer					T38MaximumBuffersize

T38FaxMaxDatagram
T38MaximumDatagramsize

T38FaxUdpEC						T.38 Capabilities

T38FaxProtocol(IFP transport method)	IPFaxTransport

----------------------------
So, the property mapping looks OK to me.
Can you please explain what call flow conflict you have found, and if you
have any proposal for solution of the conflict.

Best regards

Gunnar Hellström ( editor of H.248 Annex F )
--------------------------
Gunnar Hellström
Omnitor AB
Tel +46 708 204 288
E-mail [email-masked]
WWW:     http://www.omnitor.se

> From: Miao, Kai [mailto:[email-masked]]
> Sent: Tuesday, October 16, 2001 5:07 PM
> To: 'James Rafferty'; 'Terry L Anderson'; 'Zahid Anwar'
> Cc: [email-masked]'; Gunnar Hellstrom (E-mail); Glenn Parsons (E-mail)
> Subject: RE: [Megaco] Fax call Flow for discussion and comments required
>
>
> The following properties have been defined in T38 annexes. But as far as
> Megaco is concerned, I have noticed a few conflicts as which
> descriptor each
> of these properties belong to. For example, the call flow in T38
> Annex E is
> direct conflict to H248 Annex F.
>
> Can any one shine some light as to what it going on in this regard?
>
> Thanks,
> Kai Miao
>
> =========================================================================
>
>
> T38FaxVersion
>
> T38MaxBitRate
>
> T38FaxFillBitRemoval
>
> T38FaxTranscodingMMR
>
> T38FaxTranscodingJGIB
>
> T38FaxRatemanagement
>
> T38FaxMaxBuffer
>
> T38FaxMaxDatagram
>
> T38FaxUdpEC
>
> T38FaxProtocol(IFP transport method)
>
>

---

From: James Rafferty <[email-masked]>
Date: Mon, 22 Oct 2001 10:37:07 -0400

Gunnar,  

Thanks for your analysis.  I agree with almost all of it.  

However, there is one T.38 property which does not appear to have a clear
Annex F counterpart.    

T38FaxRateManagement basically indicates whether local fax training is used
(Data Rate Management Method 1 in T.38) or the passthrough approach (Method
2 in T.38).   As you say, it can be derived from ipfaxtransport, according
to the rules of sections 8.1 and 8.2 of T.38, 
since Data Rate Management method 1 is specified for use with TCP and Data
Rate Management method 2 is specified only for use with UDP.   However, I
believe it would probably be cleaner to have 
a specific Annex F property in the IP Fax package which maps directly to
T38FaxRatemanagement.  

I checked T.38 Annex D and note that there is already an equivalent property
defined in the SDP
of Annex D, so there is a way to indicate such a property in SDP.  

So, if we wanted to complete the mapping of T.38 properties by adding a
T38FaxRateManagement
property to the IP Fax package in Annex F, this would be a good idea from my
standpoint.   I'm
pretty sure our original intent was to fully map the 
applicable T.38 properties in this package.   

Glenn, does this make sense from your standpoint?    

By the way, there is a Megaco call flow of a voice/fax session in Appendix E
of T.38 which 
Glenn and I developed at the same time as Annex F of H.248 and was designed
to be fully consistent
with both T.38 Annex E and H.248 Annex F.   I noticed upon my review of it
that the
example  uses the T38FaxRateManagement property, which reinforces my sense
that if the T38FaxRateManagement property was left out of the original Annex
F, this
was an accidental omission.    

So, Gunnar, if it is feasible to add this property into the draft text for
corrections
to the Annex F in your contribution, I think this would be a good idea.  If
you think
we need to do this via contribution, that would be OK too.  My colleague
Dave Duehren, 
who is the T.38 editor will be attending portions of the Dublin meeting, so
perhaps
you could hook up with him to help sort this out.   In the meantime, I can
be reached via
email.  

Kiao, I hope this answers your questions.  In my re-review of the T.38 Annex
E text, I can 
see that it might be confusing.   It essentially says that if you are using
text encoding, 
(i.e. SDP), you may use the property values designed for use with SDP in
T.38 Annex D.   
On the other hand, if you are using the binary encoding to implement T.38
Annex E,  
the normative reference is from T.38 Annex E to the IP Fax package of H.248
Annex 
F.  The intent among the fax experts of SG8 (now SG16) was to have a way of
negotiating T.38 
capabilities or properties no matter which standard IP Call Control or
device control protocol is 
to be used.  From what I can see, the addition of the T38FaxRateManagement
property to 
Annex F of H.248 would complete the mapping of the negotiation parameters
for T.38 which 
have been specified to date for use with H.323 (see H.245 V6 or later), SIP
(T.38 Annex D) and Megaco/H.248
(see T.38 Annex E and its normative references, T.38 Annex D and Annex F of
H.248).   

James

> T38MaxBitRate					Transmission 
> Speed    (also related to transmission speed
> T38FaxRatemanagement				Comes 
> implicitly from ipfaxtransport
> 
> T38FaxMaxBuffer					
> T38MaximumBuffersize
> 
> T38FaxMaxDatagram					
> T38MaximumDatagramsize
> 
> T38FaxUdpEC						T.38 
> Capabilities
>