Subject: RE: [Megaco] codec incompatibility

From: "Donak, John" <[email-masked]>
Date: Mon, 9 Aug 2004 17:19:46 -0400

Is the specific behaviour for codec negotiation specified anywhere within
MEGACO? (as in RFC3435 for MGCP).

 I could not find it.

	John

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Wednesday, March 03, 2004 5:29 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Megaco] codec incompatibility

Hello Tom,

You are allowed to have a different codecs in the local and remote
descriptor 
for a particular stream. It is typical for a bi-directional connections that
the 
same codec is used in either direction but H.248 does not mandate this.

If you are concerned that MG1 may support different codecs to MG2 then it is
up 
to negotiation to determine whether a call can take place. In BICC networks
this 
codec negotiation is done at the MGC level. In other network types the MG1
will 
provide a list of codecs that are sent to the MG2 to choose from.

Regards, Christian

[email-masked] wrote:

> Hello,
> 
> What should happen in case MGC passes to a MG2 a localDescriptor with a 
> different codec then in the remoteDescriptor.
> I.e MG1 only supports codec 8 and MG2 only supports codec 0.
> Which entity is responsible to detect that conversation will not be 
> possible
> 
> Must the MG generate 510 as described in section 7.1.8 of RFC3015
> 
> *  If ReserveGroup is False and ReserveValue is false, then the MG
>      SHOULD apply the following rules to resolve Local and Remote to a
>      single alternative each:
> 
>   *  The MG chooses the first alternative in Local for which it is able
>      to support at least one alternative in Remote.
> 
>   *  If the MG is unable to support at least one Local and one Remote
>      alternative, it returns Error 510 (Insufficient Resources).
> 
> or should the MGC not send such commands
> 
> Example:
> 
> 14. The MGC will now associate A5555 with a new Context on MG2, and
>   establish an RTP Stream (i.e, A5556 will be assigned), SendReceive
>   connection through to the originating user, User 1. The MGC also sets
>   ring on A5555.
> 
>   MGC to MG2:
>   MEGACO/1 [123.123.123.4]:55555
>   Transaction = 50003 {
>       Context = $ {
>          Add = A5555  { Media {
>               Stream = 1 {
>                    LocalControl {Mode = SendReceive} }},
>                Events=1234{al/of},
>               Signals {al/ri}
>               },
>          Add  = $ {Media {
>               Stream = 1 {
>                    LocalControl {
>                       Mode = SendReceive,
>                       nt/jit=40 ; in ms
>                    },
>                    Local {
>   v=0
>   c=IN IP4 $
>   m=audio $ RTP/AVP 0
>   a=ptime:30
>                    },
>                    Remote {
>   v=0
>   c=IN IP4 124.124.124.222
>   m=audio 2222 RTP/AVP 8
>   a=ptime:30
>                    } ;                }
>             }
>         }
>      }
>   }
> 
> 
> 
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
> 

This communication is confidential and intended solely for the addressee(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If
you believe this message has been sent to you in error, please notify the
sender by replying to this transmission and delete the message without
disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption,
interruption, unauthorized amendment, tampering and viruses, and we only
send and receive e-mails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any
consequences thereof.

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

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

---

From: Christian Groves <[email-masked]>
Date: Wed, 11 Aug 2004 11:11:32 +1000

Hello Donak,

There is no specific behaviour for "codec" negotiation in H.248.1. The general 
rules of h.248.1 sect 7.1.7 and 7.1.8 applies for codecs as well.

Regards, Christian