Re: Codec Negotiation Question

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 protected] [mailto:[email protected]]
On Behalf Of Schwarz Albrecht
	Sent: Montag, 13. Oktober 2008 13:44
	To: Navdeep Bhatia; Deepak Bissa; Ramesh Babu Kuppili;
[email protected]
	Cc: Murugesh Govindaraju
	Subject: Re: [Megaco] 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