From albrecht.schwarz@alcatel-lucent.com Wed Aug 7 03:06:56 2013 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85EFD21F99A1 for ; Wed, 7 Aug 2013 03:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEupDzpFetsq for ; Wed, 7 Aug 2013 03:06:50 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id E27DC21F9928 for ; Wed, 7 Aug 2013 03:06:49 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r77A6eiU015256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Aug 2013 05:06:42 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r77A6dUc009658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Aug 2013 12:06:40 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.135]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 7 Aug 2013 12:06:40 +0200 From: "Schwarz, Albrecht (Albrecht)" To: ext Nevenka Biondic , "megaco@ietf.org" , "3GPP_TSG_CT_WG4@LIST.ETSI.ORG" <3GPP_TSG_CT_WG4@LIST.ETSI.ORG> Thread-Topic: SDP attribute "a=imageattr:": (1) wildcarding [3GPP CT4 "SIS-CT"] Thread-Index: Ac6TVXp2qIGCxrUISuqCB5DmbaRssA== Date: Wed, 7 Aug 2013 10:06:39 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC08A805@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC08A805FR711WXCHMBA03zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: [Megaco] SDP attribute "a=imageattr:": (1) wildcarding [3GPP CT4 "SIS-CT"] X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 10:06:56 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC08A805FR711WXCHMBA03zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nevenka, all, you proposed to continue the technical discussion at next CT4 meeting; like= to suggest to start in parallel the clarification of raised H.248 aspects= . The first topic is related to SDP wildcarding: RFC 6236 allows wildcard usage for multiple attribute parameters. I think we may just focus on the high level SDP format: a=3Dimageattr:PT send attr-list recv attr-list The wildcard "*" (ALL) may be applied principally for multiple attribute el= ements (in red), right? a=3Dimageattr:PT send attr-list recv attr-list e.g., PT: A wild card (*) can be specified for the payload type number to indicate th= at it applies to all payload types in the media description. You mentioned (in the CT4 discussion) wildcard usage at the level of 1) PT 2) recv attr-list as far as I remember, and the PT type wildcard is the difficult one, becaus= e affecting possibly multiple media configurations, right? My initial comments and understanding would be: 1. A "PT level" wildcard would imply multiple (reserved) media configu= rations, i.e., usage of ReserveGroup. 2. A "recv attr-list" level wildcard would enforce the MG to reply the= choosen/supported attribute values 3. Like to suggest you specify the SDP wildcarding of this attribute i= n H.248.39, because a. the wildcard "*" is applicable for SIP signalling, whereas the SDP= mapping to H.248 allows principally also to use additional wildcards (here= e.g., "$" and "-"); and b. possible interactions with ReserveValue/ReserveGroup. 4. Example from 26.114 ("I've copied one below"): 26.116 is not using the "PT level" wildcard at all, because there's j= ust a single video codec (H.264) considered by 26.114, - right? Regards, Albrecht _______ SIP/SDP example (26.114): Table A.4.10a: Example SDP offer for H.264/AVC with image size negotiation SDP offer a=3Dtcap:1 RTP/AVPF m=3Dvideo 49154 RTP/AVP 99 a=3Dpcfg:1 t=3D1 b=3DAS:315 b=3DRS:0 b=3DRR:2500 a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 packetization-mode=3D0; profile-level-id=3D42e00c; \ sprop-parameter-sets=3DJ0LgDJWgUH6Af1A=3D,KM46gA=3D=3D a=3Dimageattr:99 send [x=3D176,y=3D144] [x=3D224,y=3D176] [x=3D272,y=3D224]= [x=3D320,y=3D240] recv [x=3D176,y=3D144] [x=3D224,y=3D176] [x=3D272,y=3D22= 4,q=3D0.6] [x=3D320,y=3D240] a=3Drtcp-fb:* trr-int 5000 a=3Drtcp-fb:* nack a=3Drtcp-fb:* nack pli a=3Drtcp-fb:* ccm fir a=3Drtcp-fb:* ccm tmmbr a=3Dextmap:4 urn:3gpp:video-orientation --_000_786615F3A85DF44AA2A76164A71FE1AC08A805FR711WXCHMBA03zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Nevenka, all,
you proposed to continue the technical discussion at next CT4 meeting;= like to suggest to start in parallel the clarification of  raised H.2= 48 aspects .
 
The first topic is related to SDP wildcarding:
 
RFC 6236 allows wildcard usage for multiple attribute parameters.
I think we may just focus on the high level SDP format:
 
=       a=3Dimageattr:PT send attr-list recv attr-li= st
 
The wildcard “*” (ALL) ma= y be applied principally for multiple attribute elements (in red), right?
 
=       a=3Dimageattr:PT = send attr-list recv attr-lis= t
 
e.g., PT:
= A wild card (*) can be specified for the payload type number to indicate th= at it applies
=       to all payload types in the media descriptio= n.
 
You mentioned (in the CT4 discussion) wildcard usage at the level of
1) PT
2) recv attr-list
as far as I remember, and the PT type wildcard is the difficult one, b= ecause affecting possibly multiple media configurations, right?
 
My initial comments and understanding would be:
  1. A “PT level” wildcard would imply multiple (reserved) media= configurations, i.e., usage of ReserveGroup.
  2. A “recv attr-li= st” level wildcard would enforce the MG to reply the choosen/supporte= d attribute values
  3. Like to suggest you specify the SDP wildcarding = of this attribute in H.248.39, because
  1. the wildcard “*” is applicable for SIP signalling, whereas= the SDP mapping to H.248 allows principally also to use additional wildcar= ds (here e.g., “$” and “-“);
    and
  2. possible interactions with ReserveValue/ReserveGroup.
  1. Example from 26.114 (“I’ve copied one below”):
    26.116 is not using the “PT level” wildcard at all, because the= re’s just a single video codec (H.264) considered by 26.114, - right?=
 
Regards,
Albrecht
_______
SIP/SDP example (26.114):
Table A.4.10a: Example SDP offer for H.264= /AVC with image size negotiation
SDP offer
a= =3Dtcap:1 RTP/AVPF
m=3Dvideo 49154 RTP/AVP 99
a=3Dpcfg:1 t=3D1
b=3DAS:315
b=3DRS:0
b=3DRR:2500
a=3Drtpmap:99 H264/90000
a=3Dfmtp:99 packetization-mode=3D0; profile-level-id=3D42e00c; \
     sprop-parameter-sets=3DJ0LgDJWgUH6Af1A=3D,KM4= 6gA=3D=3D
a=3Dimageattr:99 send [x=3D17= 6,y=3D144] [x=3D224,y=3D176] [x=3D272,y=3D224] [x=3D320,y=3D240] recv [x=3D= 176,y=3D144] [x=3D224,y=3D176] [x=3D272,y=3D224,q=3D0.6] [x=3D320,y=3D240]<= /span>
a=3Drtcp-fb:* trr-int 5000
a=3Drtcp-fb:* nack
a=3Drtcp-fb:* nack pli
a=3Drtcp-fb:* ccm fir
a=3Drtcp-fb:* ccm tmmbr
a=3Dextmap:4 urn:3gpp:video-orientation
 
 
 
 
 
 
 
 
 
 
 
 --_000_786615F3A85DF44AA2A76164A71FE1AC08A805FR711WXCHMBA03zeu_-- From albrecht.schwarz@alcatel-lucent.com Wed Aug 7 03:21:15 2013 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4299F21F9A1D for ; Wed, 7 Aug 2013 03:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YU96QWKUWGn for ; Wed, 7 Aug 2013 03:21:08 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5718111E80FC for ; Wed, 7 Aug 2013 03:21:08 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r77AL3F6023029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Aug 2013 05:21:04 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r77AL2qm020357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Aug 2013 12:21:02 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.135]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 7 Aug 2013 12:21:02 +0200 From: "Schwarz, Albrecht (Albrecht)" To: ext Nevenka Biondic , "megaco@ietf.org" , "3GPP_TSG_CT_WG4@LIST.ETSI.ORG" <3GPP_TSG_CT_WG4@LIST.ETSI.ORG> Thread-Topic: SDP attribute "a=imageattr:": (2) revised SDP O/A [3GPP CT4 "SIS-CT"] Thread-Index: AQHOk1fRBCl818f7RUKWbmGZw/viDw== Date: Wed, 7 Aug 2013 10:21:02 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC08A85C@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <786615F3A85DF44AA2A76164A71FE1AC08A805@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC08A805@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC08A85CFR711WXCHMBA03zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: [Megaco] SDP attribute "a=imageattr:": (2) revised SDP O/A [3GPP CT4 "SIS-CT"] X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 10:21:15 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC08A85CFR711WXCHMBA03zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The 2nd discussion subject was related to revised SDP O/A elements: RFC 6236 explicitly indicates their (=3D RFC 5939 & RFC 6871) usage (see cl= ause 3.2.6/RFC 6236). ... a=3Dmcap:1 video H264/90000 a=3Dacap:1 imageattr:%1% send [x=3D720,y=3D576,sar=3D[0.91,1.0,1.09,1= .45]] ... Also 26.114 indicates (RFC 5939) usage in the example: ... a=3Dtcap:1 The general comment made in the CT4 meeting: the mapping of these SDP elem= ents from SIP to H.248 would need to take the work of H.248.80 into account= (due to the different resource reservation principles at SIP and H.248 int= erfaces). -Albrecht From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of= Schwarz, Albrecht (Albrecht) Sent: Mittwoch, 7. August 2013 12:07 To: ext Nevenka Biondic; megaco@ietf.org; 3GPP_TSG_CT_WG4@LIST.ETSI.ORG Subject: [Megaco] SDP attribute "a=3Dimageattr:": (1) wildcarding [3GPP CT4= "SIS-CT"] Hi Nevenka, all, you proposed to continue the technical discussion at next CT4 meeting; like= to suggest to start in parallel the clarification of raised H.248 aspects= . The first topic is related to SDP wildcarding: RFC 6236 allows wildcard usage for multiple attribute parameters. I think we may just focus on the high level SDP format: a=3Dimageattr:PT send attr-list recv attr-list The wildcard "*" (ALL) may be applied principally for multiple attribute el= ements (in red), right? a=3Dimageattr:PT send attr-list recv attr-list e.g., PT: A wild card (*) can be specified for the payload type number to indicate th= at it applies to all payload types in the media description. You mentioned (in the CT4 discussion) wildcard usage at the level of 1) PT 2) recv attr-list as far as I remember, and the PT type wildcard is the difficult one, becaus= e affecting possibly multiple media configurations, right? My initial comments and understanding would be: 1. A "PT level" wildcard would imply multiple (reserved) media config= urations, i.e., usage of ReserveGroup. 2. A "recv attr-list" level wildcard would enforce the MG to reply th= e choosen/supported attribute values 3. Like to suggest you specify the SDP wildcarding of this attribute = in H.248.39, because a. the wildcard "*" is applicable for SIP signalling, whereas the SDP= mapping to H.248 allows principally also to use additional wildcards (here= e.g., "$" and "-"); and b. possible interactions with ReserveValue/ReserveGroup. 4. Example from 26.114 ("I've copied one below"): 26.116 is not using the "PT level" wildcard at all, because there's just a = single video codec (H.264) considered by 26.114, - right? Regards, Albrecht _______ SIP/SDP example (26.114): Table A.4.10a: Example SDP offer for H.264/AVC with image size negotiation SDP offer a=3Dtcap:1 RTP/AVPF m=3Dvideo 49154 RTP/AVP 99 a=3Dpcfg:1 t=3D1 b=3DAS:315 b=3DRS:0 b=3DRR:2500 a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 packetization-mode=3D0; profile-level-id=3D42e00c; \ sprop-parameter-sets=3DJ0LgDJWgUH6Af1A=3D,KM46gA=3D=3D a=3Dimageattr:99 send [x=3D176,y=3D144] [x=3D224,y=3D176] [x=3D272,y=3D224]= [x=3D320,y=3D240] recv [x=3D176,y=3D144] [x=3D224,y=3D176] [x=3D272,y=3D22= 4,q=3D0.6] [x=3D320,y=3D240] a=3Drtcp-fb:* trr-int 5000 a=3Drtcp-fb:* nack a=3Drtcp-fb:* nack pli a=3Drtcp-fb:* ccm fir a=3Drtcp-fb:* ccm tmmbr a=3Dextmap:4 urn:3gpp:video-orientation --_000_786615F3A85DF44AA2A76164A71FE1AC08A85CFR711WXCHMBA03zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 2nd discus= sion subject was related to revised SDP O/A elements:

 <= /p>

RFC 6236 explicitly indic= ates their (=3D RFC 5939 & RFC 6871) usage (see clause 3.2.6/RFC 6236).=

...

      a=3Dmcap:1 video H264/90000=

      a=3Dacap:1 imageattr:%1% se= nd [x=3D720,y=3D576,sar=3D[0.91,1.0,1.09,1.45]]

      ...

 <= /p>

Also 26.114 indicates (RF= C 5939) usage in the example:

…

a=3Dtcap:1

 <= /p>

The general comment made = in the CT4 meeting:  the mapping of these SDP elements from SIP to H.2= 48 would need to take the work of H.248.80 into account (due to the different resource reservation principles at SIP and H.248 interfac= es).

 <= /p>

-Albrecht

 <= /p>

 <= /p>

From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.o= rg] On Behalf Of Schwarz, Albrecht (Albrecht)
Sent: Mittwoch, 7. August 2013 12:07
To: ext Nevenka Biondic; megaco@ietf.org; 3GPP_TSG_CT_WG4@LIST.ETSI.= ORG
Subject: [Megaco] SDP attribute "a=3Dimageattr:": (1) wild= carding [3GPP CT4 "SIS-CT"]

 

Hi Nevenka, all,

you proposed to continue the technical = discussion at next CT4 meeting; like to suggest to start in parallel the cl= arification of  raised H.248 aspects .

 

The first topic is related to SDP wildc= arding:

 

RFC 6236 allows wildcard usage for mult= iple attribute parameters.

I think we may just focus on the high l= evel SDP format:

 

      a=3Dimageattr:PT send attr-= list recv attr-list

 

The wildcard “*” (ALL) may be appl= ied principally for multiple attribute elements (= in red), right?

 

      a=3Dimageattr:PT send attr-list recv a= ttr-list

 

e.g., PT:

A wild card (*) can be specified for the payload type numb= er to indicate that it applies

      to all payload types in the= media description.

 

You mentioned (in the CT4 discussion) w= ildcard usage at the level of

1) PT

2) recv attr-list

as far as I remember, and the PT type w= ildcard is the difficult one, because affecting possibly multiple media con= figurations, right?

 

My initial comments and understanding w= ould be:

1.    &nb= sp;  A “PT level” wildca= rd would imply multiple (reserved) media configurations, i.e., usage of Res= erveGroup.

2.    &nb= sp;  A “recv attr-list” = level wildcard would enforce the MG to reply the choosen/supported attribut= e values

3.    &nb= sp;  Like to suggest you specify the= SDP wildcarding of this attribute in H.248.39, because

a.    &nb= sp;  the wildcard “*” is= applicable for SIP signalling, whereas the SDP mapping to H.248 allows pri= ncipally also to use additional wildcards (here e.g., “$” and &= #8220;-“);
and

b.    &nb= sp; possible interactions with Rese= rveValue/ReserveGroup.

4.    &nb= sp;  Example from 26.114 (“I&#= 8217;ve copied one below”):
26.116 is not using the “PT level” wildcard at all, because the= re’s just a single video codec (H.264) considered by 26.114, - right?=

 

Regards,

Albrecht

_______

SIP/SDP example (26.114):

Table A.4.10a: Example SDP offer for H.264/AVC with image size negot= iation

SDP offer

a=3Dtcap:1 RTP/AVPF

m=3Dvideo 49154 RTP/AVP 99

a=3Dpcfg:1 t=3D1

b=3DAS:315

b=3DRS:0

b=3DRR:2500

a=3Drtpmap:99 H264/90000

a=3Dfmtp:99 packetization-mode=3D0; profile-level-id=3D42e0= 0c; \

     sprop-parameter-sets=3DJ0LgDJWgUH6= Af1A=3D,KM46gA=3D=3D

a=3Dimageattr:99 send [x=3D176,y=3D144] [= x=3D224,y=3D176] [x=3D272,y=3D224] [x=3D320,y=3D240] recv [x=3D176,y=3D144]= [x=3D224,y=3D176] [x=3D272,y=3D224,q=3D0.6] [x=3D320,y=3D240]

a=3Drtcp-fb:* trr-int 5000

a=3Drtcp-fb:* nack

a=3Drtcp-fb:* nack pli

a=3Drtcp-fb:* ccm fir

a=3Drtcp-fb:* ccm tmmbr

a=3Dextmap:4 urn:3gpp:video-orientation

 

 

 

 

 

 

 

 

 

 

 

--_000_786615F3A85DF44AA2A76164A71FE1AC08A85CFR711WXCHMBA03zeu_-- From Christian.Groves@nteczone.com Thu Aug 8 01:55:14 2013 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE29D21E8054 for ; Thu, 8 Aug 2013 01:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3Hst2FO3N+w for ; Thu, 8 Aug 2013 01:55:14 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 84AF621E8051 for ; Thu, 8 Aug 2013 01:55:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAMVbA1J20Qf5/2dsb2JhbAANToM7vxmBLoMYAQEBBAEBAQkmAQUbGwoBEAsRBAEBAQkMCggHCQMCAQIBFR8JCAYNAQUCAQGIGKY5kiwEj2gzBwqEBAOrD4FL Received: from ppp118-209-7-249.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.7.249]) by ipmail06.adl2.internode.on.net with ESMTP; 08 Aug 2013 18:25:11 +0930 Message-ID: <52035CE7.7040907@nteczone.com> Date: Thu, 08 Aug 2013 18:55:03 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Schwarz, Albrecht (Albrecht)" References: <786615F3A85DF44AA2A76164A71FE1AC08A805@FR711WXCHMBA03.zeu.alcatel-lucent.com> <786615F3A85DF44AA2A76164A71FE1AC08A85C@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC08A85C@FR711WXCHMBA03.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: ext Nevenka Biondic , "megaco@ietf.org" , "3GPP_TSG_CT_WG4@LIST.ETSI.ORG" <3GPP_TSG_CT_WG4@LIST.ETSI.ORG> Subject: Re: [Megaco] SDP attribute "a=imageattr:": (2) revised SDP O/A [3GPP CT4 "SIS-CT"] X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 08:55:14 -0000 Hello Albrecht, I wasn't part of the discussions so I'm not 100% what was being proposed. I'm not sure using "*" for the PT would require the use of reserve value/group. My understanding is that it is simple shorthand if you have a list of payload. A MGC could provide an over specified list of payloads and utilise a=imageattr:*. The MG could response with a single payload and still have a=imageattr:* . With respect to using "*" in the recv attr-list I'm not sure what this would indicate from a H.248 perspective. There seems to be a clash between the RFC6236 and the H.248 usage. RFC6236 indicates that "*" indicates that the user sees no reason to use the image attribute. Whereas the H.248 wildcard usage it would mean use "all" the values. I think this interaction is useful to specify. From a H.248 wildcarding perspective it would seem that "-" truly means the MGC doesn't care and "$" would mean provide a value. There's also the issue of mapping the SDP to the local and remote descriptors. I take it that for H.248 you only specify a=imageattr:PT send attr-list or a=imageattr:PT recv attr-list depending on the descriptor. Regards, Christian On 7/08/2013 8:21 PM, Schwarz, Albrecht (Albrecht) wrote: > > The 2^nd discussion subject was related to revised SDP O/A elements: > > RFC 6236 explicitly indicates their (= RFC 5939 & RFC 6871) usage (see > clause 3.2.6/RFC 6236). > > ... > > a=mcap:1 video H264/90000 > > a=acap:1 imageattr:%1% send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]] > > ... > > Also 26.114 indicates (RFC 5939) usage in the example: > > … > > a=tcap:1 > > The general comment made in the CT4 meeting: the mapping of these SDP > elements from SIP to H.248 would need to take the work of H.248.80 > into account (due to the different resource reservation principles at > SIP and H.248 interfaces). > > -Albrecht > > *From:*megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] *On > Behalf Of *Schwarz, Albrecht (Albrecht) > *Sent:* Mittwoch, 7. August 2013 12:07 > *To:* ext Nevenka Biondic; megaco@ietf.org; 3GPP_TSG_CT_WG4@LIST.ETSI.ORG > *Subject:* [Megaco] SDP attribute "a=imageattr:": (1) wildcarding > [3GPP CT4 "SIS-CT"] > > Hi Nevenka, all, > > you proposed to continue the technical discussion at next CT4 meeting; > like to suggest to start in parallel the clarification of raised H.248 > aspects . > > The first topic is related to SDP wildcarding: > > RFC 6236 allows wildcard usage for multiple attribute parameters. > > I think we may just focus on the high level SDP format: > > a=imageattr:PT send attr-list recv attr-list > > The wildcard “*” (ALL) may be applied principally for multiple > attribute elements (in red), right? > > a=imageattr:PT send attr-list recv attr-list > > e.g., PT: > > A wild card (*) can be specified for the payload type number to > indicate that it applies > > to all payload types in the media description. > > You mentioned (in the CT4 discussion) wildcard usage at the level of > > 1) PT > > 2) recv attr-list > > as far as I remember, and the PT type wildcard is the difficult one, > because affecting possibly multiple media configurations, right? > > My initial comments and understanding would be: > > 1.A “PT level” wildcard would imply multiple (reserved) media > configurations, i.e., usage of ReserveGroup. > > 2.A “recv attr-list” level wildcard would enforce the MG to reply the > choosen/supported attribute values > > 3.Like to suggest you specify the SDP wildcarding of this attribute in > H.248.39, because > > a.the wildcard “*” is applicable for SIP signalling, whereas the SDP > mapping to H.248 allows principally also to use additional wildcards > (here e.g., “$” and “-“); > and > > b.possible interactions with ReserveValue/ReserveGroup. > > 4.Example from 26.114 (“I’ve copied one below”): > 26.116 is not using the “PT level” wildcard at all, because there’s > just a single video codec (H.264) considered by 26.114, - right? > > Regards, > > Albrecht > > _______ > > SIP/SDP example (26.114): > > *Table A.4.10a: Example SDP offer for H.264/AVC with image size > negotiation* > > *SDP offer* > > a=tcap:1 RTP/AVPF > > m=video 49154 RTP/AVP 99 > > a=pcfg:1 t=1 > > b=AS:315 > > b=RS:0 > > b=RR:2500 > > a=rtpmap:99 H264/90000 > > a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ > > sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== > > a=imageattr:99 send [x=176,y=144] [x=224,y=176] [x=272,y=224] > [x=320,y=240] recv [x=176,y=144] [x=224,y=176] [x=272,y=224,q=0.6] > [x=320,y=240] > > a=rtcp-fb:* trr-int 5000 > > a=rtcp-fb:* nack > > a=rtcp-fb:* nack pli > > a=rtcp-fb:* ccm fir > > a=rtcp-fb:* ccm tmmbr > > a=extmap:4 urn:3gpp:video-orientation > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco From albrecht.schwarz@alcatel-lucent.com Thu Aug 8 08:05:16 2013 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D804711E81E0 for ; Thu, 8 Aug 2013 08:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.098 X-Spam-Level: X-Spam-Status: No, score=-9.098 tagged_above=-999 required=5 tests=[AWL=-0.899, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QosyEcouWSmc for ; Thu, 8 Aug 2013 08:05:11 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id F20D111E8168 for ; Thu, 8 Aug 2013 08:05:10 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r78F4tPU003482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Aug 2013 10:04:58 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r78F4sL0019872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Aug 2013 17:04:55 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.135]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 8 Aug 2013 17:04:54 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Christian Groves Thread-Topic: [Megaco] SDP attribute "a=imageattr:": (2) revised SDP O/A [3GPP CT4 "SIS-CT"] Thread-Index: AQHOk1fcXbsj56OuLkSyFyNNJg5+I5mK4bqAgAB4F5A= Date: Thu, 8 Aug 2013 15:04:54 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC08B69E@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <786615F3A85DF44AA2A76164A71FE1AC08A805@FR711WXCHMBA03.zeu.alcatel-lucent.com> <786615F3A85DF44AA2A76164A71FE1AC08A85C@FR711WXCHMBA03.zeu.alcatel-lucent.com> <52035CE7.7040907@nteczone.com> In-Reply-To: <52035CE7.7040907@nteczone.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: ext Nevenka Biondic , "megaco@ietf.org" , "3GPP_TSG_CT_WG4@LIST.ETSI.ORG" <3GPP_TSG_CT_WG4@LIST.ETSI.ORG> Subject: Re: [Megaco] SDP attribute "a=imageattr:": (2) revised SDP O/A [3GPP CT4 "SIS-CT"] X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 15:05:17 -0000 Thanks Christian for you evaluation and further insights! Concerning 3GPP Iq, I guess that both wildcarding levels need to be describ= ed: "PT level" wildcard: expected not to be used at IMS call control level (due= to single video codec); thus the IMS-ALG shall not use "PT wildcarding" as= well at gateway control level "attr level" wildcard: guess "$" and "-" both are applicable, dependent on = the use case (IMS-AGW either agnostic to video processing or the IMS-AGW is= requested for some kind of "video transcoding" (which might be "video tran= ssizing" here)). Nevenka, could you please indicate your specific points? I think its not so simply just to check out H.248.1 wildcarding usage and c= ommand.reply rules. It was observed that wildcarding at the level of H.248-= embedded SDP needs carefull consideration, that's H.248.39 was established = to describe wildcarding at SDP level in more detail. Further: I would appreciate if you could transform the 26.114 SIP/SDP examp= le on an H.248 command request. Just considering a single (H.248) Stream Endpoint/Termination might not be = sufficient because the IMS-AGW must compare the two Stream Descriptors of e= ach SEP/Termination (see above ... agnostic vs video specific support ...). Regards, Albrecht=20 -----Original Message----- From: Christian Groves [mailto:Christian.Groves@nteczone.com]=20 Sent: Donnerstag, 8. August 2013 10:55 To: Schwarz, Albrecht (Albrecht) Cc: ext Nevenka Biondic; megaco@ietf.org; 3GPP_TSG_CT_WG4@LIST.ETSI.ORG Subject: Re: [Megaco] SDP attribute "a=3Dimageattr:": (2) revised SDP O/A [= 3GPP CT4 "SIS-CT"] Hello Albrecht, I wasn't part of the discussions so I'm not 100% what was being proposed. I'm not sure using "*" for the PT would require the use of reserve value/gr= oup. My understanding is that it is simple shorthand if you have a list of = payload. A MGC could provide an over specified list of payloads and utilise= a=3Dimageattr:*. The MG could response with a single payload and still hav= e a=3Dimageattr:* . With respect to using "*" in the recv attr-list I'm not sure what this woul= d indicate from a H.248 perspective. There seems to be a clash between the = RFC6236 and the H.248 usage. RFC6236 indicates that "*"=20 indicates that the user sees no reason to use the image attribute.=20 Whereas the H.248 wildcard usage it would mean use "all" the values. I thin= k this interaction is useful to specify. From a H.248 wildcarding perspecti= ve it would seem that "-" truly means the MGC doesn't care and "$" would me= an provide a value. There's also the issue of mapping the SDP to the local and remote descripto= rs. I take it that for H.248 you only specify a=3Dimageattr:PT send attr-li= st or a=3Dimageattr:PT recv attr-list depending on the descriptor. Regards, Christian On 7/08/2013 8:21 PM, Schwarz, Albrecht (Albrecht) wrote: > > The 2^nd discussion subject was related to revised SDP O/A elements: > > RFC 6236 explicitly indicates their (=3D RFC 5939 & RFC 6871) usage (see= =20 > clause 3.2.6/RFC 6236). > > ... > > a=3Dmcap:1 video H264/90000 > > a=3Dacap:1 imageattr:%1% send [x=3D720,y=3D576,sar=3D[0.91,1.0,1.09,1.45]= ] > > ... > > Also 26.114 indicates (RFC 5939) usage in the example: > > ... > > a=3Dtcap:1 > > The general comment made in the CT4 meeting: the mapping of these SDP=20 > elements from SIP to H.248 would need to take the work of H.248.80=20 > into account (due to the different resource reservation principles at=20 > SIP and H.248 interfaces). > > -Albrecht > > *From:*megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] *On=20 > Behalf Of *Schwarz, Albrecht (Albrecht) > *Sent:* Mittwoch, 7. August 2013 12:07 > *To:* ext Nevenka Biondic; megaco@ietf.org;=20 > 3GPP_TSG_CT_WG4@LIST.ETSI.ORG > *Subject:* [Megaco] SDP attribute "a=3Dimageattr:": (1) wildcarding=20 > [3GPP CT4 "SIS-CT"] > > Hi Nevenka, all, > > you proposed to continue the technical discussion at next CT4 meeting;=20 > like to suggest to start in parallel the clarification of raised H.248=20 > aspects . > > The first topic is related to SDP wildcarding: > > RFC 6236 allows wildcard usage for multiple attribute parameters. > > I think we may just focus on the high level SDP format: > > a=3Dimageattr:PT send attr-list recv attr-list > > The wildcard "*" (ALL) may be applied principally for multiple=20 > attribute elements (in red), right? > > a=3Dimageattr:PT send attr-list recv attr-list > > e.g., PT: > > A wild card (*) can be specified for the payload type number to=20 > indicate that it applies > > to all payload types in the media description. > > You mentioned (in the CT4 discussion) wildcard usage at the level of > > 1) PT > > 2) recv attr-list > > as far as I remember, and the PT type wildcard is the difficult one,=20 > because affecting possibly multiple media configurations, right? > > My initial comments and understanding would be: > > 1.A "PT level" wildcard would imply multiple (reserved) media=20 > configurations, i.e., usage of ReserveGroup. > > 2.A "recv attr-list" level wildcard would enforce the MG to reply the=20 > choosen/supported attribute values > > 3.Like to suggest you specify the SDP wildcarding of this attribute in=20 > H.248.39, because > > a.the wildcard "*" is applicable for SIP signalling, whereas the SDP=20 > mapping to H.248 allows principally also to use additional wildcards=20 > (here e.g., "$" and "-"); and > > b.possible interactions with ReserveValue/ReserveGroup. > > 4.Example from 26.114 ("I've copied one below"): > 26.116 is not using the "PT level" wildcard at all, because there's=20 > just a single video codec (H.264) considered by 26.114, - right? > > Regards, > > Albrecht > > _______ > > SIP/SDP example (26.114): > > *Table A.4.10a: Example SDP offer for H.264/AVC with image size > negotiation* > > *SDP offer* > > a=3Dtcap:1 RTP/AVPF > > m=3Dvideo 49154 RTP/AVP 99 > > a=3Dpcfg:1 t=3D1 > > b=3DAS:315 > > b=3DRS:0 > > b=3DRR:2500 > > a=3Drtpmap:99 H264/90000 > > a=3Dfmtp:99 packetization-mode=3D0; profile-level-id=3D42e00c; \ > > sprop-parameter-sets=3DJ0LgDJWgUH6Af1A=3D,KM46gA=3D=3D > > a=3Dimageattr:99 send [x=3D176,y=3D144] [x=3D224,y=3D176] [x=3D272,y=3D22= 4]=20 > [x=3D320,y=3D240] recv [x=3D176,y=3D144] [x=3D224,y=3D176] [x=3D272,y=3D2= 24,q=3D0.6]=20 > [x=3D320,y=3D240] > > a=3Drtcp-fb:* trr-int 5000 > > a=3Drtcp-fb:* nack > > a=3Drtcp-fb:* nack pli > > a=3Drtcp-fb:* ccm fir > > a=3Drtcp-fb:* ccm tmmbr > > a=3Dextmap:4 urn:3gpp:video-orientation > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco