Re: Codec Negotiation Question

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 protected] [mailto:[email protected]]
On Behalf Of Navdeep Bhatia
	Sent: Samstag, 11. Oktober 2008 09:59
	To: Deepak Bissa; Ramesh Babu Kuppili; [email protected]
	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 protected] [[email protected]] On
Behalf Of Deepak Bissa
	Sent: Friday, October 10, 2008 11:06 AM
	To: Ramesh Babu Kuppili; [email protected]
	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

	
________________________________


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

	 

	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}}}}}


________________________________

	"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."

_______________________________________________
Megaco mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/megaco