Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=" line

From: Christian Groves <[email-masked]>
Date: Fri, 04 Aug 2006 11:28:00 +1000

Hello Bruno and Christer,

If this the MG is media unaware isn't this then a "data service"? and 
DATA can be used as a media type and the appropriate fields used?

If we're not extending to all properties then wouldn't the required 
properties need to explained in any additions?

Regards, Christian

CHATRAS Bruno RD-CORE-ISS wrote:

>I would of course vote of option a) as well. I don't think we need to extend this to all properties. This convention can be restricted to SDP fields. 
>
>The Binary case is different. If SDP fields are represented by dedicated tags (e.g. Media/1001), then the MGC can simply omit the parameters that are meaningless. If the SDP equivalent (e.g. SDP_M) are used then the "-" convention shall also be used in the valeu field of the TLV parameter.
>
>Regards,
>Bruno
>
>-----Message d'origine-----
>De : Christer Holmberg [mailto:[email-masked]] 
>Envoyé : mardi 25 juillet 2006 09:34
>À : Christian Groves; [email-masked]
>Cc : CHATRAS Bruno RD-CORE-ISS; [email-masked]; Campos, Simao
>Objet : Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=" line
>
>Hi Christian,
>
>As Bruno also said, in future the Ia profile may become media aware, so we can't just say that "-" means that you can send whatever you want since the receiver doesn't care about the value. We will need a dedicated "do not care" value, so that the receiver knows whether it should care or not.
>
>For the response I would vote for option a).
>
>Regards,
>
>Christer
>
>________________ Reply Header ________________
>Subject:	Re: [Megaco] ETSI H.248 Ia Profile: issue with media value	'-'in SDP"m=" line
>Author:	"Christian Groves" <[email-masked]>
>Date:		25th July 2006 10:06:12 am
>
>Hello All,
>
>I'm not really comfortable with this being added via the way of the implementors guide (e.g. I don't support this). In an earlier email Bruno had concerns other the ability of ability of previous Ia implementations to accept a CR on this. I think we strike the same (if not bigger) problem if we simply state "-" is supported. I would assume there are a lot more H.248.1 implementations than Ia implementations out there. If we added this we would be introducing a possible error to a greater set of implementations.
>
>I would also consider the use of "-" as new functionality. Is this used in command requests AND responses?
>
>Let's look at the original text from the Ia profile:
>"-" may be used for the transport value, unless transport specific behaviour is required by the MG. 
>"-" may be used for the format list value. Other values shall be ignored.
>
>Now H.248 requires that fully compliant SDP be returned in the command response. So what does this text really mean?
>a) Does "-" mean the MGC doesn't care and return "-" in the command reply?
>b) Does "-" mean the MGC doesn't care but its up to the MG to choose something.
>c) The Ia profile doesn't care what is put there. Any valid SDP can be used.
>
>If its a) then its definately not an implementor's guide change. As now we have to change things in command requests and responses. Do we also need to add this "don't care" to all properties. e.g. for the ASN.1?
>If its b) then it sound like CHOOSE ? is really what it being requested.
>If its c) I believe is the original intention from profiles and was probably lost in translation (e.g. a derivitive of the Q.1950 text) then "-" is never sent and this can be fixed in the Ia profile which introduced this problem.
>
>Regards, Christian
>
>[email-masked] wrote:
>
>  
>
>>Hi,
>>
>>it's a syntax issue. An implementation following strictly ES 283 018 
>>v1.1.1 may not work due to RFC 2327 and H.248.1 (09/2005) baseline (in 
>>my understanding of the profile specification).
>>'-' is an implicit SDP syntax extension in ES 283 018 IMHO.
>>
>>I do accept all your arguments in favour for '-', i.e. I won't submit a 
>>CR for 'OMIT'.
>>I do support the clarification proposal for H.248.1 from Kevin/Christer.
>>I'll submit a CR for a new NOTE in Table 81/ES 283 018, pointing out 
>>explicitly the syntax extension.
>>
>>Thanks,
>>regards,
>>
>>Albrecht
>>
>>
>>
>>
>>                                                                                                                                            
>>                     "Christer Holmberg                                                                                                     
>>                     \(JO/LMF\)"                   To:      "Kevin Boyle" <[email-masked]>, "CHATRAS Bruno RD-CORE-ISS"                  
>>                     <christer.holmberg@er         <[email-masked]>, Albrecht SCHWARZ/DE/ALCATEL@ALCATEL                       
>>                     icsson.com>                   cc:      [email-masked]                                                                 
>>                                                   Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in  SDP"m=" line  
>>                     21.07.2006 16:42                                                                                                       
>>                                                                                                                                            
>>
>>
>>
>>
>>
>>Hi,
>>
>>What we need to say is that "-" is allowed in H.248 usage of SDP(in 
>>case
>>H.248.1 still refers to RFC 2327), and we need to say what a "-" value 
>>means.
>>
>>Regards,
>>
>>Christer
>>
>>
>>-----Original Message-----
>>From: Kevin Boyle [mailto:[email-masked]]
>>Sent: 21. heinäkuuta 2006 17:23
>>To: Christer Holmberg (JO/LMF); CHATRAS Bruno RD-CORE-ISS; 
>>[email-masked]
>>Cc: [email-masked]
>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value 
>>'-'in SDP"m=" line
>>
>>I will draft something to be included in the next IG.  Even though we 
>>are talking about something syntactical in nature, the syntax is that 
>>of SDP and not H.248.  It also appears that there is a common 
>>understanding of how this is to be used.  Therefore, I think this falls 
>>into the realm of clarification and not as a change to the procedures of the protocol.
>>
>>As for updating the reference to 4566, I will have to ask the TSB if 
>>that is acceptable in the IG, or if we should look to prepare a 
>>Corrigendum in November.
>>
>>Kevin
>>
>>-----Original Message-----
>>From: Christer Holmberg (JO/LMF) 
>>[mailto:[email-masked]]
>>Sent: Friday, July 21, 2006 5:18 AM
>>To: CHATRAS Bruno RD-CORE-ISS; [email-masked]
>>Cc: [email-masked]
>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value 
>>'-'in SDP"m=" line
>>
>>
>>Hi,
>>
>>I agree with Bruno.
>>
>>Also, H.248.1 does already "extend" RFC 2327, by defining some SDP 
>>values which are not allowed by the RFC, e.g. "*" and "$".
>>
>>I think a solution would be to add text to H.248.1, allowing also the "-"
>>value and define what it is used for (similar to "*" and "$").
>>
>>(It would of course have been good to define the meaning of "-" in RFC 
>>4566, in case some other protocol needs it, but it's too late now.)
>>
>>Regards,
>>
>>Christer
>>
>>
>>
>>-----Original Message-----
>>From: CHATRAS Bruno RD-CORE-ISS [mailto:[email-masked]]
>>Sent: 21. heinäkuuta 2006 10:26
>>To: Christer Holmberg (JO/LMF); [email-masked]
>>Cc: [email-masked]
>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value 
>>'-'in SDP"m=" line
>>
>>Moreover, even if a CR was issued agaisnt ES 283 018 to recommend using 
>>the OMIT token rather than the "-", the "-" would have to be kept in 
>>the Ia profile anyway for backward compatibility purposes. I assume 
>>that we would not like an IP2IP MG to reject an H.248 command just 
>>because it contains a "-" sent by an MGC that has not implemented the CR yet.
>>
>>Regards,
>>Bruno
>>
>>-----Message d'origine-----
>>De : Christer Holmberg (JO/LMF) [mailto:[email-masked]]
>>Envoyé : jeudi 20 juillet 2006 20:46
>>À : [email-masked]
>>Cc : [email-masked]
>>Objet : RE: [Megaco] ETSI H.248 Ia Profile: issue with media value 
>>'-'in SDP"m=" line
>>
>>
>>Hi,
>>
>>Why can't the Ia profile be based on RFC 4566? RFC 3108 is not 
>>referenced by the Ia profile, or by H.248.1.
>>
>>Also, my understanding is that RFC 3108 DOES recommend "-", but says 
>>that "OMIT" can be used due to the syntax issue with RFC 2327.
>>
>>Also, in the RFC 3108 examples "-" is used.
>>
>>Regards,
>>
>>Christer
>>
>>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]
>>Sent: 20. heinäkuuta 2006 12:00
>>To: Christer Holmberg (JO/LMF)
>>Cc: [email-masked]
>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value 
>>'-'in SDP "m=" line
>>
>>
>>Christer, et al.,
>>
>>I was aware of the SDP extension by '-' in "SDP new" (guess will be RFC 
>>4566), when writting my email.
>>(I was not aware of the Q.1950 SDP extensions, but I didn't consider 
>>them because Q.1950 is irrelevant for ETSI ES 283 018.)
>>
>>We came finally to the conclusion that:
>>'OMIT' seems to be the best compromise because
>>* compliant to RFC 2327,
>>* ETSI ES 283 018 v1.1.1 is based on RFC 2327,
>>* when the H.248 Ia Profile will be based on RFC 4566 is still unclear 
>>to me ("I guess that first H.248.1 will obsolete RFC 2327 and then 
>>replace it by RFC 4566, but whether this is a straightforward task or 
>>not, I don't know. Next step then H.248 profiles ..."),
>>* 'OMIT' already recommended (& defined) by RFC 3108 for "media-agnostic"
>>SDP descriptors, so 'OMIT' is not totally new, and
>>* 'OMIT' is inline with separating into media-agnostic and media-aware 
>>IP terminations, and
>>* '-' would be an extension of the SDP grammar of RFC 2327 based H.248 
>>profiles.
>>
>>We will submitt a correspondent CR to next TISPAN meeting.
>>
>>Regards,
>>Albrecht
>>
>>
>>
>>
>>                     "Christer Holmberg
>>
>>                     \(JO/LMF\)"                   To:      "Kevin Boyle"
>><[email-masked]>, "B Venkat S.R Swamy"
>>                     <christer.holmberg@er 
>><[email-masked]>, "Christian Groves"
>><[email-masked]>
>>                     icsson.com>                   cc:      Albrecht
>>SCHWARZ/DE/ALCATEL@ALCATEL, [email-masked]
>>                                                   Subject: RE: 
>>[Megaco] ETSI H.248 Ia Profile: issue with media  value '-'inSDP"m=" line
>>                     17.07.2006 22:00
>>
>>
>>
>>
>>
>>
>>
>>Hi,
>>
>>According to draft-ietf-mmusic-sdp-new-26, which will replace RFC 2327, "-"
>>IS allowed.  Both the media and the fmt parts of the m= line are 
>>defined as tokens.
>>
>>media =               token
>>                           ;typically "audio", "video", "text" or
>>                           ;"application"
>>
>>fmt =                 token
>>                           ;typically an RTP payload type for audio
>>                           ;and video media
>>
>>token =               1*(token-char)
>>
>>token-char =          %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 /
>>%x41-5A / %x5E-7E
>>
>>(The ascii code for "-" is %x2D)
>>
>>
>>Regards,
>>
>>Christer
>>
>>
>>
>>-----Original Message-----
>>From: Kevin Boyle [mailto:[email-masked]]
>>Sent: 17. heinäkuuta 2006 19:58
>>To: B Venkat S.R Swamy; Christian Groves
>>Cc: [email-masked]; [email-masked]; Christer Holmberg
>>(JO/LMF)
>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value 
>>'-'inSDP"m=" line
>>
>>The MGC could place "$" there if it truly did not care.  This would 
>>align better with the intent of both SDP and H.248.
>>
>>Kevin
>>
>>________________________________
>>
>>From: B Venkat S.R Swamy [mailto:[email-masked]]
>>Sent: Monday, July 17, 2006 12:40 AM
>>To: Christian Groves
>>Cc: [email-masked]; [email-masked]; 
>>[email-masked]
>>Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'
>>inSDP"m=" line
>>
>>
>>
>>Hi
>>
>>Although you are right these are don't care values, but the point here 
>>was SDP grammar does not support "-" in the media as shown below.
>>
>>"m=" media space port ["/" integer] space proto 1*(space fmt) CRLF
>>
>>media =               1*(alpha-numeric)
>>;typically "audio", "video", "application"
>>;or "data"
>>
>>therefore the string "OMIT" was suggested for the media, so as not to 
>>violate the SDP grammar.
>>
>>
>>regards
>>B Venkat S.R Swamy
>>Senior Technical Leader
>>Flextronics Software Systems
>>Phone: +91-124- 4176213
>>Fax: +91-124-4300247
>>web: www.flextronicssoftware.com
>>Christian Groves <[email-masked]>
>>
>>
>>
>>
>>                                                Christian Groves 
>><[email-masked]>
>>
>>                                                07/17/2006 06:36 AM
>>
>>
>>
>>To
>>
>>[email-masked]
>>
>>
>>cc
>>
>>B Venkat S.R Swamy/HSS@HSS, [email-masked], 
>>[email-masked]
>>
>>
>>Subject
>>
>>Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-' inSDP"m="
>>line
>>
>>
>>Hello Albrecht,
>>
>>In Q.1950 which encounters a similar issue it states :
>>
>>"NOTE - "-" indicates "do not care" - i.e. the field should be set to 
>>any value valid according to SDP, but it is not used on the CBC interface."
>>
>>So a profile may specify what values it doesn't care about. If it 
>>receives normal SDP values in those positions these can simply be 
>>ignored. No need to say OMIT.
>>
>>Regards, Christian
>>
>>[email-masked] wrote:
>>
>> 
>>
>>    
>>
>>>Thanks for pointing to § 2.5/RFC 3108!
>>>" The string "OMIT" can be used in lieu of "-" for an omitted
>>>   
>>>
>>>      
>>>
>>parameter."
>> 
>>
>>    
>>
>>>Seems to be the best change proposal IMHO.
>>>- Albrecht
>>>
>>>
>>>RFC 3108:
>>> 2.5 Use of special characters in SDP parameter values
>>>
>>>    In general, RFC 2327-conformant string values of SDP parameters
>>>   
>>>
>>>      
>>>
>>[1]
>> 
>>
>>    
>>
>>>    do not include special characters that are neither alphabets nor
>>>    digits.  An exception is the "/" character used in the value
>>>    "RTP/AVP" of transport sub-field of the 'm' line.
>>>
>>>    String values used in SDP descriptions of ATM connections retain
>>>   
>>>
>>>      
>>>
>>this
>> 
>>
>>    
>>
>>>    convention, while allowing the use of the special character "/"
>>>   
>>>
>>>      
>>>
>>in a
>> 
>>
>>    
>>
>>>    manner commensurate with [1].  In addition, the special
>>>   
>>>
>>>      
>>>
>>characters
>> 
>>
>>    
>>
>>>    "$" and "-" are used in the following manner.  A "$" value is a
>>>    wildcard that allows the recipient of the SDP description to
>>>   
>>>
>>>      
>>>
>>select
>> 
>>
>>    
>>
>>>    any permitted value of the parameter.  A "-" value indicates that
>>>   
>>>
>>>      
>>>
>>it
>> 
>>
>>    
>>
>>>    is not necessary to specify the value of the parameter in the SDP
>>>    description because this parameter is irrelevant for this
>>>    application, or because its value can be known from another
>>>   
>>>
>>>      
>>>
>>source
>> 
>>
>>    
>>
>>>    such as provisioning, defaults, another protocol, another SDP
>>>    descriptor or another part of the same SDP descriptor.  If the
>>>   
>>>
>>>      
>>>
>>use of
>> 
>>
>>    
>>
>>>    these special characters is construed as a violation of RFC 2327
>>>   
>>>
>>>      
>>>
>>[1]
>> 
>>
>>    
>>
>>>    syntax, then reserved string values can be used.  The string
>>>   
>>>
>>>      
>>>
>>"CHOOSE"
>> 
>>
>>    
>>
>>>    can be used in lieu of "$".  The string "OMIT" can be used in
>>>   
>>>
>>>      
>>>
>>lieu of
>> 
>>
>>    
>>
>>>    "-" for an omitted parameter.
>>>
>>>
>>>
>>>
>>>
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>                    "B Venkat S.R Swamy"
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>                    <b.swamy@flextronicsso         To:      Albrecht
>>>   
>>>
>>>      
>>>
>>SCHWARZ/DE/ALCATEL@ALCATEL
>> 
>>
>>    
>>
>>>                    ftware.com>                    cc:
>>>   
>>>
>>>      
>>>
>>[email-masked], [email-masked]
>>
>> 
>>
>>    
>>
>>>                                                   Subject: Re:
>>>   
>>>
>>>      
>>>
>>[Megaco] ETSI H.248 Ia Profile: issue with media value '-' in SDP"m="
>> 
>>
>>    
>>
>>>                    14.07.2006 05:59               line
>>>   
>>>
>>>      
>>>
>> 
>>
>>
>> 
>>
>>    
>>
>>>Hi
>>>
>>>I support the option 2, and we should try to avoid any violation of 
>>>the
>>>   
>>>
>>>      
>>>
>>RFC
>> 
>>
>>    
>>
>>>2327/RFC 3108.
>>>The string "OMIT" as suggested by RFC 3108, section 2.5, can be used
>>>   
>>>
>>>      
>>>
>>for
>> 
>>
>>    
>>
>>>media.
>>>Also the use of "-" is not allowed as per RFC 2327/RFC 2848 for the
>>>   
>>>
>>>      
>>>
>>proto
>> 
>>
>>    
>>
>>>field.
>>>
>>>
>>>regards
>>>B Venkat S.R Swamy
>>>Senior Technical Leader
>>>Flextronics Software Systems
>>>Phone: +91-124- 4176213
>>>Fax: +91-124-4300247
>>>web: www.flextronicssoftware.com
>>>(Embedded image moved to file: 
>>>pic12377.gif)[email-masked]
>>>
>>>
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>                       Albrecht
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>                       .Schwarz
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>                       @alcatel
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>                       .de      (Embedded image moved to file:
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>                                pic00224.gif)
>>>   
>>>
>>>      
>>>
>> 
>>
>>To
>> 
>>
>>    
>>
>>>                       07/13/20          (Embedded image moved to
>>>   
>>>
>>>      
>>>
>>file:
>> 
>>
>>    
>>
>>>                       06 09:49          pic02722.gif)
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>                       PM
>>>   
>>>
>>>      
>>>
>>[email-masked],
>> 
>>
>>    
>>
>>>                                         [email-masked]
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>                                (Embedded image moved to file:
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>                                pic31609.gif)
>>>   
>>>
>>>      
>>>
>> 
>>
>>cc
>> 
>>
>>    
>>
>>>                                         (Embedded image moved to
>>>   
>>>
>>>      
>>>
>>file:
>> 
>>
>>    
>>
>>>                                         pic17314.gif)
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>                                         [email-masked]
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>                                (Embedded image moved to file:
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>                                pic14997.gif)
>>>   
>>>
>>>      
>>>
>> 
>>
>>Subject
>> 
>>
>>    
>>
>>>                                         (Embedded image moved to
>>>   
>>>
>>>      
>>>
>>file:
>> 
>>
>>    
>>
>>>                                         pic24297.gif)
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>                                         [Megaco] ETSI H.248 Ia
>>>   
>>>
>>>      
>>>
>>Profile:
>> 
>>
>>    
>>
>>>                                         issue with media value '-'
>>>   
>>>
>>>      
>>>
>>in
>> 
>>
>>    
>>
>>>                                         SDP"m=" line
>>>   
>>>
>>>      
>>>
>> 
>>
>>
>> 
>>
>>
>> 
>>
>>    
>>
>>>                                (Embedded image moved to file:
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>                                pic24565.gif)
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>                                       (Embedded image moved to file:
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>                                       pic28141.gif)
>>>   
>>>
>>>      
>>>
>> 
>>
>>
>> 
>>
>>
>> 
>>
>>    
>>
>>>Christer, et al.,
>>>
>>>media value '-' is not allowed by RFC 2327 (& RFC 3108) in our
>>>understanding:
>>>
>>>RFC 2327:
>>>
>>>
>>>media-descriptions =  *( media-field
>>>
>>>
>>>                         information-field
>>>
>>>
>>>                         *(connection-field)
>>>
>>>
>>>                         bandwidth-fields
>>>
>>>
>>>                         key-field
>>>
>>>
>>>                         attribute-fields )
>>>
>>>
>>>   media-field =         "m=" media space port ["/" integer]
>>>
>>>
>>>                         space proto 1*(space fmt) CRLF
>>>
>>>
>>>   media =               1*(alpha-numeric)
>>>
>>>
>>>                         ;typically "audio", "video", "application"
>>>
>>>
>>>                         ;or "data"
>>>
>>>
>>>RFC 3108:
>>>
>>>
>>>media-descriptions = *(media-description)
>>>
>>>
>>>media-description  = media-field information-field
>>>   
>>>
>>>      
>>>
>>*(connection-field)
>> 
>>
>>    
>>
>>>                     bandwidth-fields key-field attribute-fields
>>>
>>>
>>>media-field = RFC 2327-media-field / RFC 2848-media-field /
>>>
>>>
>>>              atm-media-field
>>>
>>>
>>>    ; RFC 2327-media-field and RFC 2848-media-field defined in those 
>>>rfc's
>>>
>>>
>>>atm-media-field = "m=" media space vcId space transport-fmts EOL
>>>
>>>
>>>   ; superset of RFC 2327 definition
>>>
>>>
>>>media = "audio" / "video" / "data" / "application" / "control" /
>>>
>>>
>>>        1*(alpha-numeric)
>>>
>>>
>>>
>>>If our understanding is correct then either
>>>
>>>(1) ETSI ES 283 018 is extending the SDP codepoint space, leading to 
>>>further differences between H.248/SDP and SIP/SDP, with further 
>>>mapping requirements for the "SDP mapper" (ETSI TR 183 046; WI-03062), 
>>>or
>>>
>>>(2) alternatively we could change the codepoint '-' to an allowed
>>>   
>>>
>>>      
>>>
>>codepoint
>> 
>>
>>    
>>
>>>(e.g., '0', 'none' or 'mediaagnostic' or sth similar).
>>>
>>>We are in favour of (2) due to compliance to RFC 2327.
>>>What is the feeling of others (Tom, guess you got some deep insights
>>>   
>>>
>>>      
>>>
>>with
>> 
>>
>>    
>>
>>>your work on media formats and SDP usage in msf2006.046.01)?
>>>
>>>Regards,
>>>Albrecht
>>>
>>>
>>>PS
>>>Didn't checked yet whether '-' is affecting other SDP codepoints, too.
>>>
>>>
>>>Reference:
>>>ETSI ES 283 018 V1.1.1 (2006-06)
>>>
>>>
>>>
>>>
>>>5.15     Mandatory support of SDP and annex C information elements
>>>
>>>
>>>
>>>            Table 81: Supported SDP Information Elements
>>>|---------------------------+---------------------------+-------------
>>>|---------------------------+---------------------------+-
>>>   
>>>
>>>      
>>>
>>---------------|
>> 
>>
>>    
>>
>>>|  SDP Information Element  |     Mandatory/optional    |
>>>Description         |
>>>|---------------------------+---------------------------+-------------
>>>|---------------------------+---------------------------+-
>>>   
>>>
>>>      
>>>
>>---------------|
>> 
>>
>>    
>>
>>>| Protocol version          | Mandatory                 | The value
>>>   
>>>
>>>      
>>>
>>must
>> 
>>
>>    
>>
>>>always be    |
>>>| "v=" line                 |                           | equals to
>>>   
>>>
>>>      
>>>
>>zero:
>> 
>>
>>    
>>
>>>|
>>>|                           |                           | v=0
>>>|
>>>|---------------------------+---------------------------+-------------
>>>|---------------------------+---------------------------+-
>>>   
>>>
>>>      
>>>
>>---------------|
>> 
>>
>>    
>>
>>>| Connection                | Mandatory                 | The network
>>>   
>>>
>>>      
>>>
>>type
>> 
>>
>>    
>>
>>>must always|
>>>| "c=" line                 |                           | be "IN".
>>>|
>>>|                           |                           |
>>>|
>>>|                           |                           |The address
>>>   
>>>
>>>      
>>>
>>type
>> 
>>
>>    
>>
>>>value must  |
>>>|                           |                           |be "IP4" or
>>>   
>>>
>>>      
>>>
>>"IP6".
>> 
>>
>>    
>>
>>>|
>>>|                           |                           |
>>>|
>>>|                           |                           |The connection
>>>address value |
>>>|                           |                           |may be
>>>underspecified with   |
>>>|                           |                           |CHOOSE
>>>   
>>>
>>>      
>>>
>>wildcard
>> 
>>
>>    
>>
>>>("$").       |
>>>|---------------------------+---------------------------+-------------
>>>|---------------------------+---------------------------+-
>>>   
>>>
>>>      
>>>
>>---------------|
>> 
>>
>>    
>>
>>>| Media                     | Mandatory                 |"-" may be
>>>   
>>>
>>>      
>>>
>>used
>> 
>>
>>    
>>
>>>for the media|
>>>| "m=" line                 |                           |value. Other
>>>values shall be |
>>>|                           |                           |ignored,
>>>   
>>>
>>>      
>>>
>>unless
>> 
>>
>>    
>>
>>>media        |
>>>|                           |                           |specific
>>>information is      |
>>>|                           |                           |required.
>>>|
>>>|                           |                           |
>>>|
>>>|                           |                           |The port value
>>>   
>>>
>>>      
>>>
>>may
>> 
>>
>>    
>>
>>>be        |
>>>|                           |                           |underspecified
>>>with CHOOSE   |
>>>|                           |                           |wildcard
>>>   
>>>
>>>      
>>>
>>("$").
>> 
>>
>>    
>>
>>>|
>>>|                           |                           |
>>>|
>>>|                           |                           |"-" may be
>>>   
>>>
>>>      
>>>
>>used
>> 
>>
>>    
>>
>>>for the      |
>>>|                           |                           |transport
>>>   
>>>
>>>      
>>>
>>value,
>> 
>>
>>    
>>
>>>unless      |
>>>|                           |                           |transport
>>>   
>>>
>>>      
>>>
>>specific
>> 
>>
>>    
>>
>>>behaviour |
>>>|                           |                           |is required by
>>>   
>>>
>>>      
>>>
>>the
>> 
>>
>>    
>>
>>>MG.       |
>>>|                           |                           |(See note)
>>>|
>>>|                           |                           | "-" may be
>>>   
>>>
>>>      
>>>
>>used
>> 
>>
>>    
>>
>>>for the     |
>>>|                           |                           | format list
>>>value. Other    |
>>>|                           |                           | values shall
>>>   
>>>
>>>      
>>>
>>be
>> 
>>
>>    
>>
>>>ignored.    |
>>>|---------------------------+---------------------------+-------------
>>>|---------------------------+---------------------------+-
>>>   
>>>
>>>      
>>>
>>---------------|
>> 
>>
>>    
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>Megaco mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/megaco
>>>
>>>
>>>
>>>*********************** FSS-Restricted ***********************
>>>"DISCLAIMER: This message is proprietary to Flextronics Software 
>>>Systems Limited (FSS) 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. FSS 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
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/megaco
>>>
>>>
>>>
>>>
>>>
>>>
>>>   
>>>
>>>      
>>>
>>-----------------------------------------------------------------------
>>-
>> 
>>
>>    
>>
>>>   
>>>
>>>      
>>>
>>-----------------------------------------------------------------------
>>-
>> 
>>
>>    
>>
>>>   
>>>
>>>      
>>>
>>-----------------------------------------------------------------------
>>-
>> 
>>
>>    
>>
>>>   
>>>
>>>      
>>>
>>-----------------------------------------------------------------------
>>-
>> 
>>
>>    
>>
>>>   
>>>
>>>      
>>>
>>-----------------------------------------------------------------------
>>-
>> 
>>
>>    
>>
>>>   
>>>
>>>      
>>>
>>-----------------------------------------------------------------------
>>-
>> 
>>
>>    
>>
>>>   
>>>
>>>      
>>>
>>-----------------------------------------------------------------------
>>-
>> 
>>
>>    
>>
>>>   
>>>
>>>      
>>>
>>-----------------------------------------------------------------------
>>-
>> 
>>
>>    
>>
>>>   
>>>
>>>      
>>>
>>-----------------------------------------------------------------------
>>-
>> 
>>
>>    
>>
>>>----------------------------------------------------------------------
>>>-
>>>   
>>>
>>>      
>>>
>>-
>> 
>>
>>    
>>
>>>_______________________________________________
>>>Megaco mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/megaco
>>>
>>>
>>>   
>>>
>>>      
>>>
>>
>>
>>*********************** FSS-Restricted ***********************
>>"DISCLAIMER: This message is proprietary to Flextronics Software 
>>Systems Limited (FSS) 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. FSS 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
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>
>>
>>
>>
>>_______________________________________________
>>Megaco mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>_______________________________________________
>>Megaco mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>_______________________________________________
>>Megaco mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>
>>
>>
>>
>>_______________________________________________
>>Megaco mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>
>>
>>
>> 
>>
>>    
>>
>
>
>
>_______________________________________________
>Megaco mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
>
>  
>

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 4 Aug 2006 08:25:50 +0200

Hi,

Eventhough I would prefer "data" over "omit", there are still some issues.

First, "data" has been removed from RFC4566 (new SDP RFC), due to "unclear usage". It can still be used, though, so I don't think that is a major issue. I even think there are use-cases where "data" is needed, but that is a separate discussion.

But, if you use "data", wouldn't you expect something specific in the fmt field? Remember that Ia uses "-" in the fmt field also, because Ia simply doesn't care.

So, it's not only the media type where we need to be able to indicate "don't care".

In fact, it's not even only in the m= line where we need it. H.248.20 uses "-" in the c= line. 

H.248.20 does say that any value can be used, and that "-" is simply a recommendation. But, in the H.248.20 case we don't have the problem that the receiver sometimes shall care, and in other cases it doesn't need to care. But, again, in Ia we will have that problem once/if media awareness is added to the profile.

So, I think it would be good if H.248.1 said that "-" can be used in ALL SDP parameter fields, because in future we may find other places where it may be needed.

Regards,

Christer

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: 4. elokuuta 2006 4:28
To: CHATRAS Bruno RD-CORE-ISS
Cc: Christer Holmberg (JO/LMF); [email-masked]; [email-masked]; Campos, Simao
Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=" line

If this the MG is media unaware isn't this then a "data service"? and DATA can be used as a media type and the appropriate fields used?

If we're not extending to all properties then wouldn't the required properties need to explained in any additions?

Regards, Christian

CHATRAS Bruno RD-CORE-ISS wrote:

>À : Christian Groves; [email-masked] Cc : CHATRAS Bruno 
>RD-CORE-ISS; [email-masked]; Campos, Simao Objet : Re: [Megaco] ETSI 
>H.248 Ia Profile: issue with media value '-'in SDP"m=" line
>
>Hi Christian,
>
>>I do accept all your arguments in favour for '-', i.e. I won't submit 
>>a CR for 'OMIT'.
>>understanding of how this is to be used.  Therefore, I think this 
>>falls into the realm of clarification and not as a change to the procedures of the protocol.
>>
>>Moreover, even if a CR was issued agaisnt ES 283 018 to recommend 
>>using the OMIT token rather than the "-", the "-" would have to be 
>>kept in the Ia profile anyway for backward compatibility purposes. I 
>>assume that we would not like an IP2IP MG to reject an H.248 command 
>>just because it contains a "-" sent by an MGC that has not implemented the CR yet.
>>
>>Regards,
>>Bruno
>>
>>I was aware of the SDP extension by '-' in "SDP new" (guess will be 
>>RFC 4566), when writting my email.
>>>mapping requirements for the "SDP mapper" (ETSI TR 183 046; 
>>>WI-03062), or
>>>
>>>|---------------------------+---------------------------+------------
>>>|---------------------------+---------------------------+------------
>>>|---------------------------+---------------------------+------------
>>>|---------------------------+---------------------------+------------
>>>|---------------------------+---------------------------+------------

---

From: [email-masked]
Date: Fri, 4 Aug 2006 16:16:35 +0200

Hello,

there seems to be no agreement for a general "retroactive" change in
H.248.1.
Thus, following stepwise proceeding could be a way forward IMHO:

1st
   Limit scope and applicability of "-" on H.248 Ia Profile Version 1 only.
   [Because ETSI_BGF/1 is based on RFC 2327 and H.248.1 V3 (09/2005).]
   Clarify in a CR for ETSI ES 283 018 the RFC 2327 extension "-" in the
   text.

2nd
   Replacement of RFC 2327 by RFC 4566 in H.248.1. We need an investigation
   which parts of H.248.1 will be affected. Such investigations (due to RFC
   2327 replacement by RFC 4566) are already in progress for other
   protocols (see e.g. 3GPP) which are based on RFC 2327.
   There might be then a future release H.248.1 V3 (xx/2006?).

3rd
   When a "RFC 4566"-based H.248.1 (xx/2006?) will be available, then we
   may
   a) "legalize" "-" in ETSI_BGF/1 by a correspondent update of ETSI ES 283
   018,
   and/or
   b) base the next profile version ETSI_BGF/2 on H.248.1 V3 (xx/2006?)
   anyway.

The advantage of such a proceeding would be:
- general applicability of "-" would be linked with RFC 2327 replacement by
RFC 4566 in H.248.1, and
- codepoint "-" in ETSI_BGF/1 would not change in future profile versions.

/Albrecht

                      "Christer Holmberg                                                                                                   
                      \(JO/LMF\)"                   To:      "Christian Groves" <[email-masked]>, "CHATRAS Bruno            
                      <christer.holmberg@er         RD-CORE-ISS" <[email-masked]>                                             
                      icsson.com>                   cc:      Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, <[email-masked]>, "Campos, Simao"       
                                                    <[email-masked]>                                                                 
                      04.08.2006 08:25              Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value  '-'in SDP"m="     
                                                    line                                                                                   

Hi,

First, "data" has been removed from RFC4566 (new SDP RFC), due to "unclear
usage". It can still be used, though, so I don't think that is a major
issue. I even think there are use-cases where "data" is needed, but that is
a separate discussion.

But, if you use "data", wouldn't you expect something specific in the fmt
field? Remember that Ia uses "-" in the fmt field also, because Ia simply
doesn't care.

So, it's not only the media type where we need to be able to indicate
"don't care".

In fact, it's not even only in the m= line where we need it. H.248.20 uses
"-" in the c= line.

H.248.20 does say that any value can be used, and that "-" is simply a
recommendation. But, in the H.248.20 case we don't have the problem that
the receiver sometimes shall care, and in other cases it doesn't need to
care. But, again, in Ia we will have that problem once/if media awareness
is added to the profile.

So, I think it would be good if H.248.1 said that "-" can be used in ALL
SDP parameter fields, because in future we may find other places where it
may be needed.

Regards,

Christer

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: 4. elokuuta 2006 4:28
To: CHATRAS Bruno RD-CORE-ISS
Cc: Christer Holmberg (JO/LMF); [email-masked];
[email-masked]; Campos, Simao
Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in
SDP"m=" line

If this the MG is media unaware isn't this then a "data service"? and DATA
can be used as a media type and the appropriate fields used?

Regards, Christian

CHATRAS Bruno RD-CORE-ISS wrote:

>I would of course vote of option a) as well. I don't think we need to
extend this to all properties. This convention can be restricted to SDP
fields.
>
>The Binary case is different. If SDP fields are represented by dedicated
tags (e.g. Media/1001), then the MGC can simply omit the parameters that
are meaningless. If the SDP equivalent (e.g. SDP_M) are used then the "-"
convention shall also be used in the valeu field of the TLV parameter.
>As Bruno also said, in future the Ia profile may become media aware, so we
can't just say that "-" means that you can send whatever you want since the
receiver doesn't care about the value. We will need a dedicated "do not
care" value, so that the receiver knows whether it should care or not.
>I'm not really comfortable with this being added via the way of the
implementors guide (e.g. I don't support this). In an earlier email Bruno
had concerns other the ability of ability of previous Ia implementations to
accept a CR on this. I think we strike the same (if not bigger) problem if
we simply state "-" is supported. I would assume there are a lot more
H.248.1 implementations than Ia implementations out there. If we added this
we would be introducing a possible error to a greater set of
implementations.
>Now H.248 requires that fully compliant SDP be returned in the command
response. So what does this text really mean?
>If its a) then its definately not an implementor's guide change. As now we
have to change things in command requests and responses. Do we also need to
add this "don't care" to all properties. e.g. for the ASN.1?
>If its c) I believe is the original intention from profiles and was
probably lost in translation (e.g. a derivitive of the Q.1950 text) then
"-" is never sent and this can be fixed in the Ia profile which introduced
this problem.

>>                     \(JO/LMF\)"                   To:      "Kevin Boyle"
<[email-masked]>, "CHATRAS Bruno RD-CORE-ISS"
>>                     <christer.holmberg@er
<[email-masked]>, Albrecht SCHWARZ/DE/ALCATEL@ALCATEL

>>                                                   Subject: RE: [Megaco]
ETSI H.248 Ia Profile: issue with media value '-'in  SDP"m=" line

---

From: Christian Groves <[email-masked]>
Date: Mon, 07 Aug 2006 16:14:49 +1000

Hello Christer,

You could use:

m = application 1233456 udp application/octet-stream

Yes H.248.20 does use "-" in the  c = however it is allowed to do this 
by RFC2327.

So there seems to be some disagreement between the proponents of "-" of 
whether this is a general mechanism or for specific parameters. I would 
have thought both media aware and media unaware gateways would be 
interested in receiving valid SDP.

For H.248.1 v1, v2, v3 implementations which are based on RFC2327 the 
use of "-" is not supported for the m= line. A subsequent version of 
H.248.1 could be based on RFC4566 and would then allow the use of "-" in 
m=. I'm little hesitant in saying "-" can be used in ANY SDP field if it 
has not been allowed even in RFC4566.

Having said that I think Albrecht's approach is a pragmatic way forward. 
In addition the Tispan work could adopt the "application" example as 
outlined above for media unaware MGs.

Regards, Christian

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 7 Aug 2006 09:02:01 +0200

Hi Christian, 

>m = application 1233456 udp application/octet-stream

I guess you should change order of "udp" and "application/octet-stream" (assuming "udp" is the fmt value)?

Anyway, I think "data" would fit better than "application".

>Yes H.248.20 does use "-" in the  c = however it is allowed to do this by RFC2327.

Yes, but H.248.1, nor RFC2327, defines the USAGE of "-". It is done in H.248.20.

>So there seems to be some disagreement between the proponents of "-" of whether this is a general mechanism or for 
>specific parameters. I would have thought both media aware and media unaware gateways would be interested in receiving 
>valid SDP.
>
>For H.248.1 v1, v2, v3 implementations which are based on RFC2327 the use of "-" is not supported for the m= line. A 
>subsequent version of H.248.1 could be based on RFC4566 and would then allow the use of "-" in m=. I'm little hesitant in 
>saying "-" can be used in ANY SDP field if it has not been allowed even in RFC4566.

As I said before, H.248.1 already uses values (CHOOSE and ALL) in places NOT supported by RFC2327, so from that perspective I don't see any syntax problem by also allowing "-". I don't even think updating the reference to RFC4566 is going to change that fact. I do, however, agree that adding text about "-" to H.248.1 is considered new functionlity - EVEN if the RFC reference is updated (the new RFC does not specify the USAGE of "-" either).

>In addition the Tispan work could adopt the "application" example as outlined above for media unaware MGs.

I think TISPAN can continue using "-" even in future versions of the Ia profile. We can discuss whether we just add some clarification text to the Ia profile, and/or if we update the SDP reference in Ia from 2327 to 4566. I see no problem in having profiles refering 4566, even if H.248.1 refers 2327, so I don't think the "legalizing" Albrecht is talking about is needed. 

My first choise, however, would still be to update H.248.1, but if we can't agree on that I can live with some compromise.

Regards,

Christer

Regards, Christian

Christer Holmberg (JO/LMF) wrote:

>>>v1.1.1 may not work due to RFC 2327 and H.248.1 (09/2005) baseline 
>>>(in my understanding of the profile specification).
>>>H.248.1 still refers to RFC 2327), and we need to say what a "-" 
>>>value means.
>>>
>>>Regards,
>>>
>>>Christer
>>>
>>>
>>>(It would of course have been good to define the meaning of "-" in 
>>>RFC 4566, in case some other protocol needs it, but it's too late 
>>>now.)
>>>
>>>Regards,
>>>
>>>Christer
>>>
>>>
>>>
>>>* when the H.248 Ia Profile will be based on RFC 4566 is still 
>>>unclear to me ("I guess that first H.248.1 will obsolete RFC 2327 and 
>>>then replace it by RFC 4566, but whether this is a straightforward 
>>>task or not, I don't know. Next step then H.248 profiles ..."),
>>>* 'OMIT' is inline with separating into media-agnostic and 
>>>media-aware IP terminations, and
>>>* '-' would be an extension of the SDP grammar of RFC 2327 based 
>>>H.248 profiles.
>>>
>>>Although you are right these are don't care values, but the point 
>>>here was SDP grammar does not support "-" in the media as shown below.
>>>
>>>>|---------------------------+---------------------------+-----------
>>>>|---------------------------+---------------------------+-----------
>>>>|---------------------------+---------------------------+-----------
>>>>|---------------------------+---------------------------+-----------
>>>>|---------------------------+---------------------------+-----------
>>>>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.
>>>>--------------------------------------------------------------------
>>>>-
>>>>-
>>>>-
>>>>  
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>-
>>>
>>>
>>>   
>>>
>>>      
>>>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 7 Aug 2006 10:41:43 +0200

Hi, 

>[CNG] Isn't the format of m=?:    m=<media> <port> <transport> <fmt list>
>and for <fmt list> "From RFC2327: Formats for non-RTP media should be registered as MIME content types as described in 
>Appendix B."

So, you propose that application/octet-stream is the fmt value? I don't think that "/" and "-" are allowed for fmt in 2327.

fmt = 1*(alpha-numeric)

>If "data" isn't supported then an "application" of  "octet stream" sounds to me a good fit what an media unaware MG is 
>handling.

"Data" is supported - you just need to have a description of it...

>[CNG] At least we agree that H.248.1 isn't the place to do it. The key is the syntax allows it.

I guess we could agree that H.248.1 would be the ideal place to have it (I haven't seen any objection to that), but that it is not possible to add it to the CURRENT version of the spec.

>>>So there seems to be some disagreement between the proponents of "-" 
>>>of whether this is a general mechanism or for specific parameters. I 
>>>would have thought both media aware and media unaFrom [email-masked] Mon Aug 07 09:11:38 2006
Content-class: urn:content-classes:message
Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value	'-'in
	SDP"m=" line
Date: Mon, 7 Aug 2006 10:41:43 +0200
From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
To: "Christian Groves" <[email-masked]>
Cc: [email-masked]

Hi, 

>[CNG] Isn't the format of m=?:    m=<media> <port> <transport> <fmt list>
>and for <fmt list> "From RFC2327: Formats for non-RTP media should be registered as MIME content types as described in 
>Appendix B."

So, you propose that application/octet-stream is the fmt value? I don't think that "/" and "-" are allowed for fmt in 2327.

fmt = 1*(alpha-numeric)

>If "data" isn't supported then an "application" of  "octet stream" sounds to me a good fit what an media unaware MG is 
>handling.

"Data" is supported - you just need to have a description of it...

>[CNG] At least we agree that H.248.1 isn't the place to do it. The key is the syntax allows it.

I guess we could agree that H.248.1 would be the ideal place to have it (I haven't seen any objection to that), but that it is not possible to add it to the CURRENT version of the spec.

>>>So there seems to be some disagreement between the proponents of "-" 
>>>of whether this is a general mechanism or for specific parameters. I 
>>>would have thought both media aware and media unaware gateways would be interested in receiving valid SDP.
>>>
>>>H.248.1 could be based on RFC4566 and would then allow the use of "-" in m=. I'm little hesitant in saying "-" can be 
>>>used in ANY SDP field if it has not been allowed even in RFC4566.
>As I said before, H.248.1 already uses values (CHOOSE and ALL) in places NOT supported by RFC2327, so from that 
>perspective I don't see any syntax problem by also allowing "-". I don't even think updating the reference to RFC4566 is 
>going to change that fact. I do, however, agree that adding text about "-" to H.248.1 is considered new functionlity - 
>EVEN if the RFC reference is updated (the new RFC does not specify the USAGE of "-" either).
>
>  
>
>[CNG] If there's no syntax problem then what happens if a H.248.1 MGC using "-" tries to use it on a MG that doesn't 
>support it? A SDP syntax error results because "-" cannot be present in an RFC2327 in a m= line. 
>If RFC4566 was supported then you wouldn't get the basic syntax error because "-" IS supported in the m=line.

If the MG doesn't understand the "-" it would reject the request anyway - no matter if it's supported by 2327 or not - because it wouldn't know how to process it. It would just use another error code, I guess ("not understood" instead of "wrong syntax"). But, I DO agree it's not a nice solution.

>A further issue is once the value is supported in the syntax to define what the MG is going to do with it....

Yes.

>We can't retrospectively had new syntax to H.248.1 in v1, v2 and v3 because we introduce the above syntax problem.

I can accept that.

>>I think TISPAN can continue using "-" even in future versions of the Ia profile. We can discuss whether we just add some 
>>clarification text to the Ia profile, and/or if we update the SDP reference in Ia from 2327 to 4566. I see no problem in 
>>having profiles refering 4566, even if H.248.1 refers 2327, so I don't think the "legalizing" Albrecht is talking about 
>>is needed. 
>[CNG] Profiles were about enhancing interoperability. Adding things to syntax, do things in a different way to the core 
>specification certainly doesn't assist in those aims.

"-" is already added to the Ia profile. So, no matter if we referer to 4566 or not it's already there.

I don't see any interop problems, because everyone supporting the profile must support the "-" value.

Regards,

Christer

>>To: CHATRAS Bruno ware gateways would be interested in receiving valid SDP.
>>>
>>>H.248.1 could be based on RFC4566 and would then allow the use of "-" in m=. I'm little hesitant in saying "-" can be 
>>>used in ANY SDP field if it has not been allowed even in RFC4566.
>As I said before, H.248.1 already uses values (CHOOSE and ALL) in places NOT supported by RFC2327, so from that 
>perspective I don't see any syntax problem by also allowing "-". I don't even think updating the reference to RFC4566 is 
>going to change that fact. I do, however, agree that adding text about "-" to H.248.1 is considered new functionlity - 
>EVEN if the RFC reference is updated (the new RFC does not specify the USAGE of "-" either).
>
>  
>
>[CNG] If there's no syntax problem then what happens if a H.248.1 MGC using "-" tries to use it on a MG that doesn't 
>support it? A SDP syntax error results because "-" cannot be present in an RFC2327 in a m= line. 
>If RFC4566 was supported then you wouldn't get the basic syntax error because "-" IS supported in the m=line.

If the MG doesn't understand the "-" it would reject the request anyway - no matter if it's supported by 2327 or not - because it wouldn't know how to process it. It would just use another error code, I guess ("not understood" instead of "wrong syntax"). But, I DO agree it's not a nice solution.

>A further issue is once the value is supported in the syntax to define what the MG is going to do with it....

Yes.

>We can't retrospectively had new syntax to H.248.1 in v1, v2 and v3 because we introduce the above syntax problem.

I can accept that.

>>I think TISPAN can continue using "-" even in future versions of the Ia profile. We can discuss whether we just add some 
>>clarification text to the Ia profile, and/or if we update the SDP reference in Ia from 2327 to 4566. I see no problem in 
>>having profiles refering 4566, even if H.248.1 refers 2327, so I don't think the "legalizing" Albrecht is talking about 
>>is needed. 
>[CNG] Profiles were about enhancing interoperability. Adding things to syntax, do things in a different way to the core 
>specification certainly doesn't assist in those aims.

"-" is already added to the Ia profile. So, no matter if we referer to 4566 or not it's already there.

I don't see any interop problems, because everyone supporting the profile must support the "-" value.

Regards,

Christer

>>>>it's a syntax issue. An implementatRD-CORE-ISS
>>>>I do accept all your arguments in favour for '-', i.e. I won't 
>>>>submit a CR for 'OMIT'.
>>>>I will draft something to be included in the next IG.  Even though 
>>>>we are talking about something syntactical in nature, the syntax is 
>>>>that of SDP and not H.248.  It also appears that there is a common 
>>>ion following strictly ES 283 018
>>>>I do accept all your arguments in favour for '-', i.e. I won't 
>>>>submit a CR for 'OMIT'.
>>>>I will draft something to be included in the next IG.  Even though 
>>>>we are talking about something syntactical in nature, the syntax is 
>>>>that of SDP and not H.248.  It also appears that there is a common 
>>>>Envoyé : jeudi 20 juillet 2006 20:46 À : [email-masked] 
>>>>Cc : [email-masked] Objet : RE: [Megaco] ETSI H.248 Ia Profile: 
>>>>issue with media value '-'in SDP"m=" line
>>>>
>>>>
>>>>Hi,
>>>>
>>>>unclear to me ("I guess that first H.248.1 will obsolete RFC 2327 
>>>>and then replace it by RFC 4566, but whether this is a 
>>>>straightforward task or not, I don't know. Next step then H.248 
>>>>profiles ..."),
>>>>Envoyé : jeudi 20 juillet 2006 20:46 À : [email-masked] 
>>>>Cc : [email-masked] Objet : RE: [Megaco] ETSI H.248 Ia Profile: 
>>>>issue with media value '-'in SDP"m=" line
>>>>
>>>>
>>>>Hi,
>>>>
>>>>unclear to me ("I guess that first H.248.1 will obsolete RFC 2327 
>>>>and then replace it by RFC 4566, but whether this is a 
>>>>straightforward task or not, I don't know. Next step then H.248 
>>>>profiles ..."),
>>>>therefore the string "OMIT" was suggested for the media, so as not 
>>>>to violate the SDP grammar.
>>>>
>>>>
>>>>regards
>>>>B Venkat S.R Swamy
>>>>Senior Technical Leader
>>>>"NOTE - "-" indicates "do not care" - i.e. the field should be set 
>>>>to any value valid according to SDP, but it is not used on the CBC interface."
>>>>
>>>>therefore the string "OMIT" was suggested for the media, so as not 
>>>>to violate the SDP grammar.
>>>>
>>>>
>>>>regards
>>>>B Venkat S.R Swamy
>>>>Senior Technical Leader
>>>>"NOTE - "-" indicates "do not care" - i.e. the field should be set 
>>>>to any value valid according to SDP, but it is not used on the CBC interface."
>>>>
>>>>>Sen 
>>>>>                                ior Technical Leader
>>>>>(1) ETSI ES 283 018 is extending the SDP codepoint space, leading 
>>>>>to further differences between H.248/SDP and SIP/SDP, with further 
>>>>>5.15     Mandatory support of SDP and ann       issue with media value '-'
>>>>> 
>>>>>
>>>>>    
>>>>>
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>>in
>>>>
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>>>                                       SDP"m=" line
>>>>> 
>>>>>
>>>>>    
>>>>>
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>>>(1) ETSI ES 283 018 is extending the SDP codepoint space, leading 
>>>>>to further differences between H.248/SDP and SIP/SDP, with further 
>>>>>|---------------------------+---------------------------+----------
>>>>>|---------------------------+---------------------------+----------
>>>>>|---------------------------+---------------------------+----------
>>>>>|---------------------------+---------------------------+----------
>>>>>| Media   ex C information elements
>>>>>
>>>>>
>>>>>
>>>>>|---------------------------+---------------------------+----------
>>>>>|---------------------------+---------------------------+----------
>>>>>|---------------------------+---------------------------+----------
>>>>>|---------------------------+---------------------------+----------
>>>>>|---------------------------+---------------------------+----------
>>>>>confidential information and should not b                  | Mandatory                 |"-" may be
>>>>> 
>>>>>
>>>>>    
>>>>>
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>>used
>>>>
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>>>for the media|
>>>>>|---------------------------+---------------------------+----------
>>>>>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. FSS accepts no 
>>>>>responsibility for loss or damage arising from the use of the 
>>>>>information transmitted by this email including damage from virus."
>>>>damage arising from the use of the informatione 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. FSS accepts no 
>>>>>responsibility for loss or damage arising from the use of the 
>>>>>information transmitted by this email including damage from virus."

---

From: Christian Groves <[email-masked]>
Date: Mon, 07 Aug 2006 17:45:12 +1000

>>>> =20
>>>>    =20
>>>>       =20
>>>  =20
>>>     =20
>>=20
>>   =20
> =20

---

From: Christian Groves <[email-masked]>
Date: Mon, 07 Aug 2006 17:45:12 +1000

Hello Christer,

Please see my response below [CNG].

Cheers, Christian

[CNG] Isn't the format of m=?:    m=<media> <port> <transport> <fmt list>
and for <fmt list> "From RFC2327: Formats for non-RTP media should be 
registered as MIME content types as described in Appendix B."
If "data" isn't supported then an "application" of  "octet stream" 
sounds to me a good fit what an media unaware MG is handling.

>Yes, but H.248.1, nor RFC2327, defines the USAGE of "-". It is done in H.248.20.
[CNG] At least we agree that H.248.1 isn't the place to do it. The key 
is the syntax allows it.

>As I said before, H.248.1 already uses values (CHOOSE and ALL) in places NOT supported by RFC2327, so from that perspective I don't see any syntax problem by also allowing "-". I don't even think up…
[CNG] If there's no syntax problem then what happens if a H.248.1 MGC 
using "-" tries to use it on a MG that doesn't support it? A SDP syntax 
error results because "-" cannot be present in an RFC2327 in a m= line. 
If RFC4566 was supported then you wouldn't get the basic syntax error 
because "-" IS supported in the m=line.

A further issue is once the value is supported in the syntax to define 
what the MG is going to do with it....

We can't retrospectively had new syntax to H.248.1 in v1, v2 and v3 
because we introduce the above syntax problem.

>I think TISPAN can continue using "-" even in future versions of the Ia profile. We can discuss whether we just add some clarification text to the Ia profile, and/or if we update the SDP reference i…
[CNG] Profiles were about enhancing interoperability. Adding things to 
syntax, do things in a different way to the core specification certainly 
doesn't assist in those aims.

>>But, if you use "data", wouldn't you expect something specific in the [email-masked]?subject=subscribe>
Errors-To: [email-masked]

Hello Christer,

Please see my response below [CNG].

Cheers, Christian

[CNG] Isn't the format of m=?:    m=<media> <port> <transport> <fmt list>
and for <fmt list> "From RFC2327: Formats for non-RTP media should be 
registered as MIME content types as described in Appendix B."
If "data" isn't supported then an "application" of  "octet stream" 
sounds to me a good fit what an media unaware MG is handling.

>Yes, but H.248.1, nor RFC2327, defines the USAGE of "-". It is done in H.248.20.
[CNG] At least we agree that H.248.1 isn't the place to do it. The key 
is the syntax allows it.

>As I said before, H.248.1 already uses values (CHOOSE and ALL) in places NOT supported by RFC2327, so from that perspective I don't see any syntax problem by also allowing "-". I don't even think up…
[CNG] If there's no syntax problem then what happens if a H.248.1 MGC 
using "-" tries to use it on a MG that doesn't support it? A SDP syntax 
error results because "-" cannot be present in an RFC2327 in a m= line. 
If RFC4566 was supported then you wouldn't get the basic syntax error 
because "-" IS supported in the m=line.

A further issue is once the value is supported in the syntax to define 
what the MG is going to do with it....

We can't retrospectively had new syntax to H.248.1 in v1, v2 and v3 
because we introduce the above syntax problem.

>I think TISPAN can continue using "-" even in future versions of the Ia profile. We can discuss whether we just add some clarification text to the Ia profile, and/or if we update the SDP reference i…
[CNG] Profiles were about enhancing interoperability. Adding things to 
syntax, do things in a different way to the core specification certainly 
doesn't assist in those aims.

>>>a) Does "-" mean the MGC doesn't care and return "-" in tmt field? Remember that Ia uses "-" in the fmt field also, because Ia simply doesn't care.
>>
>>>>'-'in SDP"m=" lhe command reply?
>>ine
>>>>>  digits.  An exception is>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>Hi,
>>>>
>>> the "/" character used in the value
>>>>>|---------      
>>>>>media  ------------------+---------------------------+-----------
>>>_______________________________________________>---------------------------------------------------------------------
>>>>-
>>>>-
>>>>-
>>>>
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>>> 
>>>>>
>>>>>    
>>>>>
>>>>>       
>>>>>
>>>>>          
>>>>>

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 15 Aug 2006 13:14:41 -0400

It appears to me that we have another item for the "v4" list.  The
updating of the reference from 2327 to 4566 is going to require a number
of changes throughout H.248.1.  Now, we might be able to start work on
just that so that the pain is lessened later on, and if we find that the
changes turn out to be relatively small, then maybe we can issue an
amendment to the v3 spec... or maybe not -- it all depends on what will
have to change.

We were smart enough (well, not me, but the original folks drafting the
text lo these many years ago) to keep the encoding from becoming a
fully-incorporated portion of the ABNF, so updates to the SDP syntax do
NOT affect text encoding.  Binary is a little different story, since the
SDP is not carried through as binary-encoded text.  This is where I
foresee the syntax issues to appear.

Kevin

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Monday, August 07, 2006 3:45 AM
To: Christer Holmberg (JO/LMF)
Cc: [email-masked]
Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value
'-'in SDP"m=" line

Hello Christer,

Cheers, Christian

>Anyway, I think "data" would fit better than "application".
[CNG] Isn't the format of m=?:    m=<media> <port> <transport> <fmt
list>

by RFC2327.

>>H.248.1 could be based on RFC4566 and would then allow the use of "-"
in m=. I'm little hesitant in saying "-" can be used in ANY SDP field if
it has not been allowed even in RFC4566.
>>    
>>
>
>As I said before, H.248.1 already uses values (CHOOSE and ALL) in
places NOT supported by RFC2327, so from that perspective I don't see
any syntax problem by also allowing "-". I don't even think updating the
reference to RFC4566 is going to change that fact. I do, however, agree
that adding text about "-" to H.248.1 is considered new functionlity -
EVEN if the RFC reference is updated (the new RFC does not specify the
USAGE of "-" either).

>>    
>>
>
>I think TISPAN can continue using "-" even in future versions of the Ia
profile. We can discuss whether we just add some clarification text to
the Ia profile, and/or if we update the SDP reference in Ia from 2327 to
4566. I see no problem in having profiles refering 4566, even if H.248.1
refers 2327, so I don't think the "legalizing" Albrecht is talking about
is needed. 

>My first choise, however, would still be to update H.248.1, but if we
can't agree on that I can live with some compromise.
>>First, "data" has been removed from RFC4566 (new SDP RFC), due to
"unclear usage". It can still be used, though, so I don't think that is
a major issue. I even think there are use-cases where "data" is needed,
but that is a separate discussion.
>>
>>But, if you use "data", wouldn't you expect something specific in the
fmt field? Remember that Ia uses "-" in the fmt field also, because Ia
simply doesn't care.
"don't care".
recommendation. But, in the H.248.20 case we don't have the problem that
the receiver sometimes shall care, and in other cases it doesn't need to
care. But, again, in Ia we will have that problem once/if media
awareness is added to the profile.
>>
>>So, I think it would be good if H.248.1 said that "-" can be used in
ALL SDP parameter fields, because in future we may find other places
where it may be needed.
>>>
>>>The Binary case is different. If SDP fields are represented by
dedicated tags (e.g. Media/1001), then the MGC can simply omit the
parameters that are meaningless. If the SDP equivalent (e.g. SDP_M) are
used then the "-" convention shall also be used in the valeu field of
the TLV parameter.
>>>As Bruno also said, in future the Ia profile may become media aware,
so we can't just say that "-" means that you can send whatever you want
since the receiver doesn't care about the value. We will need a
dedicated "do not care" value, so that the receiver knows whether it
should care or not.
>>>I'm not really comfortable with this being added via the way of the
implementors guide (e.g. I don't support this). In an earlier email
Bruno had concerns other the ability of ability of previous Ia
implementations to accept a CR on this. I think we strike the same (if
not bigger) problem if we simply state "-" is supported. I would assume
there are a lot more H.248.1 implementations than Ia implementations out
there. If we added this we would be introducing a possible error to a
greater set of implementations.
>>>Now H.248 requires that fully compliant SDP be returned in the
command response. So what does this text really mean?
>>>If its a) then its definately not an implementor's guide change. As
now we have to change things in command requests and responses. Do we
also need to add this "don't care" to all properties. e.g. for the
ASN.1?
probably lost in translation (e.g. a derivitive of the Q.1950 text) then
"-" is never sent and this can be fixed in the Ia profile which
introduced this problem.

>>>>                   \(JO/LMF\)"                   To:      "Kevin
Boyle" <[email-masked]>, "CHATRAS Bruno RD-CORE-ISS"

>>>>                                                 Subject: RE:
[Megaco] ETSI H.248 Ia Profile: issue with media value '-'in  SDP"m="
line  

>>>>>|                           |                           |The
address
>>>>>|                           |                           |be "IP4"
or
>>>>>|                           |                           |The
connection
>>>>>|                           |                           |The port
value
>>>>>|                           |
|underspecified
>>>>>|                           |                           |is
required by
>>>>>|                           |                           | "-" may
be
>>>>>|                           |                           | format
list
>>>>>|                           |                           | values
shall

---

From: [email-masked]
Date: Wed, 16 Aug 2006 13:25:25 +0200

fyi,
we've prepared a contribution for the Ottawa meeting, providing an initial
cross-check and correspondent change proposals for H.248.1.

One worthwhile conclusion could be, to allow syntactical/sematical SDP
extensions if required by H.248 packages/profiles, under the condition,
that such extensions will not require changes of the "formal specification
rules" of the underlying SDP grammar. That means, the basic ABNF grammar
behind SDP (RFC 2327 or RFC 4566; complemented by § 7.1.8/h.248.1 SDP
rules) will not be changed in such situations.

Such a proceeding would allow to keep at least the SDP encoder/decoder
(parser) unchanged in the H.248 "core protocol stack". (Note: I know that
this is an implementation specific item, but I'm sure, the experts familiar
with protocol stack implementations know what I mean.)

- Albrecht

                      "Kevin Boyle"                                                                                                  
                      <[email-masked]         To:      "Christian Groves" <[email-masked]>, "Christer Holmberg       
                      om>                      \(JO/LMF\)" <[email-masked]>                                          
                                               cc:      [email-masked]                                                              
                      15.08.2006 19:14         Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value  '-'in SDP"m="    
                                               line                                                                                  

Kevin

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Monday, August 07, 2006 3:45 AM
To: Christer Holmberg (JO/LMF)
Cc: [email-masked]
Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value
'-'in SDP"m=" line

Hello Christer,

Cheers, Christian

by RFC2327.

"don't care".

>>>>We will submitt a correspondent CR to next TISPAN meeting.
Boyle"
>>>>[Megaco] ETSI H.248 Ia Profile: issue with media  value '-'inSDP"m="
line
'-'

---

From: [email-masked]
Date: Wed, 16 Aug 2006 09:58:18 +0200

fyi,

- Albrecht

                      "Kevin Boyle"                                                                                                  

Kevin

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Monday, August 07, 2006 3:45 AM
To: Christer Holmberg (JO/LMF)
Cc: [email-masked]
Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value
'-'in SDP"m=" line

Hello Christer,

Cheers, Christian

by RFC2327.

"don't care".

Boyle"
'-'

address
or
connection
value
|underspecified
required by
be
list
shall