[Megaco] SDP codepoints for gateway control; FW: IANA "proto" codepoints;

["Schwarz, Albrecht (Albrecht)" <[e-mail]>]

fyi, we'd like to tackle below identified issue concerning dedicated SDP codepoints for gateway control at coming ITU-T Rapporteur Meeting of Questions 1, 2, 3, and 5/16 (http://wftp3.itu.int/av-arch/avc-site/2013-2016/1403_Gen/1403_Gen.html ):

we've reserved following contribution numbers:
AVD-4569 H.Supp.IANA (New): "SDP codepoints for gateway control" - Discussion
AVD-4570 H.Supp.IANA (New): "SDP codepoints for gateway control" - Initial draft
AVD-4571 H.248.TCP - New clause "SDP for gateway control - IANA considerations"
AVD-4572 H.248.TLS - New clause "SDP for gateway control - IANA considerations"
AVD-4573 H.248.DTLS - New clause "SDP for gateway control - IANA considerations"
AVD-4574 H.248.SCTP - New clause "SDP for gateway control - IANA considerations"
	
-Albrecht
ALCATEL-LUCENT


From: Christer Holmberg [mailto:[e-mail]] 
Sent: Freitag, 24. Januar 2014 01:39
To: Christian Groves; Schwarz, Albrecht (Albrecht); Nevenka Biondic; 'Belling, Thomas (NSN - DE/Munich)'; Kall, Jan (NSN - FI/Espoo); Yangweiwei (Tommy); LANDAIS, BRUNO (BRUNO); Peter Schmitt
Cc: DRAGE, Keith (Keith); Arturo Martin De Nicolas
Subject: Re: IANA "proto" codepoints; RE: [eMEDIASEC] P-CR C4-140311 (ex0065) application agnostic DTLS

Hi Christian,

I’ll see what I can find out.

I guess one reason could be that the draft didn't contain any justification/requirements/use-cases.

Regards,

Christer

Sent from Windows Mail

From: Christian Groves
Sent: ‎Friday‎, ‎January‎ ‎24‎, ‎2014 ‎1‎:‎37‎ ‎AM
To: Hans-Christer Holmberg, Schwarz, Albrecht (Albrecht), Nevenka Biondic, 'Belling, Thomas (NSN - DE/Munich)', Kall, Jan (NSN - FI/Espoo), Yangweiwei (Tommy), ext LANDAIS, BRUNO (BRUNO), Peter Schmitt
Cc: DRAGE, Keith (Keith), Arturo Martin De Nicolas

Hello Christer,

It would be good to find out the reason from the MMUSIC chairs/ADs why 
the draft was actually withdrawn.
My guess is that because RFC5764 introduced TCP/TLS/RTP/SAVP, 
UDP/TLS/RTP/SAVP  and  DCCP/TLS/RTP/SAVP  there wasn't much left in 
draft-ietf-mmusic-sdp-dtls-00.  It would only have left  UDP/TLS and 
DCCP/TLS . It would be good to know why these were dropped.

Regards, Christian

On 23/01/2014 5:31 PM, Christer Holmberg wrote:
> Hi,
>
> ‘UDP/TLS/RTP/SAVP’ and ‘DCCP/TLS/RTP/SAVP’ were defined in RFC 5764.
>
> I don’t remember what happened to the draft mentioned by Christian, 
> and why, but obviously it is not progressed.
>
> > yes, "UDP/TLS" would fit.
> > Didn't noticed that draft.
> >
> > Had a quick chat with Christer this morning, he's still thinking 
> about that topic.
>
> One of your suggestions below (Q1) was to do this in the udptl-dtls 
> draft. However, as I also told Albrecht, I don’t support that 
> idea. For one thing, ‘UDP/TLS’ would not be fax specific.
> Another idea mentioned from my side: trying to get a self-contained 
> IETF RFC for that purpose, sth like,
>
> >draft-mmusic-sdp-for-gw: "SDP codepoints for gateway control"
> >scope:
> >1. registration of the "-" (pending since 2005)
> >2. application-agnostic specifically for eMEDIASEC, but there are 
> also other use cases (such as >in context of WebRTC)
> >3. SDP for interlinkage capability (H.248.SEPLINK ->we'll provide 
> some analysis in AVD-4482)
> >4. others (pending issues from the past?)
> >
> >The overall justification is given by the fact that SDP itself is a 
> self-contained protocol, >independent of other protocols such as SIP.
> >Further, SDP is used in
> >a) application control protocols (such as SAP, SIP)
> >b) gateway control protocols (such as H.248, MGCP)
>
> If a draft is written, I think there should be a clear H.248 scope.
>
> >The very majority of SDP elements is common to both control plane 
> protocol categories, >however, there a a few differences:
> >i) SDP for bearer type indication: also application-agnostic 
> codepoints required besides the >usual application-aware codepoints
> >ii) SDP for mode of operation control: the combination of SDP across 
> multiple H.248 >terminations (in order to indicated different MG 
> behaviour)
>
> IETF may, of course, decide that a draft is not needed, that ITU-T can 
> specify the H.248 SDP extensions themselves, and they would then be 
> IANA registered e.g. using an expert review.
>
> It would probably be a good idea to talk with the MMUSIC chairs and 
> ADs, and ask for guidance. Two of them are sitting in my office 
> corridor, so I can have a chat with them next week.
>
> Regards,
>
> Christer
>
>
>
>
> -----Original Message-----
> From: Christian Groves [mailto:[e-mail]]
> Sent: Donnerstag, 23. Januar 2014 05:44
> To: Schwarz, Albrecht (Albrecht); Nevenka Biondic; 'Belling, Thomas 
> (NSN - DE/Munich)'; 'Kall, Jan (NSN - FI/Espoo)'; '[e-mail]'; 
> LANDAIS, BRUNO (BRUNO); Peter Schmitt; Christer Holmberg
> Cc: DRAGE, Keith (Keith); Arturo Martin De Nicolas (AC/EED)
> Subject: Re: IANA "proto" codepoints; RE: [eMEDIASEC] P-CR C4-140311 
> (ex0065) application agnostic DTLS
>
> Hello Albrecht,
>
> I'm not sure what happened to this draft:
> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-dtls-00
>
> In it there was a request for:
>     Type            SDP Name                     Reference
>     ----            ------------------           ---------
>     proto           TCP/TLS/RTP/SAVP [RFC-XXXX]
>                     UDP/TLS/RTP/SAVP [RFC-XXXX]
>                     DCCP/TLS/RTP/SAVP [RFC-XXXX]
>          --->>      UDP/TLS [RFC-XXXX]
>                     DCCP/TLS [RFC-XXXX]
>
> Regards, Christian
>
> On 22/01/2014 6:36 PM, Schwarz, Albrecht (Albrecht) wrote:
> > Hello Christer, et al.,
> >
> > the two UDPTL kind of interworking functions by IMS-AGW (e2ea, e2e) 
> are both application agnostic (see also C4-140203), thus, 
> application-aware codepoint "UDP/TLS/UDPTL" doesn't really match at 
> the H.248 interface.
> > What's required is rather
> > a) "UDP/TLS" or
> > b) "UDP/DTLS".
> >
> > Option a has the issue of 'TLS', but would be consistent with 
> initial DTLS based IANA codepoints (RFC 5764).
> > Option b would be consistent with proposed "SCTP-DTLS" codepoints 
> (SCTP/DTLS, DTLS/SCTP), but inconsistent to "UDP/TLS/UDPTL".
> >
> > Anyway, either a or b would be much better than "UDP/TLS/UDPTL" for 
> above MG interworking scenarios.
> > Now, there might be three options:
> > an IANA registry via
> > O1) IETF MMUSIC, e.g. your draft considers in addition SDP for 
> gateway control (as in H.248, MGCP)
> > O2) ITU-T Q.3/16 requests additional SDP codepoints by IANA (as 
> e.g., done in the past by the T.38 folks for udptl)
> > O3) ITU-T Q.3/16 uses non-SDP based bearer type indications
> >
> > I'm in favour of the first option, perhaps we may use your draft for 
> such a second SDP codepoint, see attachment.
> >
> > Comments?
> > Albrecht
> >
> > PS
> > Pragmatically we could misuse "UDP/TLS/UDPTL" for eMEDIASEC, but the 
> general concern is a future safe design, given by the lessons learnt 
> with e.g. the TISPAN BGW IaV1 and 3GPP IMS-AGW IqV1, which both 
> started as pure media-agnostic gateways, and noone could imagine any 
> need for media aware support functions (remembering the pure "-" 
> design). But both H.248 profiles developed later on to more and more 
> application-specific support functions (IMS-AGW: + ATGW, +audio 
> transcoding, ... +WebRTC).
> >
> >
> >
> > -----Original Message-----
> > From: Schwarz, Albrecht (Albrecht)
> > Sent: Mittwoch, 22. Januar 2014 08:10
> > To: 'Nevenka Biondic'; 'Belling, Thomas (NSN - DE/Munich)'; 'Kall, 
> Jan (NSN - FI/Espoo)'; '[e-mail]'; LANDAIS, BRUNO (BRUNO); 
> 'Peter Schmitt'; 'Christer Holmberg'
> > Cc: DRAGE, Keith (Keith)
> > Subject: [eMEDIASEC] P-CR C4-140311 (ex0065) application agnostic DTLS
> >
> > Dear All,
> > attached the update proposal of this P-CR:
> > 1) clarification of "application" (as discussed by 140203)
> > 2) upgrade to: draft-ietf-mmusic-udptl-dtls-03 (not any impact from 
> -02 based changes)
> > 3) E.N. related to IANA registry
> >
> > Comments?
> > Albrecht
> >
> > PS
> > Like to circulate a separate email concerning the IANA topic.
> >
>