Subject: [Megaco] Codec Negotiation Question

From: Ramesh Babu Kuppili <[email-masked]>
Date: Fri, 10 Oct 2008 10:27:09 +0530

Gurus,
 
I have a question about Codec Negotiation in Megaco.
 
Lets says the switch initially sends us local and remote codec list.  We take a intersection of the both local and remote and respond to the request.
 
Then at a later stage lets says the switch sends another modify with only local codec list.  And this time the local codec does not intersect with the remote codec list that was received previously.
 
My question is, "How should the gateway behave to the the codec list in the modify?".
 
1. Should it assume the the remote will also support all the codecs in the list of Modify and respond to the modify with all supported codecs.
2. Should it send a "codec negotiation failure" as response for Modify since the codec list in the modify does not intersect with the remote codec list previously sent.
 
- ramesh
 
~~~~~~~~~~~~~~~~~~Example messages~~~~~~~~~~~~~~~~~~~
Request with both local and remote:
    MEGACO/1    [172.16.43.151]    Transaction = 58738{Context = 3{Modify = Eag26/ep2{Media{Stream = 1{LocalControl{Mode = SendReceive , ReservedValue = off , ReservedGroup = off , tdmc/ec = on} , Local{v=0    c=IN IP4 $    m=audio $ RTP/AVP 18    a=ptime:40    v=0    c=IN IP4 $    m=audio $ RTP/AVP 101    a=rtpmap:101 telephone-event/8000    a=ptime:40    } , Remote{v=0    c=IN IP4 172.16.43.155    m=audio 6024 RTP/AVP 18    a=ptime:40    v=0    c=IN IP4 172.16.43.155    m=audio 6024 RTP/AVP 101    a=rtpmap:101 telephone-event/8000    a=ptime:40    }}}}}}
Request with local only:
    MEGACO/1    [172.16.43.151]    Transaction = 58741{Context = 3{Modify = AG26{Media{Stream = 1{LocalControl{Mode = SendReceive , tdmc/ec = off}} , TerminationState{Buffer = off , fax/faxstate = Negotiating}} , Events = 16777230{fax/faxconnchange , al/on , al/fl}} , Modif    c=IN IP4 $    m=audio $ RTP/AVP 8    a=ptime:20    }} , TerminationState{Buffer = off , ipfax/faxstate = Negotiating , ctyp/calltyp = FAX}}}}}
_______________________________________________
Megaco mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/megaco

---

From: Deepak Bissa <[email-masked]>
Date: Fri, 10 Oct 2008 11:06:57 +0530

As per section 7.1.1 of H.248.1 (v3)
"If a required descriptor other than the Audit Descriptor is unspecified (i.e. entirely absent) from a command, the previous values set in that descriptor for that termination, if any, are retained."

Thus, in case when only local codec is sent by MGC and remote is absent then previous remote descriptor will be retained.
In such scenario, if the local codec does not intersect with remote codec and MG does not asymmetric codec then it should reply with an error "515 Unsupported Media Type".
If asymmetric codec is supported by MG then codec negotiation will be successful.

With regards,
Deepak Bissa
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ramesh Babu Kuppili
Sent: Friday, October 10, 2008 10:27 AM
To: [email-masked]
Cc: Murugesh Govindaraju
Subject: [Megaco] Codec Negotiation Question

Gurus,

- ramesh

~~~~~~~~~~~~~~~~~~Example messages~~~~~~~~~~~~~~~~~~~
Request with both local and remote:
    MEGACO/1
    [172.16.43.151]
    Transaction = 58738{Context = 3{Modify = Eag26/ep2{Media{Stream = 1{LocalControl{Mode = SendReceive , ReservedValue = off , ReservedGroup = off , tdmc/ec = on} , Local{v=0
    c=IN IP4 $
    m=audio $ RTP/AVP 18
    a=ptime:40
    v=0
    c=IN IP4 $
    m=audio $ RTP/AVP 101
    a=rtpmap:101 telephone-event/8000
    a=ptime:40
    } , Remote{v=0
    c=IN IP4 172.16.43.155
    m=audio 6024 RTP/AVP 18
    a=ptime:40
    v=0
    c=IN IP4 172.16.43.155
    m=audio 6024 RTP/AVP 101
    a=rtpmap:101 telephone-event/8000
    a=ptime:40
    }}}}}}
Request with local only:
    MEGACO/1
    [172.16.43.151]
    Transaction = 58741{Context = 3{Modify = AG26{Media{Stream = 1{LocalControl{Mode = SendReceive , tdmc/ec = off}} , TerminationState{Buffer = off , fax/faxstate = Negotiating}} , Events = 16777230{fax/faxconnchange , al/on , al/fl}} , Modif
    c=IN IP4 $
    m=audio $ RTP/AVP 8
    a=ptime:20
    }} , TerminationState{Buffer = off , ipfax/faxstate = Negotiating , ctyp/calltyp = FAX}}}}}

________________________________
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
Megaco mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/megaco

---

From: "Priyanka Yadav" <[email-masked]>
Date: Fri, 10 Oct 2008 11:52:56 +0530

Hi Ramesh
I think you should send a "codec negotiation faliure" as response of Modify
since the codec list in modify doesnot intersect with the remote codec list
previously sent.
If you go by approach one and in your example case One gateway will move
from codec 18 to 8.
But the other gateway will not have any information about this codec change.
So, I think second approach is better.
 
Thanks
Priyanka

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ramesh Babu Kuppili
Sent: Friday, October 10, 2008 10:27 AM
To: [email-masked]
Cc: Murugesh Govindaraju
Subject: [Megaco] Codec Negotiation Question

Gurus,

Lets says the switch initially sends us local and remote codec list.  We
take a intersection of the both local and remote and respond to the request.
 
Then at a later stage lets says the switch sends another modify with only
local codec list.  And this time the local codec does not intersect with the
remote codec list that was received previously.
 
My question is, "How should the gateway behave to the the codec list in the
modify?".
 
1. Should it assume the the remote will also support all the codecs in the
list of Modify and respond to the modify with all supported codecs.
2. Should it send a "codec negotiation failure" as response for Modify since
the codec list in the modify does not intersect with the remote codec list
previously sent.
 
- ramesh
 
~~~~~~~~~~~~~~~~~~Example messages~~~~~~~~~~~~~~~~~~~
Request with both local and remote:
    MEGACO/1
    [172.16.43.151]
    Transaction = 58738{Context = 3{Modify = Eag26/ep2{Media{Stream =
1{LocalControl{Mode = SendReceive , ReservedValue = off , ReservedGroup =
off , tdmc/ec = on} , Local{v=0
    c=IN IP4 $
    m=audio $ RTP/AVP 18
    a=ptime:40
    v=0
    c=IN IP4 $
    m=audio $ RTP/AVP 101
    a=rtpmap:101 telephone-event/8000
    a=ptime:40
    } , Remote{v=0
    c=IN IP4 172.16.43.155
    m=audio 6024 RTP/AVP 18
    a=ptime:40
    v=0
    c=IN IP4 172.16.43.155
    m=audio 6024 RTP/AVP 101
    a=rtpmap:101 telephone-event/8000
    a=ptime:40
    }}}}}}

Request with local only:
    MEGACO/1
    [172.16.43.151]
    Transaction = 58741{Context = 3{Modify = AG26{Media{Stream =
1{LocalControl{Mode = SendReceive , tdmc/ec = off}} ,
TerminationState{Buffer = off , fax/faxstate = Negotiating}} , Events =
16777230{fax/faxconnchange , al/on , al/fl}} , Modif
    c=IN IP4 $
    m=audio $ RTP/AVP 8
    a=ptime:20
    }} , TerminationState{Buffer = off , ipfax/faxstate = Negotiating ,
ctyp/calltyp = FAX}}}}}

---

From: Navdeep Bhatia <[email-masked]>
Date: Sat, 11 Oct 2008 13:28:55 +0530

Hi,

In my opinion, MG should never perform intersection when local codec is forced upon it. It should reject call only
a) when it receives the remote descriptor codec which it does not support or
b) if a local codec is forced upon it that it does not support.

Consider the following example:
1) MG(a) and MG(b) establishes an audio call through MG(c), for example, in a border gateway scenario. And then fax regoniation takes place. Consider the following flow (taking just one MGC for simplicity, let MG (c) be the contentious MG we are talking about):
                                                                      MGC
                                              MG(a) -----------> MG(c) -------------> MG(b)

Suppose a call has already been established between MG(a) and MG(b) via MG(c) using normal MEGACO procedures. Now if any of the two, MG(a) or MG(b) wants to renegotiate, say, to fax. In this scenario, MGC shall force fax codec, say t38, on MG(c) termination towards MG(a) without sending the remote media descriptor (considering fax renegotiation initiated by MG(b)). Now in this case, MG (c) should send a successful response if it supports t38 codec.

Please note that if codec intersection is done between local and remote in the above mentioned example then we would never be able to renegotiate to codecs other than negotiated at the call start-up.

Thanks.

Regards,
Navdeep

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Deepak Bissa
Sent: Friday, October 10, 2008 11:06 AM
To: Ramesh Babu Kuppili; [email-masked]
Cc: Murugesh Govindaraju
Subject: Re: [Megaco] Codec Negotiation Question

As per section 7.1.1 of H.248.1 (v3)
“If a required descriptor other than the Audit Descriptor is unspecified (i.e. entirely absent) from a command, the previous values set in that descriptor for that termination, if any, are retained.”

Thus, in case when only local codec is sent by MGC and remote is absent then previous remote descriptor will be retained.
In such scenario, if the local codec does not intersect with remote codec and MG does not asymmetric codec then it should reply with an error “515 Unsupported Media Type”.
If asymmetric codec is supported by MG then codec negotiation will be successful.

With regards,
Deepak Bissa

Gurus,

- ramesh

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Mon, 13 Oct 2008 13:44:15 +0200

There is an "end-to-end" (bearer) capability (codec) negotiation
process.
There are two options in real networks:
 
1) the MGC could entirely do the codec negotiation itself (because codec
negotiation is firstly a matter of call/session control protocols),
without involvement of the MG, under the condition that the MGC knows
the supported codec types by the MG ("this condition is fullfilled by
many real MGC products, when provisioned by a "list of supported
codecs"; the list will change in case of MG capability changes);
 
2) the MG is involved (besides the MGC) in the "E2E codec negotiation".
 
Next aspect is related to LDs/RDs: let's consider a context with two
terminations T1 and T2. The MG has to compare four combinations:
- LD(T1) with RD (T1)
- LD(T2) with RD (T2)
- RD(T1) with RD (T2)
- LD(T1) with LD (T2)
Right? I think yes, because there could be different media formats for
each traffic direction, and there could be thus different combinations
of (direction-dependent) transcoding and transcoding free operations.
This is the asymmetrical case. Many folks have just the symmetrical case
in mind ("which is of course dominating in real session scenarios").
 
The problem space may be reduced for Phy-to-Eph contexts, because Phy
terminations do use just a single media format ("I know that there are a
few exceptions like e.g. a G.725 terminal"). The codec negotiation is
fairly straightforward for such context types (like for RGW, AGW, TGW).
Typically approach (2) is used.
=> approach (2) is the starting point because "media-awareness" is
typically required for 100% of the calls
 
Navdeeps example is related to an Eph-to-Eph context in case of MG(c).
This could be a BGW as indicated. The situation is now exactly the
opposite. "Media-agnostic" mode should be the starting point due to the
high possibility of successfull E2E codec negotiations (between a and
b).
=> approach (1) should be the starting point for MG(c)
=> requires the indication media-agnostic in LD/RD via "-" in SDP "m="
line, see e.g. H.248 profiles for BGWs (like ETSI 183 018).
If the MGC will choose approach (2) for MG(c), then the MG would always
start to create the context from "media aware" perspective (which is of
course also feasible in theory, but very inefficient in practise).
 
Albrecht

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Navdeep Bhatia
	Sent: Samstag, 11. Oktober 2008 09:59
	To: Deepak Bissa; Ramesh Babu Kuppili; [email-masked]
	Cc: Murugesh Govindaraju
	Subject: Re: [Megaco] Codec Negotiation Question

	Hi,
	 
	In my opinion, MG should never perform intersection when local
codec is forced upon it. It should reject call only 
	a) when it receives the remote descriptor codec which it does
not support or 
	b) if a local codec is forced upon it that it does not support.
	 
	Consider the following example:
	1) MG(a) and MG(b) establishes an audio call through MG(c), for
example, in a border gateway scenario. And then fax regoniation takes
place. Consider the following flow (taking just one MGC for simplicity,
let MG (c) be the contentious MG we are talking about):
	
MGC
	                                              MG(a) ----------->
MG(c) -------------> MG(b)
	 
	Suppose a call has already been established between MG(a) and
MG(b) via MG(c) using normal MEGACO procedures. Now if any of the two,
MG(a) or MG(b) wants to renegotiate, say, to fax. In this scenario, MGC
shall force fax codec, say t38, on MG(c) termination towards MG(a)
without sending the remote media descriptor (considering fax
renegotiation initiated by MG(b)). Now in this case, MG (c) should send
a successful response if it supports t38 codec.
	 
	Please note that if codec intersection is done between local and
remote in the above mentioned example then we would never be able to
renegotiate to codecs other than negotiated at the call start-up. 
	 
	Thanks.
	 
	Regards,
	Navdeep

	From: [email-masked] [[email-masked]] On
Behalf Of Deepak Bissa
	Sent: Friday, October 10, 2008 11:06 AM
	To: Ramesh Babu Kuppili; [email-masked]
	Cc: Murugesh Govindaraju
	Subject: Re: [Megaco] Codec Negotiation Question

	"If a required descriptor other than the Audit Descriptor is
unspecified (i.e. entirely absent) from a command, the previous values
set in that descriptor for that termination, if any, are retained."

	Thus, in case when only local codec is sent by MGC and remote is
absent then previous remote descriptor will be retained.

	In such scenario, if the local codec does not intersect with
remote codec and MG does not asymmetric codec then it should reply with
an error "515 Unsupported Media Type".

	If asymmetric codec is supported by MG then codec negotiation
will be successful.

	With regards,

	Deepak Bissa

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ramesh Babu Kuppili
	Sent: Friday, October 10, 2008 10:27 AM
	To: [email-masked]
	Cc: Murugesh Govindaraju
	Subject: [Megaco] Codec Negotiation Question

	Gurus,

	Lets says the switch initially sends us local and remote codec
list.  We take a intersection of the both local and remote and respond
to the request.

	Then at a later stage lets says the switch sends another modify
with only local codec list.  And this time the local codec does not
intersect with the remote codec list that was received previously.

	My question is, "How should the gateway behave to the the codec
list in the modify?".

	1. Should it assume the the remote will also support all the
codecs in the list of Modify and respond to the modify with all
supported codecs.

	2. Should it send a "codec negotiation failure" as response for
Modify since the codec list in the modify does not intersect with the
remote codec list previously sent.

	- ramesh

	    MEGACO/1
	    [172.16.43.151]
	    Transaction = 58738{Context = 3{Modify =
Eag26/ep2{Media{Stream = 1{LocalControl{Mode = SendReceive ,
ReservedValue = off , ReservedGroup = off , tdmc/ec = on} , Local{v=0
	    c=IN IP4 $
	    m=audio $ RTP/AVP 18
	    a=ptime:40
	    v=0
	    c=IN IP4 $
	    m=audio $ RTP/AVP 101
	    a=rtpmap:101 telephone-event/8000
	    a=ptime:40
	    } , Remote{v=0
	    c=IN IP4 172.16.43.155
	    m=audio 6024 RTP/AVP 18
	    a=ptime:40
	    v=0
	    c=IN IP4 172.16.43.155
	    m=audio 6024 RTP/AVP 101
	    a=rtpmap:101 telephone-event/8000
	    a=ptime:40
	    }}}}}}

	Request with local only:

	    MEGACO/1
	    [172.16.43.151]
	    Transaction = 58741{Context = 3{Modify = AG26{Media{Stream =
1{LocalControl{Mode = SendReceive , tdmc/ec = off}} ,
TerminationState{Buffer = off , fax/faxstate = Negotiating}} , Events =
16777230{fax/faxconnchange , al/on , al/fl}} , Modif
	    c=IN IP4 $
	    m=audio $ RTP/AVP 8
	    a=ptime:20
	    }} , TerminationState{Buffer = off , ipfax/faxstate =
Negotiating , ctyp/calltyp = FAX}}}}}

	"DISCLAIMER: This message is proprietary to Aricent and is
intended solely for the use of the individual to whom it is addressed.
It may contain privileged or confidential information and should not be
circulated or used for any purpose other than for what it is intended.
If you have received this message in error,please notify the originator
immediately. If you are not the intended recipient, you are notified
that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. Aricent accepts no
responsibility for loss or damage arising from the use of the
information transmitted by this email including damage from virus."

	"DISCLAIMER: This message is proprietary to Aricent and is
intended solely for the use of the individual to whom it is addressed.
It may contain privileged or confidential information and should not be
circulated or used for any purpose other than for what it is intended.
If you have received this message in error,please notify the originator
immediately. If you are not the intended recipient, you are notified
that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. Aricent accepts no
responsibility for loss or damage arising from the use of the
information transmitted by this email including damage from virus."

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Mon, 13 Oct 2008 14:33:38 +0200

I may add two examples wrt the variety of codec negotiations at the
H.248 interface:
 
A) Media server (e.g. H.248 Mp profiles, 3GPP 29.333)
    = 100% calls relate to "media-aware" contexts in MG
 
B) Border gateway according TISPAN R1 (e.g. H.248 Ia profileV1 (ETSI ES
283 018 v1), H.248 Rw profile V1, ITU-T Q.3303.2)
    = 100% calls relate to "media-agnostic" contexts in MG ("the MGC is
even not allowed to provide any media-type/-format related information
in the H.248 Media Descriptor!")
 
Should be kept in mind when considering codec negotiation aspects.

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Schwarz Albrecht
	Sent: Montag, 13. Oktober 2008 13:44
	To: Navdeep Bhatia; Deepak Bissa; Ramesh Babu Kuppili;
[email-masked]
	Cc: Murugesh Govindaraju
	Subject: Re: [Megaco] Codec Negotiation Question

	1) the MGC could entirely do the codec negotiation itself
(because codec negotiation is firstly a matter of call/session control
protocols), without involvement of the MG, under the condition that the
MGC knows the supported codec types by the MG ("this condition is
fullfilled by many real MGC products, when provisioned by a "list of
supported codecs"; the list will change in case of MG capability
changes);
	 
	2) the MG is involved (besides the MGC) in the "E2E codec
negotiation".
	 
	Next aspect is related to LDs/RDs: let's consider a context with
two terminations T1 and T2. The MG has to compare four combinations:
	
	- LD(T1) with RD (T1)
	- LD(T2) with RD (T2)
	- RD(T1) with RD (T2)
	- LD(T1) with LD (T2)
	Right? I think yes, because there could be different media
formats for each traffic direction, and there could be thus different
combinations of (direction-dependent) transcoding and transcoding free
operations.
	This is the asymmetrical case. Many folks have just the
symmetrical case in mind ("which is of course dominating in real session
scenarios").
	 
	The problem space may be reduced for Phy-to-Eph contexts,
because Phy terminations do use just a single media format ("I know that
there are a few exceptions like e.g. a G.725 terminal"). The codec
negotiation is fairly straightforward for such context types (like for
RGW, AGW, TGW). Typically approach (2) is used.
	=> approach (2) is the starting point because "media-awareness"
is typically required for 100% of the calls
	 
	Navdeeps example is related to an Eph-to-Eph context in case of
MG(c).
	This could be a BGW as indicated. The situation is now exactly
the opposite. "Media-agnostic" mode should be the starting point due to
the high possibility of successfull E2E codec negotiations (between a
and b).
	=> approach (1) should be the starting point for MG(c)
	=> requires the indication media-agnostic in LD/RD via "-" in
SDP "m=" line, see e.g. H.248 profiles for BGWs (like ETSI 183 018).
	If the MGC will choose approach (2) for MG(c), then the MG would
always start to create the context from "media aware" perspective (which
is of course also feasible in theory, but very inefficient in practise).
	 
	Albrecht

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Navdeep Bhatia
		Sent: Samstag, 11. Oktober 2008 09:59
		To: Deepak Bissa; Ramesh Babu Kuppili; [email-masked]
		Cc: Murugesh Govindaraju
		Subject: Re: [Megaco] Codec Negotiation Question

		Hi,
		 
		In my opinion, MG should never perform intersection when
local codec is forced upon it. It should reject call only 
		a) when it receives the remote descriptor codec which it
does not support or 
		b) if a local codec is forced upon it that it does not
support.
		 
		Consider the following example:
		1) MG(a) and MG(b) establishes an audio call through
MG(c), for example, in a border gateway scenario. And then fax
regoniation takes place. Consider the following flow (taking just one
MGC for simplicity, let MG (c) be the contentious MG we are talking
about):
	
MGC
		                                              MG(a)
-----------> MG(c) -------------> MG(b)
		 
		Suppose a call has already been established between
MG(a) and MG(b) via MG(c) using normal MEGACO procedures. Now if any of
the two, MG(a) or MG(b) wants to renegotiate, say, to fax. In this
scenario, MGC shall force fax codec, say t38, on MG(c) termination
towards MG(a) without sending the remote media descriptor (considering
fax renegotiation initiated by MG(b)). Now in this case, MG (c) should
send a successful response if it supports t38 codec.
		 
		Please note that if codec intersection is done between
local and remote in the above mentioned example then we would never be
able to renegotiate to codecs other than negotiated at the call
start-up. 
		 
		Thanks.
		 
		Regards,
		Navdeep

		From: [email-masked] [[email-masked]]
On Behalf Of Deepak Bissa
		Sent: Friday, October 10, 2008 11:06 AM
		To: Ramesh Babu Kuppili; [email-masked]
		Cc: Murugesh Govindaraju
		Subject: Re: [Megaco] Codec Negotiation Question

		"If a required descriptor other than the Audit
Descriptor is unspecified (i.e. entirely absent) from a command, the
previous values set in that descriptor for that termination, if any, are
retained."

		Thus, in case when only local codec is sent by MGC and
remote is absent then previous remote descriptor will be retained.

		In such scenario, if the local codec does not intersect
with remote codec and MG does not asymmetric codec then it should reply
with an error "515 Unsupported Media Type".

		If asymmetric codec is supported by MG then codec
negotiation will be successful.

		With regards,

		Deepak Bissa

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ramesh Babu Kuppili
		Sent: Friday, October 10, 2008 10:27 AM
		To: [email-masked]
		Cc: Murugesh Govindaraju
		Subject: [Megaco] Codec Negotiation Question

		Gurus,

		Lets says the switch initially sends us local and remote
codec list.  We take a intersection of the both local and remote and
respond to the request.

		Then at a later stage lets says the switch sends another
modify with only local codec list.  And this time the local codec does
not intersect with the remote codec list that was received previously.

		My question is, "How should the gateway behave to the
the codec list in the modify?".

		1. Should it assume the the remote will also support all
the codecs in the list of Modify and respond to the modify with all
supported codecs.

		2. Should it send a "codec negotiation failure" as
response for Modify since the codec list in the modify does not
intersect with the remote codec list previously sent.

		- ramesh

		    MEGACO/1
		    [172.16.43.151]

		Request with local only:

		    MEGACO/1
		    [172.16.43.151]
		    Transaction = 58741{Context = 3{Modify =
AG26{Media{Stream = 1{LocalControl{Mode = SendReceive , tdmc/ec = off}}
, TerminationState{Buffer = off , fax/faxstate = Negotiating}} , Events
= 16777230{fax/faxconnchange , al/on , al/fl}} , Modif
		    c=IN IP4 $
		    m=audio $ RTP/AVP 8
		    a=ptime:20
		    }} , TerminationState{Buffer = off , ipfax/faxstate
= Negotiating , ctyp/calltyp = FAX}}}}}

		"DISCLAIMER: This message is proprietary to Aricent and
is intended solely for the use of the individual to whom it is
addressed. It may contain privileged or confidential information and
should not be circulated or used for any purpose other than for what it
is intended. If you have received this message in error,please notify
the originator immediately. If you are not the intended recipient, you
are notified that you are strictly prohibited from using, copying,
altering, or disclosing the contents of this message. Aricent accepts no
responsibility for loss or damage arising from the use of the
information transmitted by this email including damage from virus."

		"DISCLAIMER: This message is proprietary to Aricent and
is intended solely for the use of the individual to whom it is
addressed. It may contain privileged or confidential information and
should not be circulated or used for any purpose other than for what it
is intended. If you have received this message in error,please notify
the originator immediately. If you are not the intended recipient, you
are notified that you are strictly prohibited from using, copying,
altering, or disclosing the contents of this message. Aricent accepts no
responsibility for loss or damage arising from the use of the
information transmitted by this email including damage from virus."