Christian Groves | 6 Oct 02:22 2008

Re: terminationId syntax and semantics

Hello Raphael,

I think you will be disappointed on your quest to understand the hidden 
deeper meaning behind this. Termination IDs were meant to be a hierarchy 
of names. You can see the examples in Annex A (binary encoding) on the 
possibilities. I think the disconnect came that when defining the text 
encoding, people were thinking more of a URI style format for 
termination IDs.  The URI syntax was translated to Megaco ABNF and the 
problem with "NAME" having to be an ALPHA was introduced. This also had 
a side effect that text package names have to start with a letter which 
caused some problem for 3GPP.

As for the usage of pathDomainName I haven't seen any proposed usage for 
this in any standards document.
For the usage of "*"s maybe a MGC wants to audit a certain heirarchy level?

I think the best advice is to try to work in with terminationID schemes 
already defined in profiles. At least Tispan and 3GPP share a reasonably 
common scheme.

Regards, Christian

PS: Soon George W will be in retirement and will be able to devote his 
entire time to this issue....

Raphael Tryster wrote:
> I think it is a safe bet that George W. Bush has spent almost his entire
> presidency not understanding the rules by which which Megaco termination
> identifiers are constructed.  I have been aware of the existence of
> Megaco for about the same period, and don't understand them either.
(Continue reading)

Ramesh Babu Kuppili | 10 Oct 06:57 2008

Codec Negotiation Question

ØN–	)
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Deepak Bissa | 10 Oct 07:36 2008

Re: 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."
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Priyanka Yadav | 10 Oct 08:22 2008
Picon

Re: Codec Negotiation Question

 
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: 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}}}}}
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Navdeep Bhatia | 11 Oct 09:58 2008

Re: 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."
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Rajiv Ginotra | 12 Oct 10:00 2008
Picon

Re: Megaco Digest, Vol 54, Issue 2

Hi All,

Just to add what Priyanka said, Even when u send the modify with local
descriptor containing codec other than in remote descriptor then you send
the "Codec Negotiation Failure" as the intersection between the New local
and the existing remote is empty.

Regards
Rajiv

-----Original Message-----
From: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of
megaco-request <at> ietf.org
Sent: Friday, October 10, 2008 11:52 AM
To: megaco <at> ietf.org
Subject: Megaco Digest, Vol 54, Issue 2

Send Megaco mailing list submissions to
	megaco <at> ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/megaco
or, via email, send a message with subject or body 'help' to
	megaco-request <at> ietf.org

You can reach the person managing the list at
	megaco-owner <at> ietf.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Megaco digest..."

Today's Topics:

   1. Codec Negotiation Question (Ramesh Babu Kuppili)
   2. Re: Codec Negotiation Question (Deepak Bissa)
   3. Re: Codec Negotiation Question (Priyanka Yadav)

----------------------------------------------------------------------

Message: 1
Date: Fri, 10 Oct 2008 10:27:09 +0530
From: Ramesh Babu Kuppili <RKuppili <at> zhone.com>
Subject: [Megaco] Codec Negotiation Question
To: megaco <at> ietf.org
Cc: Murugesh Govindaraju <MGovindaraju <at> zhone.com>
Message-ID: <0K8I006VLB3DTE80 <at> priority.oak.zhone.com>
Content-Type: text/plain; charset="us-ascii"

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}}}}}
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://www.ietf.org/mailman/private/megaco/attachments/20081010/809e0e3b/a
ttachment-0001.htm>

------------------------------

Message: 2
Date: Fri, 10 Oct 2008 11:06:57 +0530
From: Deepak Bissa <deepak.bissa <at> aricent.com>
Subject: Re: [Megaco] Codec Negotiation Question
To: Ramesh Babu Kuppili <RKuppili <at> zhone.com>, "megaco <at> ietf.org"
	<megaco <at> ietf.org>
Cc: Murugesh Govindaraju <MGovindaraju <at> zhone.com>
Message-ID:
	
<31F873353B13F2419C80FD0833E118951E86C1DD1F <at> GUREXMB01.ASIAN.AD.ARICENT.COM>
	
Content-Type: text/plain; charset="us-ascii"

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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://www.ietf.org/mailman/private/megaco/attachments/20081010/8d424049/a
ttachment-0001.htm>

------------------------------

Message: 3
Date: Fri, 10 Oct 2008 11:52:56 +0530
From: "Priyanka Yadav" <priyadav <at> cisco.com>
Subject: Re: [Megaco] Codec Negotiation Question
To: "'Ramesh Babu Kuppili'" <RKuppili <at> zhone.com>, <megaco <at> ietf.org>
Cc: 'Murugesh Govindaraju' <MGovindaraju <at> zhone.com>
Message-ID: <005901c92aa0$a48603f0$83a44e0a <at> priyadavwxp01>
Content-Type: text/plain; charset="us-ascii"

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://www.ietf.org/mailman/private/megaco/attachments/20081010/3262ecb0/a
ttachment.htm>

------------------------------

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco

End of Megaco Digest, Vol 54, Issue 2
*************************************
Schwarz Albrecht | 13 Oct 13:44 2008
Picon

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: 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."
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Schwarz Albrecht | 13 Oct 14:33 2008
Picon

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: 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."
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Murugesh Govindaraju | 15 Oct 13:31 2008

Choose payload value for rtpmap

Hi,
Can the choose payload value($) be specified as the value for rtpmap 
attribute in SDP?
For example:
a=rtpmap:$ telephone-event/8000

If it is valid then what should be the response for this message?
Specific reference to any RFC is really appreciated.

Thanks and Regards,
Murugesh.G
Schwarz Albrecht | 17 Oct 10:58 2008
Picon

H.248 SDP parameter identification and wildcarding; RE: Choose payload value for rtpmap

Murugesh,

"H.248 SDP parameter identification and wildcarding" is defined in
H.248.39.
Wildcarding in SDP "a=" lines is summarized in Table 6-15/H.248.39 -
Attributes.
You may find also "a=rtpmap:?".

Albrecht

> -----Original Message-----
> From: megaco-bounces <at> ietf.org 
> [mailto:megaco-bounces <at> ietf.org] On Behalf Of Murugesh Govindaraju
> Sent: Mittwoch, 15. Oktober 2008 13:32
> To: megaco <at> ietf.org
> Subject: [Megaco] Choose payload value for rtpmap
> 
> Hi,
> Can the choose payload value($) be specified as the value for 
> rtpmap attribute in SDP?
> For example:
> a=rtpmap:$ telephone-event/8000
> 
> If it is valid then what should be the response for this message?
> Specific reference to any RFC is really appreciated.
> 
> Thanks and Regards,
> Murugesh.G
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
> 

Gmane