Re: SDP attribute "a=imageattr:": (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/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=3Dimageattr:*. The MG could response with a single =

payload and still have a=3Dimageattr:* .

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=3Dimageattr:PT =

send attr-list or a=3Dimageattr:PT recv attr-list depending on the descript=
or.

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 =

> 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:
>
> =85
>
> a=3Dtcap: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:*[email protected] [mailto:[email protected]] *On =

> Behalf Of *Schwarz, Albrecht (Albrecht)
> *Sent:* Mittwoch, 7. August 2013 12:07
> *To:* ext Nevenka Biondic; [email protected]; [email protected]
> *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 =93*=94 (ALL) may be applied principally for multiple =

> 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 =

> 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 =93PT level=94 wildcard would imply multiple (reserved) media =

> configurations, i.e., usage of ReserveGroup.
>
> 2.A =93recv attr-list=94 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 =93*=94 is applicable for SIP signalling, whereas the SDP =

> mapping to H.248 allows principally also to use additional wildcards =

> (here e.g., =93$=94 and =93-=93);
> and
>
> b.possible interactions with ReserveValue/ReserveGroup.
>
> 4.Example from 26.114 (=93I=92ve copied one below=94):
> 26.116 is not using the =93PT level=94 wildcard at all, because there=92s =

> 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] =

> [x=3D320,y=3D240] recv [x=3D176,y=3D144] [x=3D224,y=3D176] [x=3D272,y=3D2=
24,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
>
>
>
> _______________________________________________
> Megaco mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/megaco