From: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of Navdeep Bhatia
Sent: Samstag, 11. Oktober 2008 09:59
To: Deepak Bissa; Ramesh Babu Kuppili; megaco <at> ietf.org
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: megaco-bounces <at> ietf.org [megaco-bounces <at> ietf.org] On Behalf Of Deepak Bissa
Sent: Friday, October 10, 2008 11:06 AM
To: Ramesh Babu Kuppili; megaco <at> ietf.org
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: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of Ramesh Babu Kuppili
Sent: Friday, October 10, 2008 10:27 AM
To: megaco <at> ietf.org
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."

From: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of Schwarz Albrecht
Sent: Montag, 13. Oktober 2008 13:44
To: Navdeep Bhatia; Deepak Bissa; Ramesh Babu Kuppili; megaco <at> ietf.org
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: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of Navdeep Bhatia
Sent: Samstag, 11. Oktober 2008 09:59
To: Deepak Bissa; Ramesh Babu Kuppili; megaco <at> ietf.org
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: megaco-bounces <at> ietf.org [megaco-bounces <at> ietf.org] On Behalf Of Deepak Bissa
Sent: Friday, October 10, 2008 11:06 AM
To: Ramesh Babu Kuppili; megaco <at> ietf.org
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: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of Ramesh Babu Kuppili
Sent: Friday, October 10, 2008 10:27 AM
To: megaco <at> ietf.org
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."