SDP attribute "a=imageattr:": (1) wildcarding [3GPP CT4 "SIS-CT"]
"Schwarz, Albrecht (Albrecht)" <[email protected]> Wed, 7 Aug 2013 10:06:39 +0000
| Newsgroups | gmane.ietf.megaco |
|---|---|
| Message-ID | <786615F3A85DF44AA2A76164A71FE1AC08A805@FR711WXCHMBA03.zeu.alcatel-lucent.com> |
--===============1904452921292643510==
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_786615F3A85DF44AA2A76164A71FE1AC08A805FR711WXCHMBA03zeu_"
--_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
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
#800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Calibri" size=3D"2"><span style=3D"font-size:11pt;">
<div>Hi Nevenka, all, </div>
<div>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 .</div>
<div> </div>
<div>The first topic is related to SDP wildcarding:</div>
<div> </div>
<div>RFC 6236 allows wildcard usage for multiple attribute parameters.</div=
>
<div>I think we may just focus on the high level SDP format:</div>
<div> </div>
<div><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">=
a=3Dimageattr:PT send attr-list recv attr-li=
st</span></font></div>
<div> </div>
<div>The <font color=3D"red">wildcard </font><font color=3D"red">“</f=
ont><font color=3D"red">*</font><font color=3D"red">”</font> (ALL) ma=
y be applied principally for multiple attribute elements (<font color=3D"re=
d">in red</font>), right?</div>
<div> </div>
<div><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">=
a=3Dimageattr:<font color=3D"red">PT</font> =
send <font color=3D"red">attr-list</font> recv <font color=3D"red">attr-lis=
t</font></span></font></div>
<div> </div>
<div>e.g., PT: </div>
<div><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">=
A wild card (*) can be specified for the payload type number to indicate th=
at it applies</span></font></div>
<div><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">=
to all payload types in the media descriptio=
n. </span></font></div>
<div> </div>
<div>You mentioned (in the CT4 discussion) wildcard usage at the level of</=
div>
<div>1) PT</div>
<div>2) recv attr-list</div>
<div>as far as I remember, and the PT type wildcard is the difficult one, b=
ecause affecting possibly multiple media configurations, right?</div>
<div> </div>
<div>My initial comments and understanding would be:</div>
<ol style=3D"margin:0;padding-left:36pt;">
<li>A “PT level” wildcard would imply multiple (reserved) media=
configurations, i.e., usage of ReserveGroup.</li><li>A “recv attr-li=
st” level wildcard would enforce the MG to reply the choosen/supporte=
d attribute values</li><li>Like to suggest you specify the SDP wildcarding =
of this attribute in H.248.39, because</li></ol>
<ol type=3D"a" style=3D"margin:0;padding-left:72pt;">
<li> 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 “-“);<br>
and</li><li>possible interactions with ReserveValue/ReserveGroup.</li></ol>
<ol start=3D"4" style=3D"margin:0;padding-left:36pt;">
<li>Example from 26.114 (“I’ve copied one below”):<br>
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?=
</li></ol>
<div> </div>
<div>Regards,</div>
<div>Albrecht</div>
<div>_______</div>
<div>SIP/SDP example (26.114):</div>
<div align=3D"center" style=3D"text-align:center;margin-top:3pt;margin-bott=
om:9pt;"><font face=3D"Arial"><b>Table A.4.10a: Example SDP offer for H.264=
/AVC with image size negotiation</b></font></div>
<table width=3D"803" style=3D"width:482.25pt;margin-left:4pt;">
<col width=3D"803" style=3D"width:482.25pt;">
<tr>
<td align=3D"center" style=3D"text-align:center;"><font face=3D"Arial" size=
=3D"2"><span style=3D"font-size:9pt;"><b>SDP offer</b></span></font></td>
</tr>
<tr>
<td><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:9pt;">a=
=3Dtcap:1 RTP/AVPF
<div>m=3Dvideo 49154 RTP/AVP 99 </div>
<div>a=3Dpcfg:1 t=3D1</div>
<div>b=3DAS:315</div>
<div>b=3DRS:0</div>
<div>b=3DRR:2500</div>
<div>a=3Drtpmap:99 H264/90000</div>
<div>a=3Dfmtp:99 packetization-mode=3D0; profile-level-id=3D42e00c; \</div>
<div> sprop-parameter-sets=3DJ0LgDJWgUH6Af1A=3D,KM4=
6gA=3D=3D</div>
<div><span style=3D"background-color:yellow;">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></div>
<div>a=3Drtcp-fb:* trr-int 5000</div>
<div>a=3Drtcp-fb:* nack</div>
<div>a=3Drtcp-fb:* nack pli</div>
<div>a=3Drtcp-fb:* ccm fir</div>
<div>a=3Drtcp-fb:* ccm tmmbr</div>
<div>a=3Dextmap:4 urn:3gpp:video-orientation</div>
</span></font></td>
</tr>
</table>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
</span></font>
</body>
</html>
--_000_786615F3A85DF44AA2A76164A71FE1AC08A805FR711WXCHMBA03zeu_--
--===============1904452921292643510==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Megaco mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/megaco
--===============1904452921292643510==--