From megaco-bounces@ietf.org Tue Aug 01 00:10:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7laa-0002IJ-JS; Tue, 01 Aug 2006 00:10:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7laZ-0002I3-M2 for megaco@ietf.org; Tue, 01 Aug 2006 00:10:39 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17] helo=jaguar.hss.hns.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7laV-0005m2-VH for megaco@ietf.org; Tue, 01 Aug 2006 00:10:39 -0400 Received: from jaguar.hss.hns.com (localhost [127.0.0.1]) by jaguar.hss.hns.com (8.13.6/8.12.10) with ESMTP id k714C47l014632 for ; Tue, 1 Aug 2006 09:42:04 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by jaguar.hss.hns.com (8.13.6/8.13.6) with ESMTP id k714Bwr5014598; Tue, 1 Aug 2006 09:41:59 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id k714BB424001; Tue, 1 Aug 2006 09:41:11 +0530 (IST) In-Reply-To: <31F31018FE2DC941A70BD30477510B0C0B44FB27@biscm02.cn001.siemens.net> Subject: Re: [Megaco] RE:Add Command To: "Liu Ti,SLC Com FN RDC NA(BJ)" X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: "B Venkat S.R Swamy" Date: Tue, 1 Aug 2006 09:43:21 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 01/08/2006 09:40:17 AM MIME-Version: 1.0 X-Spam-Score: 1.7 (+) X-Scan-Signature: 9d7e8d783239e9f0c425c823a9c950ff Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0544160053==" Errors-To: megaco-bounces@ietf.org --===============0544160053== Content-type: multipart/related; Boundary="0__=EABBFB2EDF858C618f9e8a93df938690918cEABBFB2EDF858C61" Content-Disposition: inline --0__=EABBFB2EDF858C618f9e8a93df938690918cEABBFB2EDF858C61 Content-type: text/html; charset=ISO-2022-JP Content-Disposition: inline Content-transfer-encoding: quoted-printable

Hi

A ADD command without descriptor is definately valid as per the protoco= l, but in most real scenarios
descriptors are always there. MG should add the termination into the g= iven context and
return successfull Add Reply. For Ephemeral termination however I guess= , Media descriptor should
always be present, so that appropriate IP/ATM interface can be associat= ed at the time of ADD.

MGC can subsequently modify the termination properties or apply signals= or events through MODIFY
command. But this would result in unnecessary messaging between MG and= MGC and a proper design
implementation should ensure minimal messaging between MG and MGC.


regards
B Venkat S.R Swamy
Senior Technical Leader
Flextronics Software Systems
Phone: +91-124- 4176213
Fax: +91-124-4300247
web: www.flextronicssoftware.com
3D"Inactive"Liu Ti,SLC Com = FN RDC NA(BJ)" <ti.liu@siemens.com>


=
          "Liu Ti,SLC Com FN RDC NA(BJ)" <ti= .liu@siemens.com>

          08/01/2006 08:53 AM

 =
3D""
To
3D""
megaco@ietf.org
3D""
cc
3D""
3D""
Subject
3D""
[Megaco] RE:Add Command
=3D""3D""<= /td>

Hi all:

To this ADD Command question, I find an explanation from http://quimby.gnus.org/internet-drafts/draft-rosen-me= gaco-interop-1-report-00.txt  no 6：

 An MG should always accept a command which has no descriptors, <= br>  assuming that the contextId and the terminationIds are legal. &n= bsp;
 It's a NOP, but it's legal.

What is your opinion on this?

If this is a NOP, then whether the termination should be added to the c= ontext or just ignore it. What kind of reply should the MG return to MG= C when it receives an ADD command without a descriptior.

B.R.
Liu Ti

-----Original Message-----
From: megaco-request@ietf.org [mailto:megaco-request@ietf.org]
Sent: Friday, July 28, 2006 12:00 AM
To: megaco@ietf.org
Subject: Megaco Digest, Vol 27, Issue 35


Send Megaco mailing list submissions to
megaco@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
h= ttps://www1.ietf.org/mailman/listinfo/megaco
or, via email, send a message with subject or body 'help' to
megaco-request@ietf.org

You can reach the person managing the list at
megaco-owner@ietf.org

When replying, please edit your Subject line so it is more specific tha= n "Re: Contents of Megaco digest..."


Today's Topics:

  1. Re: Error format (Ashish Singh)
  2. RE: Error format (Wainwright, John (Com US))
  3. Re: Error format (Ashish Singh)
  4. Add Command (Liu Ti,SLC Com FN RDC NA(BJ))


----------------------------------------------------------------------<= br>
Message: 1
Date: Wed, 26 Jul 2006 09:36:07 -0700
From: Ashish Singh <ashishs@redback.com>
Subject: Re: [Megaco] Error format
To: "Wainwright, John (Com US)" <john.wainwright@siemens.c= om>
Cc: megaco@ietf.org
Message-ID: <44C799F7.2010305@redback.com>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed

Hi John,

The response is correct from syntax point of view. But H.248.8 mentions=
to include "stream ID" as Error text for this particular erro= r code.

There are many other error codes, for which extra information is
required. Like with error codes 433 and 435, contextID is returned, so =
that MGC can synchronize its database.

Thanks
Ashish


Wainwright, John (Com US) wrote:
> Is the following format 'valid' for a response to an ADD request > containing an unsupported codec in the Local descriptor?  Wou= ld the
> same format apply, apart from the error code and text, for any oth= er
> type of error in the SDP data within the Local descriptor ?
>  
> MEGACO/2 [20.0.4.32]:2084
> REPLY =3D 269820167 {
>   CONTEXT =3D 13 {
>     ADD =3D port_1
>   ,
>     ADD =3D eph/00337 {
>           ERROR =3D 515 {"Unsupporte= d Media Type"}
>     }
>   }
> }
>  
> Thanks
> John
>  
> ------------------------------------------------------------------= ----
> --
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>  




------------------------------

Message: 2
Date: Wed, 26 Jul 2006 11:44:47 -0700
From: "Wainwright, John \(Com US\)" <john.wainwright@sieme= ns.com>
Subject: RE: [Megaco] Error format
To: "Ashish Singh" <ashishs@redback.com>
Cc: megaco@ietf.org
Message-ID:
<B8F190056D7DF44998303AEFEC3BE1140820DF7E@USNWK100MSX.ww017.sieme= ns.net>

Content-Type: text/plain; charset=3D"us-ascii"

So would a more accurate response have something like the following
= ERROR =3D 515 {"Unsupported Media Type.  Stream =3D xxx&qu= ot;

If "Stream =3D 1" can it be omitted and assumed by default ?<= br>
Thanks
John


-----Original Message-----
From: Ashish Singh [mailto:ashis= hs@redback.com]
Sent: Wednesday, July 26, 2006 11:36 AM
To: Wainwright, John (Com US)
Cc: megaco@ietf.org
Subject: Re: [Megaco] Error format

Hi John,

The response is correct from syntax point of view. But H.248.8 mentions=
to include "stream ID" as Error text for this particular erro= r code.

There are many other error codes, for which extra information is
required. Like with error codes 433 and 435, contextID is returned, so =
that MGC can synchronize its database.

Thanks
Ashish


Wainwright, John (Com US) wrote:
> Is the following format 'valid' for a response to an ADD request > containing an unsupported codec in the Local descriptor?  Wou= ld the
> same format apply, apart from the error code and text, for any oth= er
> type of error in the SDP data within the Local descriptor ?
>  
> MEGACO/2 [20.0.4.32]:2084
> REPLY =3D 269820167 {
>   CONTEXT =3D 13 {
>     ADD =3D port_1
>   ,
>     ADD =3D eph/00337 {
>           ERROR =3D 515 {"Unsupporte= d Media Type"}
>     }
>   }
> }
>  
> Thanks
> John
>  
>
-----------------------------------------------------------------------= -
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>  




------------------------------

Message: 3
Date: Wed, 26 Jul 2006 11:55:11 -0700
From: Ashish Singh <ashishs@redback.com>
Subject: Re: [Megaco] Error format
To: "Wainwright, John (Com US)" <john.wainwright@siemens.c= om>
Cc: megaco@ietf.org
Message-ID: <44C7BA8F.4080202@redback.com>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed

I guess it will be easier for MGC to parse, if we only include
"streamID" and no other text. IMO, error descriptor should lo= ok like:

ERROR =3D 515 {"xxx"}

Thanks
Ashish


Wainwright, John (Com US) wrote:
> So would a more accurate response have something like the followin= g
> ERROR =3D 515 {"Unsupported Media Type.  Stream =3D x= xx"
>
> If "Stream =3D 1" can it be omitted and assumed by defau= lt ?
>
> Thanks
> John
>
>
> -----Original Message-----
> From: Ashish Singh [mailto:= ashishs@redback.com]
> Sent: Wednesday, July 26, 2006 11:36 AM
> To: Wainwright, John (Com US)
> Cc: megaco@ietf.org
> Subject: Re: [Megaco] Error format
>
> Hi John,
>
> The response is correct from syntax point of view. But H.248.8 > mentions
> to include "stream ID" as Error text for this particular= error code.
>
> There are many other error codes, for which extra information is > required. Like with error codes 433 and 435, contextID is returned= , so
> that MGC can synchronize its database.
>
> Thanks
> Ashish
>
>
> Wainwright, John (Com US) wrote:
>  
>> Is the following format 'valid' for a response to an ADD reque= st
>> containing an unsupported codec in the Local descriptor?  = ;Would the
>> same format apply, apart from the error code and text, for any= other
>> type of error in the SDP data within the Local descriptor ? >>  
>> MEGACO/2 [20.0.4.32]:2084
>> REPLY =3D 269820167 {
>>   CONTEXT =3D 13 {
>>     ADD =3D port_1
>>   ,
>>     ADD =3D eph/00337 {
>>           ERROR =3D 515 {"Unsupp= orted Media Type"}
>>     }
>>   }
>> }
>>  
>> Thanks
>> John
>>  
>>
>>    
> ------------------------------------------------------------------= ----
> --
>  
>> _______________________________________________
>> Megaco mailing list
>> Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco<= /tt>
>>  
>>    
>
>
>  




------------------------------

Message: 4
Date: Wed, 26 Jul 2006 16:29:41 +0800
From: "Liu Ti,SLC Com FN RDC NA(BJ)" <ti.liu@siemens.com&g= t;
Subject: [Megaco] Add Command
To: megaco@ietf.org, megaco@DOMAIN.HIDDEN
Message-ID:
<31F31018FE2DC941A70BD30477510B0C0B2579B5@biscm02.cn001.siemens.n= et>
Content-Type: text/plain; charset=3D"us-ascii"

Hi All:

Does there exist such situation:
1 An Add Command does not have any descriptor as parameters.
2 An Add command,used to create a Termination, does not have any descri= ptor as parameters.

Thanks in advance.

B.R
Ti



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www1.ietf.org/pipermail/m= egaco/attachments/20060726/8e22cac4/attachment.html

------------------------------

_______________________________________________
Megaco mailing list
Megaco@ietf.org
http= s://www1.ietf.org/mailman/listinfo/megaco


End of Megaco Digest, Vol 27, Issue 35
**************************************

_______________________________________________
Megaco mailing list
Megaco@ietf.org
http= s://www1.ietf.org/mailman/listinfo/megaco



*********************** FSS-Restricted ***********************
"DISCLAIMER: This message is proprietary to Flextronics Software <= br> 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."= --0__=EABBFB2EDF858C618f9e8a93df938690918cEABBFB2EDF858C61 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <00__=EABBFB2EDF858C61@flextronicssoftware.com> Content-transfer-encoding: base64 R0lGODlhEAAQAPcAAAAAAL8AAAC/AL+/AAAAv78AvwC/v8DAwICAgP8AAAD/AP//AAAA//8A/wD/ /////wCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAA8ALAAAAAAQABAA QAgtAB8IHEiwoMEHBxIeOIhQoUOHDCNKnPhQ4cSLGDNqNFgR4sGKFxNuHEmSYEAAADs= --0__=EABBFB2EDF858C618f9e8a93df938690918cEABBFB2EDF858C61 Content-type: image/gif; name="pic02351.gif" Content-Disposition: inline; filename="pic02351.gif" Content-ID: <10__=EABBFB2EDF858C61@flextronicssoftware.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=EABBFB2EDF858C618f9e8a93df938690918cEABBFB2EDF858C61 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=EABBFB2EDF858C61@flextronicssoftware.com> Content-transfer-encoding: base64 R0lGODlhEAABAPcAAAAAAL8AAAC/AL+/AAAAv78AvwC/v8DAwICAgP8AAAD/AP//AAAA//8A/wD/ /////wCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAA8ALAAAAAAQAAEA QAgKAB8IHEiw4IOAAAA7 --0__=EABBFB2EDF858C618f9e8a93df938690918cEABBFB2EDF858C61-- --===============0544160053== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0544160053==-- From megaco-bounces@ietf.org Tue Aug 01 10:03:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7uqU-0001aC-LD; Tue, 01 Aug 2006 10:03:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7uqT-0001XL-Fe for megaco@ietf.org; Tue, 01 Aug 2006 10:03:41 -0400 Received: from web54209.mail.yahoo.com ([206.190.39.251]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7uqS-0005Ye-5r for megaco@ietf.org; Tue, 01 Aug 2006 10:03:41 -0400 Received: (qmail 66170 invoked by uid 60001); 1 Aug 2006 14:03:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.hk; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=iWqNynFkl7SgP1Kx0CLwUOXOuQwwrSxMyVudwKt7vrK+rJhm3jMFPaxVeUZZKxhGVGa3tRu3d4b3j22WDanyOzQu45OpGoBTB5iwaS6QANonJ99KADdvYytOl+gL2p3E59JsXoXAPi9dAlHYvRb4X1PUJzB4XdNlHbiZw2NphII= ; Message-ID: <20060801140340.66168.qmail@web54209.mail.yahoo.com> Received: from [194.237.142.21] by web54209.mail.yahoo.com via HTTP; Tue, 01 Aug 2006 22:03:39 CST Date: Tue, 1 Aug 2006 22:03:39 +0800 (CST) From: Tonny Kung To: megaco@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [Megaco] Wildcarded AuditValue X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mail2tonny-megaco@yahoo.com.hk List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1851979833==" Errors-To: megaco-bounces@ietf.org --===============1851979833== Content-Type: multipart/alternative; boundary="0-802089961-1154441019=:65764" Content-Transfer-Encoding: 8bit --0-802089961-1154441019=:65764 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 8bit Hi, I just want to check that the wildcarded AuditValue request is valid for ALL descriptors, including the TerminationStateDescriptor, is that correct? So the following request: Context = * { OW-AuditValue = pra/n/n/* { Audit { Media { Termination state { ServiceStates } } } } } } will give the following reply: 1) if all channel are in-service Reply = 1003 { Context = - { AuditValue = pra/n/n/* { Media { TerminationState { ServiceStates = InService } } } } } 2) if some are in-service and some out-of-service Reply = 1003 { Context = - { AuditValue = pra/n/n/* { Media { TerminationState { ServiceStates = InService } }, Media { TerminationState { ServiceStates = OutOfService } } } } } Best Regards, Tonny _______________________________________ YM - Â÷½u°T®§ ´Nºâ§A¨S¦³¤Wºô¡A§AªºªB¤Í¤´¥i¥H¯d¤U°T®§µ¹§A¡A·í§A¤Wºô®É´N¯à¥ß§Y¬Ý¨ì¡A¥ô¦ó»¡¸Ü³£ÉN¨«¥¢¡C http://messenger.yahoo.com.hk --0-802089961-1154441019=:65764 Content-Type: text/html; charset=big5 Content-Transfer-Encoding: 8bit Hi,

I just want to check that the wildcarded AuditValue request is valid for ALL descriptors, including the TerminationStateDescriptor, is that correct?

So the following request:

  Context = * {
      OW-AuditValue = pra/n/n/* {
            Audit {
              Media {
               Termination state {
                 ServiceStates } } } } } }

will give the following reply:

1) if all channel are in-service
Reply = 1003 {
  Context = - {
      AuditValue = pra/n/n/* {
         Media {
            TerminationState {
               ServiceStates = InService
            } } } } }

2) if some are in-service and some out-of-service
Reply = 1003 {
  Context = - {
      AuditValue = pra/n/n/* {
         Media {
            TerminationState {
               ServiceStates = InService
            } },
         Media {
            TerminationState {
               ServiceStates = OutOfService
            } } } } }


Best Regards,
Tonny

_______________________________________
YM - Â÷½u°T®§
´Nºâ§A¨S¦³¤Wºô¡A§AªºªB¤Í¤´¥i¥H¯d¤U°T®§µ¹§A¡A·í§A¤Wºô®É´N¯à¥ß§Y¬Ý¨ì¡A¥ô¦ó»¡¸Ü³£ÉN¨«¥¢¡C
http://messenger.yahoo.com.hk --0-802089961-1154441019=:65764-- --===============1851979833== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1851979833==-- From megaco-bounces@ietf.org Tue Aug 01 13:43:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7yGk-0003l5-Rq; Tue, 01 Aug 2006 13:43:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7yGj-0003kF-6O for Megaco@ietf.org; Tue, 01 Aug 2006 13:43:01 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7yGh-0007t4-RW for Megaco@ietf.org; Tue, 01 Aug 2006 13:43:01 -0400 Received: by ug-out-1314.google.com with SMTP id m2so1498791uge for ; Tue, 01 Aug 2006 10:42:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=EzskaZ8XFCdPXSaMrc8XPmQKNgGZyIEYjE17mwh4kDaQZFWmN5bSyga9XEVlcc+92QO3xj+bQV80fXTaHTSvZXjjMe7HtvVbnmK0XeA1UgbJ3065Qn3HYkOhjtSIj2MVZFbzd6I9MzEnMR4qhc0YRA95laF3zGuHYKBSIHLVTEE= Received: by 10.67.119.13 with SMTP id w13mr1307892ugm; Tue, 01 Aug 2006 10:42:58 -0700 (PDT) Received: by 10.66.250.10 with HTTP; Tue, 1 Aug 2006 10:42:58 -0700 (PDT) Message-ID: <1a9ac220608011042k7c5f05a7s9b64b938cd7e6df1@mail.gmail.com> Date: Tue, 1 Aug 2006 14:42:58 -0300 From: "Nicolas Emiliani" To: Megaco@ietf.org MIME-Version: 1.0 X-Spam-Score: 2.0 (++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Subject: [Megaco] Notify reply issue. X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0267276915==" Errors-To: megaco-bounces@ietf.org --===============0267276915== Content-Type: multipart/alternative; boundary="----=_Part_80786_14804143.1154454178881" ------=_Part_80786_14804143.1154454178881 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi list! Well, I have an issue with the reply to a notify command that comes from the MG. Basically I'm receiving this message : MEGACO/1 [192.168.0.206]:2944 T=17201{ C = 2 { O-N=TGW206/PDC1/2{ OE=1235{ 19700101T00015312 : ct/cmp{ res=Success}}}}}\000 So as u see I have an O-N, in the RFC it says O- means that it's a command request list for which I don't understand the use, cause there is only one command (the notify). Anyways, this is what I'm answering as the MGC: MEGACO/1 [192.168.0.187]:2948 Reply=17201{ Context=2{O-Notify=TGW206/PDC1/2}} TransactionResponseAck{3} What happens next is that the MG starts retransmitting the Notify command cause it doesn't like my reply. The board I'm using is a trunk gateway from Audicodes. The guys from audoicodes say that my reply is not valid cause O-Notify is not a legal response. I'm really not sure about that, so what I'm asking is if my answer is ok or not. Should it be "... Context=2{Notify=TGW206/PDC1/2}... " instead? shouldn't the TGW be sending a syntax error instead of retransmitting as if the had no reply? If anyone could send me an expample of use of the "O-" thing I wpould appreciate it since I don't fully understand it's use and I can't find any expamples about it. Thanks! Nico ------=_Part_80786_14804143.1154454178881 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi list!
Well, I have an issue with the reply to a notify command that comes from the MG. Basically I'm receiving this message :

   MEGACO/1 [192.168.0.206]:2944
    T=17201{
    C = 2 {
    O-N=TGW206/PDC1/2{
    OE=1235{
    19700101T00015312 : ct/cmp{
    res=Success}}}}}\000

So as u see I have an O-N, in the RFC it says O- means that it's a command request list for which I  don't understand the use, cause there is only one command (the notify). Anyways, this is what I'm answering as the MGC:

MEGACO/1 [192.168.0.187]:2948
Reply=17201{
Context=2{O-Notify=TGW206/PDC1/2}}
TransactionResponseAck{3}

What happens next is that the MG starts retransmitting the Notify command cause it doesn't like my reply. The board I'm using is a trunk gateway from Audicodes. The guys from audoicodes say that my reply is not valid cause O-Notify is not  a legal response. I'm really not sure about that, so what I'm asking is if my answer is ok or not. Should it be "... Context=2{Notify=TGW206/PDC1/2}... " instead?

shouldn't the TGW be sending a syntax error instead of retransmitting as if the had no reply?

If anyone could send me an expample of use of the "O-" thing I wpould appreciate it since I don't fully understand it's use and I can't find any expamples about it.

Thanks!

Nico

------=_Part_80786_14804143.1154454178881-- --===============0267276915== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0267276915==-- From megaco-bounces@ietf.org Tue Aug 01 13:59:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7yWn-00009l-C9; Tue, 01 Aug 2006 13:59:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7yWm-00009g-50 for Megaco@ietf.org; Tue, 01 Aug 2006 13:59:36 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7yWf-0001Np-V9 for Megaco@ietf.org; Tue, 01 Aug 2006 13:59:36 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.13.6/IER-o) with ESMTP id k71HxJAk011075; Tue, 1 Aug 2006 12:59:19 -0500 (CDT) Received: from mmraju1 (mmraju-1.ih.lucent.com [135.185.194.46]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k71HxIP27180; Tue, 1 Aug 2006 12:59:19 -0500 (CDT) From: "Maridi Raju Makaraju\(Raju\)" To: "Nicolas Emiliani" , Subject: RE: [Megaco] Notify reply issue. Date: Tue, 1 Aug 2006 12:59:18 -0500 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <1a9ac220608011042k7c5f05a7s9b64b938cd7e6df1@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1987644050==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1987644050== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C6B56A.4CB7E9C0" This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C6B56A.4CB7E9C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Nicolas, "O-" in front of any Command Request means the command is optional and the processing can continue with next command in the request even if a "O-" command fails. In your case, you just have one command request, so it's not really needed to include "O-", but it's still legal to include it in the request. "O-" (and also "W-" for wildcards) only applies to requests not responses. So, you should not send back "O-Notify"... the example you mentioned "... Context=2{Notify=TGW206/PDC1/2}... " should be the right response. -Raju -----Original Message----- From: Nicolas Emiliani [mailto:or3st3s@gmail.com] Sent: Tuesday, August 01, 2006 12:43 PM To: Megaco@ietf.org Subject: [Megaco] Notify reply issue. Hi list! Well, I have an issue with the reply to a notify command that comes from the MG. Basically I'm receiving this message : MEGACO/1 [192.168.0.206]:2944 T=17201{ C = 2 { O-N=TGW206/PDC1/2{ OE=1235{ 19700101T00015312 : ct/cmp{ res=Success}}}}}\000 So as u see I have an O-N, in the RFC it says O- means that it's a command request list for which I don't understand the use, cause there is only one command (the notify). Anyways, this is what I'm answering as the MGC: MEGACO/1 [192.168.0.187]:2948 Reply=17201{ Context=2{O-Notify=TGW206/PDC1/2}} TransactionResponseAck{3} What happens next is that the MG starts retransmitting the Notify command cause it doesn't like my reply. The board I'm using is a trunk gateway from Audicodes. The guys from audoicodes say that my reply is not valid cause O-Notify is not a legal response. I'm really not sure about that, so what I'm asking is if my answer is ok or not. Should it be "... Context=2{Notify=TGW206/PDC1/2}... " instead? shouldn't the TGW be sending a syntax error instead of retransmitting as if the had no reply? If anyone could send me an expample of use of the "O-" thing I wpould appreciate it since I don't fully understand it's use and I can't find any expamples about it. Thanks! Nico ------=_NextPart_000_0009_01C6B56A.4CB7E9C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi=20 Nicolas,
 
"O-"=20 in front of any Command Request means the command is optional and the = processing=20 can continue
with=20 next command in the request even if a "O-" command = fails.
In=20 your case, you just have one command request, so it's not really needed = to=20 include "O-", but it's still
legal=20 to include it in the request.
 
"O-"=20 (and also "W-" for wildcards) only applies to requests not = responses. So,=20 you should not send back
"O-Notify"... the example you mentioned "... = Context=3D2{Notify=3DTGW206/PDC1/2}... " should=20 be the
right=20 response.
 
-Raju
-----Original Message-----
From: Nicolas Emiliani=20 [mailto:or3st3s@gmail.com]
Sent: Tuesday, August 01, 2006 = 12:43=20 PM
To: Megaco@ietf.org
Subject: [Megaco] Notify = reply=20 issue.

Hi list!
Well, I have an issue with the = reply to=20 a notify command that comes from the MG. Basically I'm receiving this = message=20 :

   MEGACO/1 [192.168.0.206]:2944
  &nbs= p;=20 T=3D17201{
    C =3D 2 {
   =20 O-N=3DTGW206/PDC1/2{
    = OE=3D1235{
   =20 19700101T00015312 : ct/cmp{
   =20 res=3DSuccess}}}}}\000

So as u see I have an O-N, in the RFC it = says O-=20 means that it's a command request list for which I  don't = understand the=20 use, cause there is only one command (the notify). Anyways, this is = what I'm=20 answering as the MGC:

MEGACO/1 [192.168.0.187]:2948
Reply=3D17201{Context=3D2{O-Notify=3DTGW206/PDC1/2}}
TransactionResponseAck{3}=20

What happens next is that the MG starts retransmitting the = Notify=20 command cause it doesn't like my reply. The board I'm using is a trunk = gateway=20 from Audicodes. The guys from audoicodes say that my reply is not = valid cause=20 O-Notify is not  a legal response. I'm really not sure about = that, so=20 what I'm asking is if my answer is ok or not. Should it be "...=20 Context=3D2{Notify=3DTGW206/PDC1/2}... " instead?

shouldn't = the TGW be=20 sending a syntax error instead of retransmitting as if the had no=20 reply?

If anyone could send me an expample of use of the "O-" = thing I=20 wpould appreciate it since I don't fully understand it's use and I = can't find=20 any expamples about it.=20

Thanks!

Nico

------=_NextPart_000_0009_01C6B56A.4CB7E9C0-- --===============1987644050== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1987644050==-- From megaco-bounces@ietf.org Thu Aug 03 02:44:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Wwc-0002lj-Th; Thu, 03 Aug 2006 02:44:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Wwb-0002im-7F for megaco@ietf.org; Thu, 03 Aug 2006 02:44:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8NuW-0005D8-RO for megaco@ietf.org; Wed, 02 Aug 2006 17:05:48 -0400 Received: from usnwksmtp04e.usa.siemens.com ([12.46.135.35] helo=usnwk224srv.usa.siemens.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8NsL-0001n8-7l for megaco@ietf.org; Wed, 02 Aug 2006 17:03:38 -0400 Received: from usnwk203a.ww017.siemens.net ([155.45.111.48]) by 172.16.1.38 with trend_isnt_name_B; Wed, 02 Aug 2006 14:00:18 -0700 Received: from USNWK100MSX.ww017.siemens.net ([155.45.111.54]) by usnwk203a.ww017.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 14:03:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] Error format Date: Wed, 2 Aug 2006 14:03:26 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Error format Thread-Index: Acaw5QmUI5vsaTjBQD6ZqDeHf9DQqgFkVbuA From: "Wainwright, John \(Com US\)" To: X-OriginalArrivalTime: 02 Aug 2006 21:03:27.0586 (UTC) FILETIME=[19BDA420:01C6B677] X-Spam-Score: -2.5 (--) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org As a follow on to this question, if the original ADD request involved a CHOOSE ($) for the ephemeral then if for example there was an error in the Local Descriptor, such as codec not supported, would the response indicate a failure for ADD of a specific Ephemeral termination or would the entire ADD for the ephemeral fail with the response indicating $ for its terminationId ? i.e.=20 ADD =3D eph/00337 {=20 ERROR =3D 515 {"Unsupported Media Type"}=20 Or ADD =3D $ {=20 ERROR =3D 515 {"Unsupported Media Type"}=20 Thanks John -----Original Message----- From: Ashish Singh [mailto:ashishs@redback.com]=20 Sent: Wednesday, July 26, 2006 1:55 PM To: Wainwright, John (Com US) Cc: megaco@ietf.org Subject: Re: [Megaco] Error format I guess it will be easier for MGC to parse, if we only include=20 "streamID" and no other text. IMO, error descriptor should look like: ERROR =3D 515 {"xxx"} Thanks Ashish Wainwright, John (Com US) wrote: > So would a more accurate response have something like the following > ERROR =3D 515 {"Unsupported Media Type. Stream =3D xxx" > > If "Stream =3D 1" can it be omitted and assumed by default ? > > Thanks > John > > > -----Original Message----- > From: Ashish Singh [mailto:ashishs@redback.com]=20 > Sent: Wednesday, July 26, 2006 11:36 AM > To: Wainwright, John (Com US) > Cc: megaco@ietf.org > Subject: Re: [Megaco] Error format > > Hi John, > > The response is correct from syntax point of view. But H.248.8 mentions=20 > to include "stream ID" as Error text for this particular error code. > > There are many other error codes, for which extra information is=20 > required. Like with error codes 433 and 435, contextID is returned, so > that MGC can synchronize its database. > > Thanks > Ashish > > > Wainwright, John (Com US) wrote: > =20 >> Is the following format 'valid' for a response to an ADD request=20 >> containing an unsupported codec in the Local descriptor? Would the=20 >> same format apply, apart from the error code and text, for any other=20 >> type of error in the SDP data within the Local descriptor ? >> =20 >> MEGACO/2 [20.0.4.32]:2084 >> REPLY =3D 269820167 { >> CONTEXT =3D 13 { >> ADD =3D port_1 >> , >> ADD =3D eph/00337 {=20 >> ERROR =3D 515 {"Unsupported Media Type"}=20 >> } >> } >> }=20 >> =20 >> Thanks >> John >> =20 >> >> =20 > ------------------------------------------------------------------------ > =20 >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> =20 >> =20 > > > =20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Aug 03 03:13:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8XOd-0000dA-Ha; Thu, 03 Aug 2006 03:13:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8XOc-0000cy-1s for Megaco@ietf.org; Thu, 03 Aug 2006 03:13:30 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8XOc-0001xX-06 for Megaco@ietf.org; Thu, 03 Aug 2006 03:13:30 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.96]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8XMw-0005cv-Dm for Megaco@ietf.org; Thu, 03 Aug 2006 03:11:49 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.11.20060308/8.12.11/ICT TSC MAIL 2005) with ESMTP id k737BdmH026948; Thu, 3 Aug 2006 09:11:39 +0200 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1243@esealmw113.eemea.ericsson.se> Subject: AVD-2834; RE: [Megaco] H.248.37 - Latch versus Relatch To: "Christer Holmberg \(JO/LMF\)" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Albrecht.Schwarz@alcatel.de Date: Thu, 3 Aug 2006 09:11:38 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/03/2006 09:11:39 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: -2.6 (--) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: Megaco@ietf.org, Christian Groves X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org fyi, we did record the responses (as well as our understanding of some other .37 related questions) in a proposed draft Addendum to H.248.37. See AVD-2834: http://ftp3.itu.int/av-arch/avc-site/Incoming/AVD-2834%20H.248.37_Adden= dum.zip (note: doc will be moved later to directory http://ftp3.itu.int/av-arch/avc-site/2005-2008/0608_Ott/) Any comments? Albrecht/Juergen = =20 "Christer Holmberg = =20 \(JO/LMF\)" To: J.Stoetzer= @alcatel.de, "Christian Groves" =20 Andreas.Winkler@alc= atel.de, UUhler@alcatel.de =20 Subject: RE: [Megac= o] H.248.37 - Latch versus Relatch =20 17.07.2006 22:26 = =20 = =20 Hi, I am currently on vacation, so I will need to verify Christian's answer= s when I get back to office (I will be away the whole july). But, after a= first look it seems like we have a common view :) Regards, Christer -----Original Message----- From: Juergen Stoetzer [mailto:J.Stoetzer@alcatel.de] Sent: 17. hein=E4kuuta 2006 14:42 To: Christian Groves Cc: Christer Holmberg (JO/LMF); Albrecht Schwarz; Carsten Waitzmann; Andreas Winkler; Uwe Uhler Subject: Re: [Megaco] H.248.37 - Latch versus Relatch Hello Christian, Thanks a lot for your answers! They really help clarifying things. Thank you and best regards, Juergen Christian Groves wrote: > Hello Juergen, > > Please see my replies below marked CNG. As I'm no longer with > Ericsson, Christer may have a seperate view. > > Regards, Christian > > Juergen Stoetzer wrote: > >> Hello Christian and Christer, >> >> Below are some questions to H.248.37. Guess you as former editor/mai= n >> contributors may have the best insights in the package design and >> background information. >> >> Thanks a lot in advance for any ideas and clarifications you may giv= e! >> Best regards, >> Juergen Stoetzer >> >> -------------------------------------- >> >> The package H.248.37 introduces the signal ipnapt/latch with >> parameter napt. >> This parameter napt may have the values OFF, LATCH and RELATCH. >> The parameter value LATCH is defined as >> >> "When the NAPT processing signal with the NAPT parameter on a >> termination/stream is set to LATCH, then this results in the MG >> ignoring the addresses received in the RemoteDescriptor. Instead the= >> MG will use the source address and source port from the incoming >> media stream (i.e., from the other terminations) as the destination >> address and destination port of the outgoing application data." >> >> The value RELATCH is defined to imply a similar gateway behaviour as= >> the value LATCH with the difference >> >> "... that the MG will check for a change of source IP address/port o= n >> the incoming media stream. If/when a new source IP address and/or >> port are detected, then they will be used as the destination address= >> and port for future outgoing packets. After re-latching, any packets= >> received on the old source address and port combination will be >> considered as malicious and will be treated accordingly (discarded >> and counted)." >> >> Thus, the RELATCH case emphasizes the change of source IP address/po= rt. >> Does this mean that RELATCHing is only possible/allowed after a firs= t >> LATCHing was already performed and thus the used destination IP >> address/port for outgoing packets are in fact already different from= >> the ones in the Remote descriptor? > > > [CNG] Not necessarily. RELTACH enables the MG to keep receiving > packets and then immediately LATCH to packets from a new source > address. If the MGC sends LATCH it immediately latches to the next > packet. However I think the most likely use case is LATCH followed by= RELATCH. > >> >> In case the stream mode of the corresponding termination equals >> SendReceive it seems to be clear that the signal >> ipnapt/latch{napt=3DLATCH} completes (generates the g/sc event if >> requested by the MGC) at the moment the next IP packet is received b= y >> the corresponding termination. From that moment onwards the source >> address/port of that received packet will then be used as destinatio= n >> address/port for outgoing packets. >> >> In case a Remote descriptor is already specified, is this behaviour >> independent of whether the source address/port of received IP packet= >> is equal to or unqual to the IP address/port specified in this Remot= e >> descriptor? >> That is, if the source address/port of received packet is equal to >> the address/port in the Remote descriptor, does the signal >> ipnapt/latch{napt=3DLATCH} complete nevertheless? > > > [CNG] Yes I would say the signal complete would be returned > irrespective of the address in the remote descriptor. > >> >> Is this also the case if the stream mode is equal to ReceiveOnly? >> Or does the signal ipnapt/latch{napt=3DLATCH} in this case only >> complete at the moment the first IP packet is received _after_ the >> stream mode was changed to SendReceive? >> In other words, does the reception of the new address trigger the >> signal completion event or is it the first packet which is actually >> sent to the new address? > > > [CNG] Signals are usually independent of stream mode. The signal > completion would be when packets are received as that is what drives > the latching process. > >> >> When does the signal ipnapt/latch{napt=3DRELATCH} complete? > > > [CNG] When the MG detects a packet coming from a different address fo= r > the particular stream. > >> >> Does it make sense to generate an IP termination with a Signals >> descriptor containing the signal ipnapt/latch{napt=3DRELATCH}, i.e. >> with RELATCH parameter? >> That is to say, can the very first IP packet received by >> corresponding termination be considered to have a 'new'/'different' >> source IP address/port? >> >> Let's assume an IP termination (Ia profile terminology) is created >> only with a Local descriptor and ipnapt/latch signal: >> >> Add =3D ip///$ { >> Signals{ipnapt/latch{napt=3DLATCH}}, >> Media { >> LocalControl { >> Mode =3D SendReceive >> }, >> Local { >> .... >> } >> } >> } >> >> Is this IP termination then allowed to start sending out IP packets >> after having received the first incoming packet (and after having >> performed latching with the received source address/port) since the >> Stream Mode equals SendReceive but before having received a Remote >> descriptor? > > > [CNG] Yes and no. The MG has the remote addresses at this stage but n= o > description of the media type etc that is usually contained in the > Remote Descriptor. Latching means you ignore the addresses but not th= e > whole remote descriptor contents. > >> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> >> >> >> > = _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Aug 03 03:22:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8XXX-0000Tf-KD; Thu, 03 Aug 2006 03:22:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8XXW-0000Ta-Hh for Megaco@ietf.org; Thu, 03 Aug 2006 03:22:42 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8Nug-0005D8-Cw for Megaco@ietf.org; Wed, 02 Aug 2006 17:05:58 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8Nph-0001ji-2c for Megaco@ietf.org; Wed, 02 Aug 2006 17:00:52 -0400 Received: by ug-out-1314.google.com with SMTP id m2so2149468uge for ; Wed, 02 Aug 2006 14:00:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=ScPCsLQLde5b5Ua54LaeFnelcgWBrI/bX4XORS0dFIPjZrBEBHgg/ZNDdpR2/dHGJ+Pq/1Q1sZU2toJfSEyutK6WzIsZqix+FS8OvboBSZyoU6NFeCqoOUNZr+aYnThMb+DmLYpgqlWiAPRWUM8n1fh1O7RHb0MO/zDYU3GzEeY= Received: by 10.66.221.19 with SMTP id t19mr1683247ugg; Wed, 02 Aug 2006 14:00:45 -0700 (PDT) Received: by 10.66.250.10 with HTTP; Wed, 2 Aug 2006 14:00:45 -0700 (PDT) Message-ID: <1a9ac220608021400w7eb56edeq3ff1369ba05d38d5@mail.gmail.com> Date: Wed, 2 Aug 2006 18:00:45 -0300 From: "Nicolas Emiliani" To: Megaco@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Megaco] FAILOVER X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0716367245==" Errors-To: megaco-bounces@ietf.org --===============0716367245== Content-Type: multipart/alternative; boundary="----=_Part_108309_6516668.1154552445187" ------=_Part_108309_6516668.1154552445187 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi... Im using the H248.14 package to detect if the MGC is alive or not, and I have a quetsion, if the MGC doesn't send a message the MG fails over to the next MGC provided. The thing is that it sends to the next MGC a transmision failure. The thing is that when the other MGC gets the transimission failure and replies it, it doesn't know what is the state of the terminations. So I supouse I should audit them to figure it out, but i don't want to right now, so I was thinking, is there a way to restart the MG through a megaco message?... I know it's pretty nasty... but it is just fot few days :P .... Im sending a SC=ROOT with mnethod=restart but the MG replies and doesn't restart... bastard!... jejeje.... well... any suggestions? Thanks! ------=_Part_108309_6516668.1154552445187 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi...
Im using the H248.14 package to detect if the MGC is alive or not, and I have a quetsion, if the MGC doesn't send a message the MG fails over to the next MGC provided. The thing is that it sends to the next MGC a transmision failure. The thing is that when the other MGC gets the transimission failure and replies it, it doesn't know what is the state of the terminations. So I supouse I should audit them to figure it out, but i don't want to right now, so I was thinking, is there a way to restart the MG through a megaco message?... I know it's pretty nasty... but it is just fot few days :P .... Im sending a SC=ROOT with mnethod=restart but the MG replies and doesn't restart... bastard!... jejeje.... well... any suggestions?
Thanks!
------=_Part_108309_6516668.1154552445187-- --===============0716367245== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0716367245==-- From megaco-bounces@ietf.org Thu Aug 03 04:15:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8YMR-00013n-PP; Thu, 03 Aug 2006 04:15:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8YMR-00013O-0F for megaco@ietf.org; Thu, 03 Aug 2006 04:15:19 -0400 Received: from david.siemens.gr ([212.251.43.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8YMO-0001mq-J6 for megaco@ietf.org; Thu, 03 Aug 2006 04:15:18 -0400 Received: from mail.siemens.gr (localhost [127.0.0.1]) by david.siemens.gr (8.12.6/8.12.6) with ESMTP id k738FCT6000523 for ; Thu, 3 Aug 2006 10:15:13 +0200 Received: from atha112a.gr001.siemens.net ([141.29.38.98]) by mail.siemens.gr (8.12.6/8.12.6) with ESMTP id k738FCEg026761 for ; Thu, 3 Aug 2006 10:15:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] Error format Date: Thu, 3 Aug 2006 11:15:11 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Error format Thread-Index: Acaw5QmUI5vsaTjBQD6ZqDeHf9DQqgFkVbuAABd0+5A= From: "Oikonomou, Ioannis" To: "Wainwright, John \(Com US\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org John, I think that the second response is the correct one, i.e. with "$". See also http://www1.ietf.org/mail-archive/web/megaco/current/msg06129.html. Ioannis Oikonomou -----Original Message----- From: Wainwright, John (Com US)=20 Sent: Thursday, August 03, 2006 12:03 AM To: megaco@ietf.org Subject: RE: [Megaco] Error format As a follow on to this question, if the original ADD request involved a CHOOSE ($) for the ephemeral then if for example there was an error in the Local Descriptor, such as codec not supported, would the response indicate a failure for ADD of a specific Ephemeral termination or would the entire ADD for the ephemeral fail with the response indicating $ for its terminationId ? i.e.=20 ADD =3D eph/00337 {=20 ERROR =3D 515 {"Unsupported Media Type"}=20 Or ADD =3D $ {=20 ERROR =3D 515 {"Unsupported Media Type"}=20 Thanks John -----Original Message----- From: Ashish Singh [mailto:ashishs@redback.com]=20 Sent: Wednesday, July 26, 2006 1:55 PM To: Wainwright, John (Com US) Cc: megaco@ietf.org Subject: Re: [Megaco] Error format I guess it will be easier for MGC to parse, if we only include=20 "streamID" and no other text. IMO, error descriptor should look like: ERROR =3D 515 {"xxx"} Thanks Ashish Wainwright, John (Com US) wrote: > So would a more accurate response have something like the following > ERROR =3D 515 {"Unsupported Media Type. Stream =3D xxx" > > If "Stream =3D 1" can it be omitted and assumed by default ? > > Thanks > John > > > -----Original Message----- > From: Ashish Singh [mailto:ashishs@redback.com]=20 > Sent: Wednesday, July 26, 2006 11:36 AM > To: Wainwright, John (Com US) > Cc: megaco@ietf.org > Subject: Re: [Megaco] Error format > > Hi John, > > The response is correct from syntax point of view. But H.248.8 mentions=20 > to include "stream ID" as Error text for this particular error code. > > There are many other error codes, for which extra information is=20 > required. Like with error codes 433 and 435, contextID is returned, so > that MGC can synchronize its database. > > Thanks > Ashish > > > Wainwright, John (Com US) wrote: > =20 >> Is the following format 'valid' for a response to an ADD request=20 >> containing an unsupported codec in the Local descriptor? Would the=20 >> same format apply, apart from the error code and text, for any other=20 >> type of error in the SDP data within the Local descriptor ? >> =20 >> MEGACO/2 [20.0.4.32]:2084 >> REPLY =3D 269820167 { >> CONTEXT =3D 13 { >> ADD =3D port_1 >> , >> ADD =3D eph/00337 {=20 >> ERROR =3D 515 {"Unsupported Media Type"}=20 >> } >> } >> }=20 >> =20 >> Thanks >> John >> =20 >> >> =20 > ------------------------------------------------------------------------ > =20 >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> =20 >> =20 > > > =20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Aug 03 05:35:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Zbt-0000qm-CS; Thu, 03 Aug 2006 05:35:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Zbs-0000qd-5R for Megaco@ietf.org; Thu, 03 Aug 2006 05:35:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8YCf-0000ec-VM for Megaco@ietf.org; Thu, 03 Aug 2006 04:05:14 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.96]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8XqJ-0006EZ-BZ for Megaco@ietf.org; Thu, 03 Aug 2006 03:42:08 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.11.20060308/8.12.11/ICT TSC MAIL 2005) with ESMTP id k737g1tx008309; Thu, 3 Aug 2006 09:42:01 +0200 In-Reply-To: <1a9ac220608021400w7eb56edeq3ff1369ba05d38d5@mail.gmail.com> Subject: Re: [Megaco] FAILOVER To: "Nicolas Emiliani" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Albrecht.Schwarz@alcatel.de Date: Thu, 3 Aug 2006 09:42:00 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/03/2006 09:42:01 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: -2.6 (--) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Nicolas, ServiceChange procedure should be principally possible. See Annex F.3.9/H.248.1 "MGC Initiated Service Restoration". => ServiceChange 'object' = Root termination => ServiceChangeMethod = RESTART => ServiceChangeReason = 900 or 901 The reaction by the MG must be then the "attempt to establish a new control association in accordance with F.3.2 ...". Perhaps your Reason codepoint was different!? - Albrecht "Nicolas Emiliani" To: Megaco@ietf.org Subject: [Megaco] FAILOVER 02.08.2006 18:00 Hi... Im using the H248.14 package to detect if the MGC is alive or not, and I have a quetsion, if the MGC doesn't send a message the MG fails over to the next MGC provided. The thing is that it sends to the next MGC a transmision failure. The thing is that when the other MGC gets the transimission failure and replies it, it doesn't know what is the state of the terminations. So I supouse I should audit them to figure it out, but i don't want to right now, so I was thinking, is there a way to restart the MG through a megaco message?... I know it's pretty nasty... but it is just fot few days :P .... Im sending a SC=ROOT with mnethod=restart but the MG replies and doesn't restart... bastard!... jejeje.... well... any suggestions? Thanks!_______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Aug 03 21:28:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8oUI-0006cS-BZ; Thu, 03 Aug 2006 21:28:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8oUH-0006cN-Em for megaco@ietf.org; Thu, 03 Aug 2006 21:28:29 -0400 Received: from quantum.websiteactive.com ([70.86.207.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8oUE-0006iw-Cl for megaco@ietf.org; Thu, 03 Aug 2006 21:28:29 -0400 Received: from cpe-61-9-144-63.vic.bigpond.net.au ([61.9.144.63]:10077 helo=[127.0.0.1]) by quantum.websiteactive.com with esmtpa (Exim 4.52) id 1G8oTx-0006P8-Qs; Fri, 04 Aug 2006 11:28:15 +1000 Message-ID: <44D2A2A0.2010203@nteczone.com> Date: Fri, 04 Aug 2006 11:28:00 +1000 From: Christian Groves User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CHATRAS Bruno RD-CORE-ISS Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=" line References: <2AF8FF7D89242541B12E7A47F6ECB4BE040787FB@ftrdmel3.rd.francetelecom.fr> In-Reply-To: <2AF8FF7D89242541B12E7A47F6ECB4BE040787FB@ftrdmel3.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - quantum.websiteactive.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: cba578ce4c0062c6057b762290f982a8 Cc: Albrecht.Schwarz@alcatel.de, "Campos, Simao" , megaco@ietf.org, Christer Holmberg X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org 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:christer.holmberg@ericsson.com] >Envoyé : mardi 25 juillet 2006 09:34 >À : Christian Groves; Albrecht.Schwarz@alcatel.de >Cc : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org; 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" >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 > >Albrecht.Schwarz@alcatel.de 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" , "CHATRAS Bruno RD-CORE-ISS" >> , Albrecht SCHWARZ/DE/ALCATEL@ALCATEL >> icsson.com> cc: megaco@ietf.org >> 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:kboyle@nortel.com] >>Sent: 21. heinäkuuta 2006 17:23 >>To: Christer Holmberg (JO/LMF); CHATRAS Bruno RD-CORE-ISS; >>Albrecht.Schwarz@alcatel.de >>Cc: megaco@ietf.org >>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:christer.holmberg@ericsson.com] >>Sent: Friday, July 21, 2006 5:18 AM >>To: CHATRAS Bruno RD-CORE-ISS; Albrecht.Schwarz@alcatel.de >>Cc: megaco@ietf.org >>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:bruno.chatras@orange-ft.com] >>Sent: 21. heinäkuuta 2006 10:26 >>To: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de >>Cc: megaco@ietf.org >>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:christer.holmberg@ericsson.com] >>Envoyé : jeudi 20 juillet 2006 20:46 >>À : Albrecht.Schwarz@alcatel.de >>Cc : megaco@ietf.org >>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: Albrecht.Schwarz@alcatel.de [mailto:Albrecht.Schwarz@alcatel.de] >>Sent: 20. heinäkuuta 2006 12:00 >>To: Christer Holmberg (JO/LMF) >>Cc: megaco@ietf.org >>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" >>, "B Venkat S.R Swamy" >> >, "Christian Groves" >> >> icsson.com> cc: Albrecht >>SCHWARZ/DE/ALCATEL@ALCATEL, megaco@ietf.org >> 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:kboyle@nortel.com] >>Sent: 17. heinäkuuta 2006 19:58 >>To: B Venkat S.R Swamy; Christian Groves >>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; 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:b.swamy@flextronicssoftware.com] >>Sent: Monday, July 17, 2006 12:40 AM >>To: Christian Groves >>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; >>christer.holmberg@ericsson.com >>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 >> >> >> >> >> Christian Groves >> >> >> 07/17/2006 06:36 AM >> >> >> >>To >> >>Albrecht.Schwarz@alcatel.de >> >> >>cc >> >>B Venkat S.R Swamy/HSS@HSS, megaco@ietf.org, >>christer.holmberg@ericsson.com >> >> >>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 >> >>Albrecht.Schwarz@alcatel.de 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" >>> >>> >>> >>> >> >> >> >> >>> >> >>> >>> >>> >>SCHWARZ/DE/ALCATEL@ALCATEL >> >> >> >> >>> ftware.com> cc: >>> >>> >>> >>> >>megaco@ietf.org, christer.holmberg@ericsson.com >> >> >> >> >> >>> 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)Albrecht.Schwarz@alcatel.de >>> >>> >>> >>> >>> >>> >> >> >> >> >>> 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 >>> >>> >>> >>> >>christer.holmberg@ericsson.com, >> >> >> >> >>> taylor@nortel.com >>> >>> >>> >>> >> >> >> >> >>> (Embedded image moved to file: >>> >>> >>> >>> >> >> >> >> >>> pic31609.gif) >>> >>> >>> >>> >> >> >>cc >> >> >> >> >>> (Embedded image moved to >>> >>> >>> >>> >>file: >> >> >> >> >>> pic17314.gif) >>> >>> >>> >>> >> >> >> >> >>> megaco@ietf.org >>> >>> >>> >>> >> >> >> >> >>> (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 >>>Megaco@ietf.org >>>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 >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>----------------------------------------------------------------------- >>- >> >> >> >> >>> >>> >>> >>> >>----------------------------------------------------------------------- >>- >> >> >> >> >>> >>> >>> >>> >>----------------------------------------------------------------------- >>- >> >> >> >> >>> >>> >>> >>> >>----------------------------------------------------------------------- >>- >> >> >> >> >>> >>> >>> >>> >>----------------------------------------------------------------------- >>- >> >> >> >> >>> >>> >>> >>> >>----------------------------------------------------------------------- >>- >> >> >> >> >>> >>> >>> >>> >>----------------------------------------------------------------------- >>- >> >> >> >> >>> >>> >>> >>> >>----------------------------------------------------------------------- >>- >> >> >> >> >>> >>> >>> >>> >>----------------------------------------------------------------------- >>- >> >> >> >> >>>---------------------------------------------------------------------- >>>- >>> >>> >>> >>> >>- >> >> >> >> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>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 >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >> >> >> >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >> >> >> >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >> >> >> >> >> >> >> > > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco > > > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Aug 04 02:25:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8t89-0002ZS-91; Fri, 04 Aug 2006 02:25:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8t87-0002ZN-Tz for megaco@ietf.org; Fri, 04 Aug 2006 02:25:55 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8t84-0001HZ-SO for megaco@ietf.org; Fri, 04 Aug 2006 02:25:55 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 100384F00DC; Fri, 4 Aug 2006 08:25:52 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 08:25:51 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 08:25:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=" line Date: Fri, 4 Aug 2006 08:25:50 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F12C0@esealmw113.eemea.ericsson.se> In-Reply-To: <44D2A2A0.2010203@nteczone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=" line Thread-Index: Aca3ZUgdE0O4qAnfS7Wg814TqFSnjgAKBdrw From: "Christer Holmberg \(JO/LMF\)" To: "Christian Groves" , "CHATRAS Bruno RD-CORE-ISS" X-OriginalArrivalTime: 04 Aug 2006 06:25:51.0441 (UTC) FILETIME=[D50F0C10:01C6B78E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 17084e646c41197105a805f377823383 Cc: Albrecht.Schwarz@alcatel.de, "Campos, Simao" , megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org 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=3D line where we need it. H.248.20 = uses "-" in the c=3D line.=20 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 =20 -----Original Message----- From: Christian Groves [mailto:Christian.Groves@nteczone.com]=20 Sent: 4. elokuuta 2006 4:28 To: CHATRAS Bruno RD-CORE-ISS Cc: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de; = megaco@ietf.org; Campos, Simao Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value = '-'in SDP"m=3D" line 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.=20 > >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:christer.holmberg@ericsson.com] >Envoy=E9 : mardi 25 juillet 2006 09:34 >=C0 : Christian Groves; Albrecht.Schwarz@alcatel.de Cc : CHATRAS Bruno=20 >RD-CORE-ISS; megaco@ietf.org; Campos, Simao Objet : Re: [Megaco] ETSI=20 >H.248 Ia Profile: issue with media value '-'in SDP"m=3D" 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=3D" line >Author: "Christian Groves" >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.=20 >"-" 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 > >Albrecht.Schwarz@alcatel.de wrote: > > =20 > >>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=20 >>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=20 >>explicitly the syntax extension. >> >>Thanks, >>regards, >> >>Albrecht >> >> >> >> >> = =20 >> "Christer Holmberg = =20 >> \(JO/LMF\)" To: "Kevin = Boyle" , "CHATRAS Bruno RD-CORE-ISS" = >> , Albrecht SCHWARZ/DE/ALCATEL@ALCATEL = =20 >> icsson.com> cc: = megaco@ietf.org = =20 >> Subject: RE: = [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=3D" = line =20 >> 21.07.2006 16:42 = =20 >> = =20 >> >> >> >> >> >>Hi, >> >>What we need to say is that "-" is allowed in H.248 usage of SDP(in=20 >>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:kboyle@nortel.com] >>Sent: 21. hein=E4kuuta 2006 17:23 >>To: Christer Holmberg (JO/LMF); CHATRAS Bruno RD-CORE-ISS;=20 >>Albrecht.Schwarz@alcatel.de >>Cc: megaco@ietf.org >>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>'-'in SDP"m=3D" line >> >>I will draft something to be included in the next IG. Even though we=20 >>are talking about something syntactical in nature, the syntax is that=20 >>of SDP and not H.248. It also appears that there is a common=20 >>understanding of how this is to be used. Therefore, I think this=20 >>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=20 >>that is acceptable in the IG, or if we should look to prepare a=20 >>Corrigendum in November. >> >>Kevin >> >>-----Original Message----- >>From: Christer Holmberg (JO/LMF) >>[mailto:christer.holmberg@ericsson.com] >>Sent: Friday, July 21, 2006 5:18 AM >>To: CHATRAS Bruno RD-CORE-ISS; Albrecht.Schwarz@alcatel.de >>Cc: megaco@ietf.org >>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>'-'in SDP"m=3D" line >> >> >>Hi, >> >>I agree with Bruno. >> >>Also, H.248.1 does already "extend" RFC 2327, by defining some SDP=20 >>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:bruno.chatras@orange-ft.com] >>Sent: 21. hein=E4kuuta 2006 10:26 >>To: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de >>Cc: megaco@ietf.org >>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>'-'in SDP"m=3D" line >> >>Moreover, even if a CR was issued agaisnt ES 283 018 to recommend=20 >>using the OMIT token rather than the "-", the "-" would have to be=20 >>kept in the Ia profile anyway for backward compatibility purposes. I=20 >>assume that we would not like an IP2IP MG to reject an H.248 command=20 >>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)=20 >>[mailto:christer.holmberg@ericsson.com] >>Envoy=E9 : jeudi 20 juillet 2006 20:46 >>=C0 : Albrecht.Schwarz@alcatel.de >>Cc : megaco@ietf.org >>Objet : RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>'-'in SDP"m=3D" line >> >> >>Hi, >> >>Why can't the Ia profile be based on RFC 4566? RFC 3108 is not=20 >>referenced by the Ia profile, or by H.248.1. >> >>Also, my understanding is that RFC 3108 DOES recommend "-", but says=20 >>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: Albrecht.Schwarz@alcatel.de [mailto:Albrecht.Schwarz@alcatel.de] >>Sent: 20. hein=E4kuuta 2006 12:00 >>To: Christer Holmberg (JO/LMF) >>Cc: megaco@ietf.org >>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>'-'in SDP "m=3D" line >> >> >>Christer, et al., >> >>I was aware of the SDP extension by '-' in "SDP new" (guess will be=20 >>RFC 4566), when writting my email. >>(I was not aware of the Q.1950 SDP extensions, but I didn't consider=20 >>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=20 >>replace it by RFC 4566, but whether this is a straightforward task or=20 >>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" >>, "B Venkat S.R Swamy" >> >, "Christian Groves" >> >> icsson.com> cc: Albrecht >>SCHWARZ/DE/ALCATEL@ALCATEL, megaco@ietf.org >> Subject: RE:=20 >>[Megaco] ETSI H.248 Ia Profile: issue with media value '-'inSDP"m=3D" = 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=3D line are=20 >>defined as tokens. >> >>media =3D token >> ;typically "audio", "video", "text" or >> ;"application" >> >>fmt =3D token >> ;typically an RTP payload type for audio >> ;and video media >> >>token =3D 1*(token-char) >> >>token-char =3D %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:kboyle@nortel.com] >>Sent: 17. hein=E4kuuta 2006 19:58 >>To: B Venkat S.R Swamy; Christian Groves >>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; Christer Holmberg >>(JO/LMF) >>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>'-'inSDP"m=3D" line >> >>The MGC could place "$" there if it truly did not care. This would=20 >>align better with the intent of both SDP and H.248. >> >>Kevin >> >>________________________________ >> >>From: B Venkat S.R Swamy [mailto:b.swamy@flextronicssoftware.com] >>Sent: Monday, July 17, 2006 12:40 AM >>To: Christian Groves >>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org;=20 >>christer.holmberg@ericsson.com >>Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value = '-' >>inSDP"m=3D" 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=3D" media space port ["/" integer] space proto 1*(space fmt) CRLF >> >>media =3D 1*(alpha-numeric) >>;typically "audio", "video", "application" >>;or "data" >> >>therefore the string "OMIT" was suggested for the media, so as not to=20 >>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 >> >> >> >> >> Christian Groves=20 >> >> >> 07/17/2006 06:36 AM >> >> >> >>To >> >>Albrecht.Schwarz@alcatel.de >> >> >>cc >> >>B Venkat S.R Swamy/HSS@HSS, megaco@ietf.org,=20 >>christer.holmberg@ericsson.com >> >> >>Subject >> >>Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-' = inSDP"m=3D" >>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=20 >>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=20 >>receives normal SDP values in those positions these can simply be=20 >>ignored. No need to say OMIT. >> >>Regards, Christian >> >>Albrecht.Schwarz@alcatel.de wrote: >> >>=20 >> >> =20 >> >>>Thanks for pointing to =A7 2.5/RFC 3108! >>>" The string "OMIT" can be used in lieu of "-" for an omitted >>> =20 >>> >>> =20 >>> >>parameter." >>=20 >> >> =20 >> >>>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 >>> =20 >>> >>> =20 >>> >>[1] >>=20 >> >> =20 >> >>> 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 >>> =20 >>> >>> =20 >>> >>this >>=20 >> >> =20 >> >>> convention, while allowing the use of the special character "/" >>> =20 >>> >>> =20 >>> >>in a >>=20 >> >> =20 >> >>> manner commensurate with [1]. In addition, the special >>> =20 >>> >>> =20 >>> >>characters >>=20 >> >> =20 >> >>> "$" and "-" are used in the following manner. A "$" value is a >>> wildcard that allows the recipient of the SDP description to >>> =20 >>> >>> =20 >>> >>select >>=20 >> >> =20 >> >>> any permitted value of the parameter. A "-" value indicates that >>> =20 >>> >>> =20 >>> >>it >>=20 >> >> =20 >> >>> 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 >>> =20 >>> >>> =20 >>> >>source >>=20 >> >> =20 >> >>> such as provisioning, defaults, another protocol, another SDP >>> descriptor or another part of the same SDP descriptor. If the >>> =20 >>> >>> =20 >>> >>use of >>=20 >> >> =20 >> >>> these special characters is construed as a violation of RFC 2327 >>> =20 >>> >>> =20 >>> >>[1] >>=20 >> >> =20 >> >>> syntax, then reserved string values can be used. The string >>> =20 >>> >>> =20 >>> >>"CHOOSE" >>=20 >> >> =20 >> >>> can be used in lieu of "$". The string "OMIT" can be used in >>> =20 >>> >>> =20 >>> >>lieu of >>=20 >> >> =20 >> >>> "-" for an omitted parameter. >>> >>> >>> >>> >>> >>> =20 >>> >>> =20 >>> >>=20 >> >> =20 >> >>> "B Venkat S.R Swamy" >>> =20 >>> >>> =20 >>> >>=20 >> >> =20 >> >>> >> =20 >>> >>> =20 >>> >>SCHWARZ/DE/ALCATEL@ALCATEL >>=20 >> >> =20 >> >>> ftware.com> cc: >>> =20 >>> >>> =20 >>> >>megaco@ietf.org, christer.holmberg@ericsson.com >> >>=20 >> >> =20 >> >>> Subject: Re: >>> =20 >>> >>> =20 >>> >>[Megaco] ETSI H.248 Ia Profile: issue with media value '-' in = SDP"m=3D" >>=20 >> >> =20 >> >>> 14.07.2006 05:59 line >>> =20 >>> >>> =20 >>> >>=20 >> >> >>=20 >> >> =20 >> >>>Hi >>> >>>I support the option 2, and we should try to avoid any violation of=20 >>>the >>> =20 >>> >>> =20 >>> >>RFC >>=20 >> >> =20 >> >>>2327/RFC 3108. >>>The string "OMIT" as suggested by RFC 3108, section 2.5, can be used >>> =20 >>> >>> =20 >>> >>for >>=20 >> >> =20 >> >>>media. >>>Also the use of "-" is not allowed as per RFC 2327/RFC 2848 for the >>> =20 >>> >>> =20 >>> >>proto >>=20 >> >> =20 >> >>>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:=20 >>>pic12377.gif)Albrecht.Schwarz@alcatel.de >>> >>> >>> =20 >>> >>> =20 >>> >>=20 >> >> =20 >> >>> Albrecht >>> =20 >>> >>> =20 >>> >>=20 >> >> =20 >> >>> .Schwarz >>> =20 >>> >>> =20 >>> >>=20 >> >> =20 >> >>> @alcatel >>> =20 >>> >>> =20 >>> >>=20 >> >> =20 >> >>> .de (Embedded image moved to file: >>> =20 >>> >>> =20 >>> >>=20 >> >> =20 >> >>> pic00224.gif) >>> =20 >>> >>> =20 >>> >>=20 >> >>To >>=20 >> >> =20 >> >>> 07/13/20 (Embedded image moved to >>> =20 >>> >>> =20 >>> >>file: >>=20 >> >> =20 >> >>> 06 09:49 pic02722.gif) >>> =20 >>> >>> =20 >>> >>=20 >> >> =20 >> >>> PM >>> =20 >>> >>> =20 >>> >>christer.holmberg@ericsson.com, >>=20 >> >> =20 >> >>> taylor@nortel.com >>> =20 >>> >>> =20 >>> >>=20 >> >> =20 >> >>> (Embedded image moved to file: >>> =20 >>> >>> =20 >>> >>=20 >> >> =20 >> >>> pic31609.gif) >>> =20 >>> >>> =20 >>> >>=20 >> >>cc >>=20 >> >> =20 >> >>> (Embedded image moved to >>> =20 >>> >>> =20 >>> >>file: >>=20 >> >> =20 >> >>> pic17314.gif) >>> =20 >>> >>> =20 >>> >>=20 >> >> =20 >> >>> megaco@ietf.org >>> =20 >>> >>> =20 >>> >>=20 >> >> =20 >> >>> (Embedded image moved to file: >>> =20 >>> >>> =20 >>> >>=20 >> >> =20 >> >>> pic14997.gif) >>> =20 >>> >>> =20 >>> >>=20 >> >>Subject >>=20 >> >> =20 >> >>> (Embedded image moved to >>> =20 >>> >>> =20 >>> >>file: >>=20 >> >> =20 >> >>> pic24297.gif) >>> =20 >>> >>> =20 >>> >>=20 >> >> =20 >> >>> [Megaco] ETSI H.248 Ia >>> =20 >>> >>> =20 >>> >>Profile: >>=20 >> >> =20 >> >>> issue with media value '-' >>> =20 >>> >>> =20 >>> >>in >>=20 >> >> =20 >> >>> SDP"m=3D" line >>> =20 >>> >>> =20 >>> >>=20 >> >> >>=20 >> >> >>=20 >> >> =20 >> >>> (Embedded image moved to file: >>> =20 >>> >>> =20 >>> >>=20 >> >> =20 >> >>> pic24565.gif) >>> =20 >>> >>> =20 >>> >>=20 >> >> =20 >> >>> (Embedded image moved to file: >>> =20 >>> >>> =20 >>> >>=20 >> >> =20 >> >>> pic28141.gif) >>> =20 >>> >>> =20 >>> >>=20 >> >> >>=20 >> >> >>=20 >> >> =20 >> >>>Christer, et al., >>> >>>media value '-' is not allowed by RFC 2327 (& RFC 3108) in our >>>understanding: >>> >>>RFC 2327: >>> >>> >>>media-descriptions =3D *( media-field >>> >>> >>> information-field >>> >>> >>> *(connection-field) >>> >>> >>> bandwidth-fields >>> >>> >>> key-field >>> >>> >>> attribute-fields ) >>> >>> >>> media-field =3D "m=3D" media space port ["/" integer] >>> >>> >>> space proto 1*(space fmt) CRLF >>> >>> >>> media =3D 1*(alpha-numeric) >>> >>> >>> ;typically "audio", "video", "application" >>> >>> >>> ;or "data" >>> >>> >>>RFC 3108: >>> >>> >>>media-descriptions =3D *(media-description) >>> >>> >>>media-description =3D media-field information-field >>> =20 >>> >>> =20 >>> >>*(connection-field) >>=20 >> >> =20 >> >>> bandwidth-fields key-field attribute-fields >>> >>> >>>media-field =3D RFC 2327-media-field / RFC 2848-media-field / >>> >>> >>> atm-media-field >>> >>> >>> ; RFC 2327-media-field and RFC 2848-media-field defined in those=20 >>>rfc's >>> >>> >>>atm-media-field =3D "m=3D" media space vcId space transport-fmts EOL >>> >>> >>> ; superset of RFC 2327 definition >>> >>> >>>media =3D "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=20 >>>further differences between H.248/SDP and SIP/SDP, with further=20 >>>mapping requirements for the "SDP mapper" (ETSI TR 183 046;=20 >>>WI-03062), or >>> >>>(2) alternatively we could change the codepoint '-' to an allowed >>> =20 >>> >>> =20 >>> >>codepoint >>=20 >> >> =20 >> >>>(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 >>> =20 >>> >>> =20 >>> >>with >>=20 >> >> =20 >> >>>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 >>>|---------------------------+---------------------------+------------ >>>|---------------------------+---------------------------+- >>>|---------------------------+---------------------------+- >>> =20 >>> >>> =20 >>> >>---------------| >>=20 >> >> =20 >> >>>| SDP Information Element | Mandatory/optional | >>>Description | >>>|---------------------------+---------------------------+------------ >>>|---------------------------+---------------------------+- >>>|---------------------------+---------------------------+- >>> =20 >>> >>> =20 >>> >>---------------| >>=20 >> >> =20 >> >>>| Protocol version | Mandatory | The value >>> =20 >>> >>> =20 >>> >>must >>=20 >> >> =20 >> >>>always be | >>>| "v=3D" line | | equals to >>> =20 >>> >>> =20 >>> >>zero: >>=20 >> >> =20 >> >>>| >>>| | | v=3D0 >>>| >>>|---------------------------+---------------------------+------------ >>>|---------------------------+---------------------------+- >>>|---------------------------+---------------------------+- >>> =20 >>> >>> =20 >>> >>---------------| >>=20 >> >> =20 >> >>>| Connection | Mandatory | The network >>> =20 >>> >>> =20 >>> >>type >>=20 >> >> =20 >> >>>must always| >>>| "c=3D" line | | be "IN". >>>| >>>| | | >>>| >>>| | |The address >>> =20 >>> >>> =20 >>> >>type >>=20 >> >> =20 >> >>>value must | >>>| | |be "IP4" or >>> =20 >>> >>> =20 >>> >>"IP6". >>=20 >> >> =20 >> >>>| >>>| | | >>>| >>>| | |The = connection >>>address value | >>>| | |may be >>>underspecified with | >>>| | |CHOOSE >>> =20 >>> >>> =20 >>> >>wildcard >>=20 >> >> =20 >> >>>("$"). | >>>|---------------------------+---------------------------+------------ >>>|---------------------------+---------------------------+- >>>|---------------------------+---------------------------+- >>> =20 >>> >>> =20 >>> >>---------------| >>=20 >> >> =20 >> >>>| Media | Mandatory |"-" may be >>> =20 >>> >>> =20 >>> >>used >>=20 >> >> =20 >> >>>for the media| >>>| "m=3D" line | |value. = Other >>>values shall be | >>>| | |ignored, >>> =20 >>> >>> =20 >>> >>unless >>=20 >> >> =20 >> >>>media | >>>| | |specific >>>information is | >>>| | |required. >>>| >>>| | | >>>| >>>| | |The port = value >>> =20 >>> >>> =20 >>> >>may >>=20 >> >> =20 >> >>>be | >>>| | = |underspecified >>>with CHOOSE | >>>| | |wildcard >>> =20 >>> >>> =20 >>> >>("$"). >>=20 >> >> =20 >> >>>| >>>| | | >>>| >>>| | |"-" may be >>> =20 >>> >>> =20 >>> >>used >>=20 >> >> =20 >> >>>for the | >>>| | |transport >>> =20 >>> >>> =20 >>> >>value, >>=20 >> >> =20 >> >>>unless | >>>| | |transport >>> =20 >>> >>> =20 >>> >>specific >>=20 >> >> =20 >> >>>behaviour | >>>| | |is required = by >>> =20 >>> >>> =20 >>> >>the >>=20 >> >> =20 >> >>>MG. | >>>| | |(See note) >>>| >>>| | | "-" may be >>> =20 >>> >>> =20 >>> >>used >>=20 >> >> =20 >> >>>for the | >>>| | | format list >>>value. Other | >>>| | | values = shall >>> =20 >>> >>> =20 >>> >>be >>=20 >> >> =20 >> >>>ignored. | >>>|---------------------------+---------------------------+------------ >>>|---------------------------+---------------------------+- >>>|---------------------------+---------------------------+- >>> =20 >>> >>> =20 >>> >>---------------| >>=20 >> >> =20 >> >>> >>> >>> >>> >>> >>> >>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> >>>*********************** FSS-Restricted *********************** >>>"DISCLAIMER: This message is proprietary to Flextronics Software=20 >>>Systems Limited (FSS) and is intended solely for the use of the=20 >>>individual to whom it is addressed. It may contain privileged or=20 >>>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=20 >>>strictly prohibited from using, copying, altering, or disclosing the=20 >>>contents of this message. FSS accepts no responsibility for loss or=20 >>>damage arising from the use of the information transmitted by this=20 >>>email including damage from virus." >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> >>> >>> >>> >>> =20 >>> >>> =20 >>> >>---------------------------------------------------------------------- >>- >>- >>=20 >> >> =20 >> >>> =20 >>> >>> =20 >>> >>---------------------------------------------------------------------- >>- >>- >>=20 >> >> =20 >> >>> =20 >>> >>> =20 >>> >>---------------------------------------------------------------------- >>- >>- >>=20 >> >> =20 >> >>> =20 >>> >>> =20 >>> >>---------------------------------------------------------------------- >>- >>- >>=20 >> >> =20 >> >>> =20 >>> >>> =20 >>> >>---------------------------------------------------------------------- >>- >>- >>=20 >> >> =20 >> >>> =20 >>> >>> =20 >>> >>---------------------------------------------------------------------- >>- >>- >>=20 >> >> =20 >> >>> =20 >>> >>> =20 >>> >>---------------------------------------------------------------------- >>- >>- >>=20 >> >> =20 >> >>> =20 >>> >>> =20 >>> >>---------------------------------------------------------------------- >>- >>- >>=20 >> >> =20 >> >>> =20 >>> >>> =20 >>> >>---------------------------------------------------------------------- >>- >>- >>=20 >> >> =20 >> >>>--------------------------------------------------------------------- >>>- >>>- >>> =20 >>> >>> =20 >>> >>- >>=20 >> >> =20 >> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> =20 >>> >>> =20 >>> >> >> >>*********************** FSS-Restricted *********************** >>"DISCLAIMER: This message is proprietary to Flextronics Software=20 >>Systems Limited (FSS) and is intended solely for the use of the=20 >>individual to whom it is addressed. It may contain privileged or=20 >>confidential information and should not be circulated or used for any=20 >>purpose other than for what it is intended. If you have received this=20 >>message in error, please notify the originator immediately. >>If you are not the intended recipient, you are notified that you are=20 >>strictly prohibited from using, copying, altering, or disclosing the=20 >>contents of this message. FSS accepts no responsibility for loss or=20 >>damage arising from the use of the information transmitted by this=20 >>email including damage from virus." >> >> >> >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >> >> >> >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >> >> >> >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >> >> >> >>=20 >> >> =20 >> > > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco > > > > > =20 > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Aug 04 11:10:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91KA-0008Cy-Rt; Fri, 04 Aug 2006 11:10:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91K9-00088u-Q8 for megaco@ietf.org; Fri, 04 Aug 2006 11:10:53 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G90q6-0002d9-OX for megaco@ietf.org; Fri, 04 Aug 2006 10:39:50 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.96]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G90Tk-00016g-7f for megaco@ietf.org; Fri, 04 Aug 2006 10:16:46 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.11.20060308/8.12.11/ICT TSC MAIL 2005) with ESMTP id k74EGabU014976; Fri, 4 Aug 2006 16:16:36 +0200 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F12C0@esealmw113.eemea.ericsson.se> Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=" line To: "Christer Holmberg \(JO/LMF\)" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Albrecht.Schwarz@alcatel.de Date: Fri, 4 Aug 2006 16:16:35 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/04/2006 16:16:35 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: -2.6 (--) X-Scan-Signature: 62ed4f4e65fc3e4881e9f1a46097450f Cc: CHATRAS Bruno RD-CORE-ISS , megaco@ietf.org, "Campos, Simao" , Christian Groves X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org 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 o= nly. [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 th= e text. 2nd Replacement of RFC 2327 by RFC 4566 in H.248.1. We need an investiga= tion 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 w= e 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 replacemen= t by RFC 4566 in H.248.1, and - codepoint "-" in ETSI_BGF/1 would not change in future profile versio= ns. /Albrecht = =20 "Christer Holmberg = =20 \(JO/LMF\)" To: "Christian= Groves" , "CHATRAS Bruno =20 =20 icsson.com> cc: Albrecht S= CHWARZ/DE/ALCATEL@ALCATEL, , "Campos, Simao" =20 =20 04.08.2006 08:25 Subject: RE: [Megac= o] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=3D" =20 line = =20 = =20 Hi, Eventhough I would prefer "data" over "omit", there are still some issu= es. First, "data" has been removed from RFC4566 (new SDP RFC), due to "uncl= ear 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 tha= t is a separate discussion. But, if you use "data", wouldn't you expect something specific in the f= mt field? Remember that Ia uses "-" in the fmt field also, because Ia simp= ly 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=3D line where we need it. H.248.20= uses "-" in the c=3D 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 tha= t the receiver sometimes shall care, and in other cases it doesn't need t= o care. But, again, in Ia we will have that problem once/if media awarene= ss is added to the profile. So, I think it would be good if H.248.1 said that "-" can be used in AL= L SDP parameter fields, because in future we may find other places where = it may be needed. Regards, Christer -----Original Message----- From: Christian Groves [mailto:Christian.Groves@nteczone.com] Sent: 4. elokuuta 2006 4:28 To: CHATRAS Bruno RD-CORE-ISS Cc: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de; megaco@ietf.org; Campos, Simao Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'= in SDP"m=3D" line Hello Bruno and Christer, If this the MG is media unaware isn't this then a "data service"? and D= ATA 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 dedicat= ed tags (e.g. Media/1001), then the MGC can simply omit the parameters tha= t 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:christer.holmberg@ericsson.com] >Envoy=E9 : mardi 25 juillet 2006 09:34 >=C0 : Christian Groves; Albrecht.Schwarz@alcatel.de Cc : CHATRAS Bruno= >RD-CORE-ISS; megaco@ietf.org; Campos, Simao Objet : Re: [Megaco] ETSI >H.248 Ia Profile: issue with media value '-'in SDP"m=3D" line > >Hi Christian, > >As Bruno also said, in future the Ia profile may become media aware, s= o 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=3D" line >Author: "Christian Groves" >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 Bru= no had concerns other the ability of ability of previous Ia implementation= s 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 use= d 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 ignor= ed. > >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 re= ply? >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 no= w we have to change things in command requests and responses. Do we also nee= d 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 requeste= d. >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) the= n "-" is never sent and this can be fixed in the Ia profile which introdu= ced this problem. > >Regards, Christian > >Albrecht.Schwarz@alcatel.de 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 (i= n >>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/Christ= er. >>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 Bo= yle" , "CHATRAS Bruno RD-CORE-ISS" >> , Albrecht SCHWARZ/DE/ALCATEL@ALCATEL >> icsson.com> cc: megaco@ietf.org >> Subject: RE: [Mega= co] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=3D" 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 "-" valu= e >>means. >> >>Regards, >> >>Christer >> >> >>-----Original Message----- >>From: Kevin Boyle [mailto:kboyle@nortel.com] >>Sent: 21. hein=E4kuuta 2006 17:23 >>To: Christer Holmberg (JO/LMF); CHATRAS Bruno RD-CORE-ISS; >>Albrecht.Schwarz@alcatel.de >>Cc: megaco@ietf.org >>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value >>'-'in SDP"m=3D" 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:christer.holmberg@ericsson.com] >>Sent: Friday, July 21, 2006 5:18 AM >>To: CHATRAS Bruno RD-CORE-ISS; Albrecht.Schwarz@alcatel.de >>Cc: megaco@ietf.org >>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value >>'-'in SDP"m=3D" 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 RF= C >>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:bruno.chatras@orange-ft.com] >>Sent: 21. hein=E4kuuta 2006 10:26 >>To: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de >>Cc: megaco@ietf.org >>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value >>'-'in SDP"m=3D" 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 implemente= d the CR yet. >> >>Regards, >>Bruno >> >>-----Message d'origine----- >>De : Christer Holmberg (JO/LMF) >>[mailto:christer.holmberg@ericsson.com] >>Envoy=E9 : jeudi 20 juillet 2006 20:46 >>=C0 : Albrecht.Schwarz@alcatel.de >>Cc : megaco@ietf.org >>Objet : RE: [Megaco] ETSI H.248 Ia Profile: issue with media value >>'-'in SDP"m=3D" 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: Albrecht.Schwarz@alcatel.de [mailto:Albrecht.Schwarz@alcatel.de= ] >>Sent: 20. hein=E4kuuta 2006 12:00 >>To: Christer Holmberg (JO/LMF) >>Cc: megaco@ietf.org >>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value >>'-'in SDP "m=3D" 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 unclea= r >>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-agnos= tic" >>SDP descriptors, so 'OMIT' is not totally new, and >>* 'OMIT' is inline with separating into media-agnostic and media-awar= e >>IP terminations, and >>* '-' would be an extension of the SDP grammar of RFC 2327 based H.24= 8 >>profiles. >> >>We will submitt a correspondent CR to next TISPAN meeting. >> >>Regards, >>Albrecht >> >> >> >> >> "Christer Holmberg >> >> \(JO/LMF\)" To: "Kevin Bo= yle" >>, "B Venkat S.R Swamy" >> >, "Christian Groves" >> >> icsson.com> cc: Albrecht >>SCHWARZ/DE/ALCATEL@ALCATEL, megaco@ietf.org >> Subject: RE: >>[Megaco] ETSI H.248 Ia Profile: issue with media value '-'inSDP"m=3D= " line >> 17.07.2006 22:00 >> >> >> >> >> >> >> >>Hi, >> >>According to draft-ietf-mmusic-sdp-new-26, which will replace RFC 232= 7, "-" >>IS allowed. Both the media and the fmt parts of the m=3D line are >>defined as tokens. >> >>media =3D token >> ;typically "audio", "video", "text" or >> ;"application" >> >>fmt =3D token >> ;typically an RTP payload type for audio >> ;and video media >> >>token =3D 1*(token-char) >> >>token-char =3D %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:kboyle@nortel.com] >>Sent: 17. hein=E4kuuta 2006 19:58 >>To: B Venkat S.R Swamy; Christian Groves >>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; Christer Holmberg >>(JO/LMF) >>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value >>'-'inSDP"m=3D" 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:b.swamy@flextronicssoftware.com] >>Sent: Monday, July 17, 2006 12:40 AM >>To: Christian Groves >>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; >>christer.holmberg@ericsson.com >>Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '= -' >>inSDP"m=3D" line >> >> >> >>Hi >> >>Although you are right these are don't care values, but the point her= e >>was SDP grammar does not support "-" in the media as shown below. >> >>"m=3D" media space port ["/" integer] space proto 1*(space fmt) CRLF >> >>media =3D 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 >> >> >> >> >> Christian Groves >> >> >> 07/17/2006 06:36 AM >> >> >> >>To >> >>Albrecht.Schwarz@alcatel.de >> >> >>cc >> >>B Venkat S.R Swamy/HSS@HSS, megaco@ietf.org, >>christer.holmberg@ericsson.com >> >> >>Subject >> >>Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-' inSDP"= m=3D" >>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 >> >>Albrecht.Schwarz@alcatel.de wrote: >> >> >> >> >> >>>Thanks for pointing to =A7 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 tha= t >>> >>> >>> >>> >>it >> >> >> >> >>> is not necessary to specify the value of the parameter in the SD= P >>> 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" >>> >>> >>> >>> >> >> >> >> >>> >> >>> >>> >>> >>SCHWARZ/DE/ALCATEL@ALCATEL >> >> >> >> >>> ftware.com> cc: >>> >>> >>> >>> >>megaco@ietf.org, christer.holmberg@ericsson.com >> >> >> >> >> >>> Subject: Re: >>> >>> >>> >>> >>[Megaco] ETSI H.248 Ia Profile: issue with media value '-' in SDP"m=3D= " >> >> >> >> >>> 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)Albrecht.Schwarz@alcatel.de >>> >>> >>> >>> >>> >>> >> >> >> >> >>> 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 >>> >>> >>> >>> >>christer.holmberg@ericsson.com, >> >> >> >> >>> taylor@nortel.com >>> >>> >>> >>> >> >> >> >> >>> (Embedded image moved to file: >>> >>> >>> >>> >> >> >> >> >>> pic31609.gif) >>> >>> >>> >>> >> >> >>cc >> >> >> >> >>> (Embedded image moved to >>> >>> >>> >>> >>file: >> >> >> >> >>> pic17314.gif) >>> >>> >>> >>> >> >> >> >> >>> megaco@ietf.org >>> >>> >>> >>> >> >> >> >> >>> (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=3D" 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 =3D *( media-field >>> >>> >>> information-field >>> >>> >>> *(connection-field) >>> >>> >>> bandwidth-fields >>> >>> >>> key-field >>> >>> >>> attribute-fields ) >>> >>> >>> media-field =3D "m=3D" media space port ["/" integer] >>> >>> >>> space proto 1*(space fmt) CRLF >>> >>> >>> media =3D 1*(alpha-numeric) >>> >>> >>> ;typically "audio", "video", "application" >>> >>> >>> ;or "data" >>> >>> >>>RFC 3108: >>> >>> >>>media-descriptions =3D *(media-description) >>> >>> >>>media-description =3D media-field information-field >>> >>> >>> >>> >>*(connection-field) >> >> >> >> >>> bandwidth-fields key-field attribute-fields >>> >>> >>>media-field =3D 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 =3D "m=3D" media space vcId space transport-fmts EOL= >>> >>> >>> ; superset of RFC 2327 definition >>> >>> >>>media =3D "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, to= o. >>> >>> >>>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=3D" line | | equals t= o >>> >>> >>> >>> >>zero: >> >> >> >> >>>| >>>| | | v=3D0 >>>| >>>|---------------------------+---------------------------+-----------= - >>>|---------------------------+---------------------------+- >>>|---------------------------+---------------------------+- >>> >>> >>> >>> >>---------------| >> >> >> >> >>>| Connection | Mandatory | The networ= k >>> >>> >>> >>> >>type >> >> >> >> >>>must always| >>>| "c=3D" line | | be "IN".= >>>| >>>| | | >>>| >>>| | |The address= >>> >>> >>> >>> >>type >> >> >> >> >>>value must | >>>| | |be "IP4" or= >>> >>> >>> >>> >>"IP6". >> >> >> >> >>>| >>>| | | >>>| >>>| | |The connect= ion >>>address value | >>>| | |may be >>>underspecified with | >>>| | |CHOOSE >>> >>> >>> >>> >>wildcard >> >> >> >> >>>("$"). | >>>|---------------------------+---------------------------+-----------= - >>>|---------------------------+---------------------------+- >>>|---------------------------+---------------------------+- >>> >>> >>> >>> >>---------------| >> >> >> >> >>>| Media | Mandatory |"-" may be >>> >>> >>> >>> >>used >> >> >> >> >>>for the media| >>>| "m=3D" line | |value. Ot= her >>>values shall be | >>>| | |ignored, >>> >>> >>> >>> >>unless >> >> >> >> >>>media | >>>| | |specific >>>information is | >>>| | |required. >>>| >>>| | | >>>| >>>| | |The port va= lue >>> >>> >>> >>> >>may >> >> >> >> >>>be | >>>| | |underspecif= ied >>>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 lis= t >>>value. Other | >>>| | | values sha= ll >>> >>> >>> >>> >>be >> >> >> >> >>>ignored. | >>>|---------------------------+---------------------------+-----------= - >>>|---------------------------+---------------------------+- >>>|---------------------------+---------------------------+- >>> >>> >>> >>> >>---------------| >> >> >> >> >>> >>> >>> >>> >>> >>> >>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>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 an= y >>>purpose other than for what it is intended. If you have received thi= s >>>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 >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>---------------------------------------------------------------------= - >>- >>- >> >> >> >> >>> >>> >>> >>> >>---------------------------------------------------------------------= - >>- >>- >> >> >> >> >>> >>> >>> >>> >>---------------------------------------------------------------------= - >>- >>- >> >> >> >> >>> >>> >>> >>> >>---------------------------------------------------------------------= - >>- >>- >> >> >> >> >>> >>> >>> >>> >>---------------------------------------------------------------------= - >>- >>- >> >> >> >> >>> >>> >>> >>> = >>---------------------------------------------------------------------= - >>- >>- >> >> >> >> >>> >>> >>> >>> >>---------------------------------------------------------------------= - >>- >>- >> >> >> >> >>> >>> >>> >>> >>---------------------------------------------------------------------= - >>- >>- >> >> >> >> >>> >>> >>> >>> >>---------------------------------------------------------------------= - >>- >>- >> >> >> >> >>>--------------------------------------------------------------------= - >>>- >>>- >>> >>> >>> >>> >>- >> >> >> >> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>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 >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >> >> >> >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >> >> >> >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >> >> >> >> >> >> >> > > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco > > > > > > = _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Aug 04 13:09:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G93AS-0005Tz-BK; Fri, 04 Aug 2006 13:09:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G93AQ-0005Tu-W0 for Megaco@ietf.org; Fri, 04 Aug 2006 13:08:58 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G93AO-0004T5-Mb for Megaco@ietf.org; Fri, 04 Aug 2006 13:08:58 -0400 Received: by ug-out-1314.google.com with SMTP id m2so124009uge for ; Fri, 04 Aug 2006 10:08:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=VGHdXcNZuDdMtDLs0esym2tMxL4+y/eJOjqGVA9dUwZFJPQVzcKZ1qYCXJfTZjWvgZ58nvm/HgfK5CqkFPWa0VSYEFU75EVggzEz4GvrB/XVBZRFkt21zLfT1gKI40AbncpiN5iRuBzhaYgTaeeKwqwpfjjok7t7ruKCqvlKP8s= Received: by 10.67.119.13 with SMTP id w13mr4791979ugm; Fri, 04 Aug 2006 10:08:55 -0700 (PDT) Received: by 10.66.250.2 with HTTP; Fri, 4 Aug 2006 10:08:55 -0700 (PDT) Message-ID: <1a9ac220608041008v7dd0affcq103bab725319d298@mail.gmail.com> Date: Fri, 4 Aug 2006 14:08:55 -0300 From: "Nicolas Emiliani" To: Megaco@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.6 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Megaco] Auditing E1 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2124077081==" Errors-To: megaco-bounces@ietf.org --===============2124077081== Content-Type: multipart/alternative; boundary="----=_Part_35420_19452436.1154711335867" ------=_Part_35420_19452436.1154711335867 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I want to Audit the termination state descriptor in an E1. When I restart the MG I get a SC for teh root termination an a SC per E1 with reason = "service restored" like this : sc=ROOT sc=TGW/PDC0/* sc=TGW/PDC1/* sc=TGW/PDC2/* sc=TGW/PDC3/* What I wanted to do, with some issues regarding the tgw I'm ussing, is to Audit the termination state descriptor of each E1 to see the service state. Sadly I had no luck. By this I mean using AuditValue=TGW/PDC2/* for example. The question is... is this possible?... Im I supoussed to receive only one service state for all the time slots in the E1 or one per time slot? Thanks guys! Nicolas ------=_Part_35420_19452436.1154711335867 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,
I want to Audit the termination state descriptor in an E1. When I restart the MG I get a SC for teh root termination an a SC per E1 with reason = "service restored" like this :
sc=ROOT
sc=TGW/PDC0/*
sc=TGW/PDC1/*
sc=TGW/PDC2/*
sc=TGW/PDC3/*

What I wanted to do, with some issues regarding the tgw I'm ussing, is to Audit the termination state descriptor of each E1 to see the service state. Sadly I had no luck. By this I mean using AuditValue=TGW/PDC2/* for example.
The question is... is this possible?... Im I supoussed to receive only one service state for all the time slots in the E1 or one per time slot?

Thanks guys!

Nicolas


------=_Part_35420_19452436.1154711335867-- --===============2124077081== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============2124077081==-- From megaco-bounces@ietf.org Mon Aug 07 02:31:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9ydc-0001Qe-Ul; Mon, 07 Aug 2006 02:30:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9ydb-0001QU-91 for megaco@ietf.org; Mon, 07 Aug 2006 02:30:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9ydb-00018C-4L for megaco@ietf.org; Mon, 07 Aug 2006 02:30:55 -0400 Received: from quantum.websiteactive.com ([70.86.207.162]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G9yOq-0000Rr-Rv for megaco@ietf.org; Mon, 07 Aug 2006 02:15:44 -0400 Received: from cpe-61-9-144-63.vic.bigpond.net.au ([61.9.144.63]:11046 helo=[127.0.0.1]) by quantum.websiteactive.com with esmtpa (Exim 4.52) id 1G9yO9-0002tu-FO; Mon, 07 Aug 2006 16:15:03 +1000 Message-ID: <44D6DA59.3050707@nteczone.com> Date: Mon, 07 Aug 2006 16:14:49 +1000 From: Christian Groves User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=" line References: <5EB80D22825EEE42872083AD5BFFB594017F12C0@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F12C0@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - quantum.websiteactive.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.6 (--) X-Scan-Signature: e78d00214c522badaec4cc0f446650c9 Cc: CHATRAS Bruno RD-CORE-ISS , Albrecht.Schwarz@alcatel.de, "Campos, Simao" , megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org 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 Christer Holmberg (JO/LMF) wrote: >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:Christian.Groves@nteczone.com] >Sent: 4. elokuuta 2006 4:28 >To: CHATRAS Bruno RD-CORE-ISS >Cc: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de; megaco@ietf.org; Campos, Simao >Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=" line > >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:christer.holmberg@ericsson.com] >>Envoyé : mardi 25 juillet 2006 09:34 >>À : Christian Groves; Albrecht.Schwarz@alcatel.de Cc : CHATRAS Bruno >>RD-CORE-ISS; megaco@ietf.org; 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" >>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 >> >>Albrecht.Schwarz@alcatel.de 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" , "CHATRAS Bruno RD-CORE-ISS" >>> , Albrecht SCHWARZ/DE/ALCATEL@ALCATEL >>> icsson.com> cc: megaco@ietf.org >>> 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:kboyle@nortel.com] >>>Sent: 21. heinäkuuta 2006 17:23 >>>To: Christer Holmberg (JO/LMF); CHATRAS Bruno RD-CORE-ISS; >>>Albrecht.Schwarz@alcatel.de >>>Cc: megaco@ietf.org >>>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:christer.holmberg@ericsson.com] >>>Sent: Friday, July 21, 2006 5:18 AM >>>To: CHATRAS Bruno RD-CORE-ISS; Albrecht.Schwarz@alcatel.de >>>Cc: megaco@ietf.org >>>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:bruno.chatras@orange-ft.com] >>>Sent: 21. heinäkuuta 2006 10:26 >>>To: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de >>>Cc: megaco@ietf.org >>>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:christer.holmberg@ericsson.com] >>>Envoyé : jeudi 20 juillet 2006 20:46 >>>À : Albrecht.Schwarz@alcatel.de >>>Cc : megaco@ietf.org >>>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: Albrecht.Schwarz@alcatel.de [mailto:Albrecht.Schwarz@alcatel.de] >>>Sent: 20. heinäkuuta 2006 12:00 >>>To: Christer Holmberg (JO/LMF) >>>Cc: megaco@ietf.org >>>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" >>>, "B Venkat S.R Swamy" >>> >>, "Christian Groves" >>> >>> icsson.com> cc: Albrecht >>>SCHWARZ/DE/ALCATEL@ALCATEL, megaco@ietf.org >>> 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:kboyle@nortel.com] >>>Sent: 17. heinäkuuta 2006 19:58 >>>To: B Venkat S.R Swamy; Christian Groves >>>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; 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:b.swamy@flextronicssoftware.com] >>>Sent: Monday, July 17, 2006 12:40 AM >>>To: Christian Groves >>>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; >>>christer.holmberg@ericsson.com >>>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 >>> >>> >>> >>> >>> Christian Groves >>> >>> >>> 07/17/2006 06:36 AM >>> >>> >>> >>>To >>> >>>Albrecht.Schwarz@alcatel.de >>> >>> >>>cc >>> >>>B Venkat S.R Swamy/HSS@HSS, megaco@ietf.org, >>>christer.holmberg@ericsson.com >>> >>> >>>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 >>> >>>Albrecht.Schwarz@alcatel.de 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" >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>> >>> >>>> >>>> >>>> >>>> >>>> >>>SCHWARZ/DE/ALCATEL@ALCATEL >>> >>> >>> >>> >>> >>> >>>> ftware.com> cc: >>>> >>>> >>>> >>>> >>>> >>>> >>>megaco@ietf.org, christer.holmberg@ericsson.com >>> >>> >>> >>> >>> >>> >>> >>>> 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)Albrecht.Schwarz@alcatel.de >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> >>>christer.holmberg@ericsson.com, >>> >>> >>> >>> >>> >>> >>>> taylor@nortel.com >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>> (Embedded image moved to file: >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>> pic31609.gif) >>>> >>>> >>>> >>>> >>>> >>>> >>>cc >>> >>> >>> >>> >>> >>> >>>> (Embedded image moved to >>>> >>>> >>>> >>>> >>>> >>>> >>>file: >>> >>> >>> >>> >>> >>> >>>> pic17314.gif) >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>> megaco@ietf.org >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>> (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 >>>>Megaco@ietf.org >>>>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 >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>---------------------------------------------------------------------- >>>- >>>- >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>---------------------------------------------------------------------- >>>- >>>- >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>---------------------------------------------------------------------- >>>- >>>- >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>---------------------------------------------------------------------- >>>- >>>- >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>---------------------------------------------------------------------- >>>- >>>- >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>---------------------------------------------------------------------- >>>- >>>- >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>---------------------------------------------------------------------- >>>- >>>- >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>---------------------------------------------------------------------- >>>- >>>- >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>---------------------------------------------------------------------- >>>- >>>- >>> >>> >>> >>> >>> >>> >>>>--------------------------------------------------------------------- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>- >>> >>> >>> >>> >>> >>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>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 >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> >>> >>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> >>> >>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >> >> >> >> >> >> >> > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco > > > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Aug 07 03:02:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9z7p-0000NP-Sl; Mon, 07 Aug 2006 03:02:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9z7o-0000NK-EX for megaco@ietf.org; Mon, 07 Aug 2006 03:02:08 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9z7l-0006mu-Cs for megaco@ietf.org; Mon, 07 Aug 2006 03:02:08 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6EDAC4F0045; Mon, 7 Aug 2006 09:02:04 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Aug 2006 09:02:03 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Aug 2006 09:02:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=" line Date: Mon, 7 Aug 2006 09:02:01 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F12D4@esealmw113.eemea.ericsson.se> In-Reply-To: <44D6DA59.3050707@nteczone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=" line Thread-Index: Aca56OLVhicBpJ6KT2qJKqiGaT10XAAA6YRQ From: "Christer Holmberg \(JO/LMF\)" To: "Christian Groves" X-OriginalArrivalTime: 07 Aug 2006 07:02:02.0956 (UTC) FILETIME=[629F30C0:01C6B9EF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 226b78fbce55481db740f694758fa6e8 Cc: CHATRAS Bruno RD-CORE-ISS , Albrecht.Schwarz@alcatel.de, "Campos, Simao" , megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hi Christian,=20 >You could use: > >m =3D 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 =3D 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=20 >specific parameters. I would have thought both media aware and media = unaware gateways would be interested in receiving=20 >valid SDP. > >For H.248.1 v1, v2, v3 implementations which are based on RFC2327 the = use of "-" is not supported for the m=3D line. A=20 >subsequent version of H.248.1 could be based on RFC4566 and would then = allow the use of "-" in m=3D. I'm little hesitant in=20 >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). >Having said that I think Albrecht's approach is a pragmatic way = forward.=20 >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.=20 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: >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=3D line where we need it. H.248.20 = uses "-" in the c=3D line.=20 > >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 > > > > > > >=20 > >-----Original Message----- >From: Christian Groves [mailto:Christian.Groves@nteczone.com] >Sent: 4. elokuuta 2006 4:28 >To: CHATRAS Bruno RD-CORE-ISS >Cc: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de;=20 >megaco@ietf.org; Campos, Simao >Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >'-'in SDP"m=3D" line > >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: > > =20 > >>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.=20 >> >>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:christer.holmberg@ericsson.com] >>Envoy=E9 : mardi 25 juillet 2006 09:34 >>=C0 : Christian Groves; Albrecht.Schwarz@alcatel.de Cc : CHATRAS Bruno = >>RD-CORE-ISS; megaco@ietf.org; Campos, Simao Objet : Re: [Megaco] ETSI >>H.248 Ia Profile: issue with media value '-'in SDP"m=3D" 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=3D" line >>Author: "Christian Groves" >>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.=20 >>"-" 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 >> >>Albrecht.Schwarz@alcatel.de wrote: >> >>=20 >> >> =20 >> >>>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=20 >>>(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=20 >>>explicitly the syntax extension. >>> >>>Thanks, >>>regards, >>> >>>Albrecht >>> >>> >>> >>> >>> = =20 >>> "Christer Holmberg = =20 >>> \(JO/LMF\)" To: "Kevin = Boyle" , "CHATRAS Bruno RD-CORE-ISS" = >>> , Albrecht SCHWARZ/DE/ALCATEL@ALCATEL = =20 >>> icsson.com> cc: = megaco@ietf.org = =20 >>> Subject: RE: = [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=3D" = line =20 >>> 21.07.2006 16:42 = =20 >>> = =20 >>> >>> >>> >>> >>> >>>Hi, >>> >>>What we need to say is that "-" is allowed in H.248 usage of SDP(in=20 >>>case >>>H.248.1 still refers to RFC 2327), and we need to say what a "-"=20 >>>value means. >>> >>>Regards, >>> >>>Christer >>> >>> >>>-----Original Message----- >>>From: Kevin Boyle [mailto:kboyle@nortel.com] >>>Sent: 21. hein=E4kuuta 2006 17:23 >>>To: Christer Holmberg (JO/LMF); CHATRAS Bruno RD-CORE-ISS;=20 >>>Albrecht.Schwarz@alcatel.de >>>Cc: megaco@ietf.org >>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>>'-'in SDP"m=3D" 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=20 >>>understanding of how this is to be used. Therefore, I think this=20 >>>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=20 >>>that is acceptable in the IG, or if we should look to prepare a=20 >>>Corrigendum in November. >>> >>>Kevin >>> >>>-----Original Message----- >>>From: Christer Holmberg (JO/LMF) >>>[mailto:christer.holmberg@ericsson.com] >>>Sent: Friday, July 21, 2006 5:18 AM >>>To: CHATRAS Bruno RD-CORE-ISS; Albrecht.Schwarz@alcatel.de >>>Cc: megaco@ietf.org >>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>>'-'in SDP"m=3D" line >>> >>> >>>Hi, >>> >>>I agree with Bruno. >>> >>>Also, H.248.1 does already "extend" RFC 2327, by defining some SDP=20 >>>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=20 >>>RFC 4566, in case some other protocol needs it, but it's too late=20 >>>now.) >>> >>>Regards, >>> >>>Christer >>> >>> >>> >>>-----Original Message----- >>>From: CHATRAS Bruno RD-CORE-ISS [mailto:bruno.chatras@orange-ft.com] >>>Sent: 21. hein=E4kuuta 2006 10:26 >>>To: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de >>>Cc: megaco@ietf.org >>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>>'-'in SDP"m=3D" line >>> >>>Moreover, even if a CR was issued agaisnt ES 283 018 to recommend=20 >>>using the OMIT token rather than the "-", the "-" would have to be=20 >>>kept in the Ia profile anyway for backward compatibility purposes. I=20 >>>assume that we would not like an IP2IP MG to reject an H.248 command=20 >>>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:christer.holmberg@ericsson.com] >>>Envoy=E9 : jeudi 20 juillet 2006 20:46 >>>=C0 : Albrecht.Schwarz@alcatel.de >>>Cc : megaco@ietf.org >>>Objet : RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>>'-'in SDP"m=3D" line >>> >>> >>>Hi, >>> >>>Why can't the Ia profile be based on RFC 4566? RFC 3108 is not=20 >>>referenced by the Ia profile, or by H.248.1. >>> >>>Also, my understanding is that RFC 3108 DOES recommend "-", but says=20 >>>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: Albrecht.Schwarz@alcatel.de=20 >>>[mailto:Albrecht.Schwarz@alcatel.de] >>>Sent: 20. hein=E4kuuta 2006 12:00 >>>To: Christer Holmberg (JO/LMF) >>>Cc: megaco@ietf.org >>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>>'-'in SDP "m=3D" line >>> >>> >>>Christer, et al., >>> >>>I was aware of the SDP extension by '-' in "SDP new" (guess will be=20 >>>RFC 4566), when writting my email. >>>(I was not aware of the Q.1950 SDP extensions, but I didn't consider=20 >>>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=20 >>>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=20 >>>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=20 >>>media-aware IP terminations, and >>>* '-' would be an extension of the SDP grammar of RFC 2327 based=20 >>>H.248 profiles. >>> >>>We will submitt a correspondent CR to next TISPAN meeting. >>> >>>Regards, >>>Albrecht >>> >>> >>> >>> >>> "Christer Holmberg >>> >>> \(JO/LMF\)" To: "Kevin = Boyle" >>>, "B Venkat S.R Swamy" >>> >>, "Christian Groves" >>> >>> icsson.com> cc: Albrecht >>>SCHWARZ/DE/ALCATEL@ALCATEL, megaco@ietf.org >>> Subject: RE:=20 >>>[Megaco] ETSI H.248 Ia Profile: issue with media value = '-'inSDP"m=3D" 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=3D line are=20 >>>defined as tokens. >>> >>>media =3D token >>> ;typically "audio", "video", "text" or >>> ;"application" >>> >>>fmt =3D token >>> ;typically an RTP payload type for audio >>> ;and video media >>> >>>token =3D 1*(token-char) >>> >>>token-char =3D %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:kboyle@nortel.com] >>>Sent: 17. hein=E4kuuta 2006 19:58 >>>To: B Venkat S.R Swamy; Christian Groves >>>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; Christer Holmberg >>>(JO/LMF) >>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>>'-'inSDP"m=3D" line >>> >>>The MGC could place "$" there if it truly did not care. This would=20 >>>align better with the intent of both SDP and H.248. >>> >>>Kevin >>> >>>________________________________ >>> >>>From: B Venkat S.R Swamy [mailto:b.swamy@flextronicssoftware.com] >>>Sent: Monday, July 17, 2006 12:40 AM >>>To: Christian Groves >>>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org;=20 >>>christer.holmberg@ericsson.com >>>Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value = '-' >>>inSDP"m=3D" line >>> >>> >>> >>>Hi >>> >>>Although you are right these are don't care values, but the point=20 >>>here was SDP grammar does not support "-" in the media as shown = below. >>> >>>"m=3D" media space port ["/" integer] space proto 1*(space fmt) CRLF >>> >>>media =3D 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 >>> >>> >>> >>> >>> Christian Groves=20 >>> >>> >>> 07/17/2006 06:36 AM >>> >>> >>> >>>To >>> >>>Albrecht.Schwarz@alcatel.de >>> >>> >>>cc >>> >>>B Venkat S.R Swamy/HSS@HSS, megaco@ietf.org,=20 >>>christer.holmberg@ericsson.com >>> >>> >>>Subject >>> >>>Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-' = inSDP"m=3D" >>>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=20 >>>receives normal SDP values in those positions these can simply be=20 >>>ignored. No need to say OMIT. >>> >>>Regards, Christian >>> >>>Albrecht.Schwarz@alcatel.de wrote: >>> >>> >>> >>> =20 >>> >>> =20 >>> >>>>Thanks for pointing to =A7 2.5/RFC 3108! >>>>" The string "OMIT" can be used in lieu of "-" for an omitted >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>parameter." >>> >>> >>> =20 >>> >>> =20 >>> >>>>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 >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>[1] >>> >>> >>> =20 >>> >>> =20 >>> >>>> 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 >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>this >>> >>> >>> =20 >>> >>> =20 >>> >>>> convention, while allowing the use of the special character "/" >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>in a >>> >>> >>> =20 >>> >>> =20 >>> >>>> manner commensurate with [1]. In addition, the special >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>characters >>> >>> >>> =20 >>> >>> =20 >>> >>>> "$" and "-" are used in the following manner. A "$" value is a >>>> wildcard that allows the recipient of the SDP description to >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>select >>> >>> >>> =20 >>> >>> =20 >>> >>>> any permitted value of the parameter. A "-" value indicates that >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>it >>> >>> >>> =20 >>> >>> =20 >>> >>>> 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 >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>source >>> >>> >>> =20 >>> >>> =20 >>> >>>> such as provisioning, defaults, another protocol, another SDP >>>> descriptor or another part of the same SDP descriptor. If the >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>use of >>> >>> >>> =20 >>> >>> =20 >>> >>>> these special characters is construed as a violation of RFC 2327 >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>[1] >>> >>> >>> =20 >>> >>> =20 >>> >>>> syntax, then reserved string values can be used. The string >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>"CHOOSE" >>> >>> >>> =20 >>> >>> =20 >>> >>>> can be used in lieu of "$". The string "OMIT" can be used in >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>lieu of >>> >>> >>> =20 >>> >>> =20 >>> >>>> "-" for an omitted parameter. >>>> >>>> >>>> >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>> =20 >>> >>> =20 >>> >>>> "B Venkat S.R Swamy" >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>> =20 >>> >>> =20 >>> >>>> >>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>SCHWARZ/DE/ALCATEL@ALCATEL >>> >>> >>> =20 >>> >>> =20 >>> >>>> ftware.com> cc: >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>megaco@ietf.org, christer.holmberg@ericsson.com >>> >>> >>> >>> =20 >>> >>> =20 >>> >>>> Subject: Re: >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>[Megaco] ETSI H.248 Ia Profile: issue with media value '-' in = SDP"m=3D" >>> >>> >>> =20 >>> >>> =20 >>> >>>> 14.07.2006 05:59 line >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>> >>> >>> >>> =20 >>> >>> =20 >>> >>>>Hi >>>> >>>>I support the option 2, and we should try to avoid any violation of=20 >>>>the >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>RFC >>> >>> >>> =20 >>> >>> =20 >>> >>>>2327/RFC 3108. >>>>The string "OMIT" as suggested by RFC 3108, section 2.5, can be used >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>for >>> >>> >>> =20 >>> >>> =20 >>> >>>>media. >>>>Also the use of "-" is not allowed as per RFC 2327/RFC 2848 for the >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>proto >>> >>> >>> =20 >>> >>> =20 >>> >>>>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:=20 >>>>pic12377.gif)Albrecht.Schwarz@alcatel.de >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>> =20 >>> >>> =20 >>> >>>> Albrecht >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>> =20 >>> >>> =20 >>> >>>> .Schwarz >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>> =20 >>> >>> =20 >>> >>>> @alcatel >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>> =20 >>> >>> =20 >>> >>>> .de (Embedded image moved to file: >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>> =20 >>> >>> =20 >>> >>>> pic00224.gif) >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>To >>> >>> >>> =20 >>> >>> =20 >>> >>>> 07/13/20 (Embedded image moved to >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>file: >>> >>> >>> =20 >>> >>> =20 >>> >>>> 06 09:49 pic02722.gif) >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>> =20 >>> >>> =20 >>> >>>> PM >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>christer.holmberg@ericsson.com, >>> >>> >>> =20 >>> >>> =20 >>> >>>> taylor@nortel.com >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>> =20 >>> >>> =20 >>> >>>> (Embedded image moved to file: >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>> =20 >>> >>> =20 >>> >>>> pic31609.gif) >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>cc >>> >>> >>> =20 >>> >>> =20 >>> >>>> (Embedded image moved to >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>file: >>> >>> >>> =20 >>> >>> =20 >>> >>>> pic17314.gif) >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>> =20 >>> >>> =20 >>> >>>> megaco@ietf.org >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>> =20 >>> >>> =20 >>> >>>> (Embedded image moved to file: >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>> =20 >>> >>> =20 >>> >>>> pic14997.gif) >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>Subject >>> >>> >>> =20 >>> >>> =20 >>> >>>> (Embedded image moved to >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>file: >>> >>> >>> =20 >>> >>> =20 >>> >>>> pic24297.gif) >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>> =20 >>> >>> =20 >>> >>>> [Megaco] ETSI H.248 Ia >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>Profile: >>> >>> >>> =20 >>> >>> =20 >>> >>>> issue with media value '-' >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>in >>> >>> >>> =20 >>> >>> =20 >>> >>>> SDP"m=3D" line >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>> >>> >>> >>> >>> >>> >>> =20 >>> >>> =20 >>> >>>> (Embedded image moved to file: >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>> =20 >>> >>> =20 >>> >>>> pic24565.gif) >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>> =20 >>> >>> =20 >>> >>>> (Embedded image moved to file: >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>> =20 >>> >>> =20 >>> >>>> pic28141.gif) >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>> >>> >>> >>> >>> >>> >>> =20 >>> >>> =20 >>> >>>>Christer, et al., >>>> >>>>media value '-' is not allowed by RFC 2327 (& RFC 3108) in our >>>>understanding: >>>> >>>>RFC 2327: >>>> >>>> >>>>media-descriptions =3D *( media-field >>>> >>>> >>>> information-field >>>> >>>> >>>> *(connection-field) >>>> >>>> >>>> bandwidth-fields >>>> >>>> >>>> key-field >>>> >>>> >>>> attribute-fields ) >>>> >>>> >>>> media-field =3D "m=3D" media space port ["/" integer] >>>> >>>> >>>> space proto 1*(space fmt) CRLF >>>> >>>> >>>> media =3D 1*(alpha-numeric) >>>> >>>> >>>> ;typically "audio", "video", "application" >>>> >>>> >>>> ;or "data" >>>> >>>> >>>>RFC 3108: >>>> >>>> >>>>media-descriptions =3D *(media-description) >>>> >>>> >>>>media-description =3D media-field information-field >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>*(connection-field) >>> >>> >>> =20 >>> >>> =20 >>> >>>> bandwidth-fields key-field attribute-fields >>>> >>>> >>>>media-field =3D RFC 2327-media-field / RFC 2848-media-field / >>>> >>>> >>>> atm-media-field >>>> >>>> >>>> ; RFC 2327-media-field and RFC 2848-media-field defined in those=20 >>>>rfc's >>>> >>>> >>>>atm-media-field =3D "m=3D" media space vcId space transport-fmts EOL >>>> >>>> >>>> ; superset of RFC 2327 definition >>>> >>>> >>>>media =3D "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=20 >>>>mapping requirements for the "SDP mapper" (ETSI TR 183 046;=20 >>>>WI-03062), or >>>> >>>>(2) alternatively we could change the codepoint '-' to an allowed >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>codepoint >>> >>> >>> =20 >>> >>> =20 >>> >>>>(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 >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>with >>> >>> >>> =20 >>> >>> =20 >>> >>>>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 >>>>|---------------------------+---------------------------+----------- >>>>|---------------------------+---------------------------+- >>>>|---------------------------+---------------------------+- >>>>|---------------------------+---------------------------+- >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>---------------| >>> >>> >>> =20 >>> >>> =20 >>> >>>>| SDP Information Element | Mandatory/optional | >>>>Description | >>>>|---------------------------+---------------------------+----------- >>>>|---------------------------+---------------------------+- >>>>|---------------------------+---------------------------+- >>>>|---------------------------+---------------------------+- >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>---------------| >>> >>> >>> =20 >>> >>> =20 >>> >>>>| Protocol version | Mandatory | The value >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>must >>> >>> >>> =20 >>> >>> =20 >>> >>>>always be | >>>>| "v=3D" line | | equals = to >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>zero: >>> >>> >>> =20 >>> >>> =20 >>> >>>>| >>>>| | | v=3D0 >>>>| >>>>|---------------------------+---------------------------+----------- >>>>|---------------------------+---------------------------+- >>>>|---------------------------+---------------------------+- >>>>|---------------------------+---------------------------+- >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>---------------| >>> >>> >>> =20 >>> >>> =20 >>> >>>>| Connection | Mandatory | The = network >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>type >>> >>> >>> =20 >>> >>> =20 >>> >>>>must always| >>>>| "c=3D" line | | be "IN". >>>>| >>>>| | | >>>>| >>>>| | |The address >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>type >>> >>> >>> =20 >>> >>> =20 >>> >>>>value must | >>>>| | |be "IP4" or >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>"IP6". >>> >>> >>> =20 >>> >>> =20 >>> >>>>| >>>>| | | >>>>| >>>>| | |The = connection >>>>address value | >>>>| | |may be >>>>underspecified with | >>>>| | |CHOOSE >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>wildcard >>> >>> >>> =20 >>> >>> =20 >>> >>>>("$"). | >>>>|---------------------------+---------------------------+----------- >>>>|---------------------------+---------------------------+- >>>>|---------------------------+---------------------------+- >>>>|---------------------------+---------------------------+- >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>---------------| >>> >>> >>> =20 >>> >>> =20 >>> >>>>| Media | Mandatory |"-" may be >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>used >>> >>> >>> =20 >>> >>> =20 >>> >>>>for the media| >>>>| "m=3D" line | |value. = Other >>>>values shall be | >>>>| | |ignored, >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>unless >>> >>> >>> =20 >>> >>> =20 >>> >>>>media | >>>>| | |specific >>>>information is | >>>>| | |required. >>>>| >>>>| | | >>>>| >>>>| | |The port = value >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>may >>> >>> >>> =20 >>> >>> =20 >>> >>>>be | >>>>| | = |underspecified >>>>with CHOOSE | >>>>| | |wildcard >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>("$"). >>> >>> >>> =20 >>> >>> =20 >>> >>>>| >>>>| | | >>>>| >>>>| | |"-" may be >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>used >>> >>> >>> =20 >>> >>> =20 >>> >>>>for the | >>>>| | |transport >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>value, >>> >>> >>> =20 >>> >>> =20 >>> >>>>unless | >>>>| | |transport >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>specific >>> >>> >>> =20 >>> >>> =20 >>> >>>>behaviour | >>>>| | |is required = by >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>the >>> >>> >>> =20 >>> >>> =20 >>> >>>>MG. | >>>>| | |(See note) >>>>| >>>>| | | "-" may be >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>used >>> >>> >>> =20 >>> >>> =20 >>> >>>>for the | >>>>| | | format = list >>>>value. Other | >>>>| | | values = shall >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>be >>> >>> >>> =20 >>> >>> =20 >>> >>>>ignored. | >>>>|---------------------------+---------------------------+----------- >>>>|---------------------------+---------------------------+- >>>>|---------------------------+---------------------------+- >>>>|---------------------------+---------------------------+- >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>---------------| >>> >>> >>> =20 >>> >>> =20 >>> >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>>*********************** FSS-Restricted *********************** >>>>"DISCLAIMER: This message is proprietary to Flextronics Software=20 >>>>Systems Limited (FSS) and is intended solely for the use of the=20 >>>>individual to whom it is addressed. It may contain privileged or=20 >>>>confidential information and should not be circulated or used for=20 >>>>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=20 >>>>damage arising from the use of the information transmitted by this=20 >>>>email including damage from virus." >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>--------------------------------------------------------------------- >>>- >>>- >>>- >>> >>> >>> =20 >>> >>> =20 >>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>--------------------------------------------------------------------- >>>- >>>- >>>- >>> >>> >>> =20 >>> >>> =20 >>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>--------------------------------------------------------------------- >>>- >>>- >>>- >>> >>> >>> =20 >>> >>> =20 >>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>--------------------------------------------------------------------- >>>- >>>- >>>- >>> >>> >>> =20 >>> >>> =20 >>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>--------------------------------------------------------------------- >>>- >>>- >>>- >>> >>> >>> =20 >>> >>> =20 >>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>--------------------------------------------------------------------- >>>- >>>- >>>- >>> >>> >>> =20 >>> >>> =20 >>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>--------------------------------------------------------------------- >>>- >>>- >>>- >>> >>> >>> =20 >>> >>> =20 >>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>--------------------------------------------------------------------- >>>- >>>- >>>- >>> >>> >>> =20 >>> >>> =20 >>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>--------------------------------------------------------------------- >>>- >>>- >>>- >>> >>> >>> =20 >>> >>> =20 >>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>- >>> >>> >>> =20 >>> >>> =20 >>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>*********************** FSS-Restricted *********************** >>>"DISCLAIMER: This message is proprietary to Flextronics Software=20 >>>Systems Limited (FSS) and is intended solely for the use of the=20 >>>individual to whom it is addressed. It may contain privileged or=20 >>>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=20 >>>strictly prohibited from using, copying, altering, or disclosing the=20 >>>contents of this message. FSS accepts no responsibility for loss or=20 >>>damage arising from the use of the information transmitted by this=20 >>>email including damage from virus." >>> >>> >>> >>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> >>> >>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> >>> >>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> >>> >>> >>> >>> =20 >>> >>> =20 >>> >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >> >> >> >>=20 >> >> =20 >> > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco > > > > > =20 > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Aug 07 09:11:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA4tO-000078-08; Mon, 07 Aug 2006 09:11:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA0gI-0008Nf-GC for megaco@ietf.org; Mon, 07 Aug 2006 04:41:50 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA0gF-0000NH-7P for megaco@ietf.org; Mon, 07 Aug 2006 04:41:50 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 719B14F003A; Mon, 7 Aug 2006 10:41:46 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Aug 2006 10:41:45 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Aug 2006 10:41:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F12D6@esealmw113.eemea.ericsson.se> In-Reply-To: <44D6EF88.2040700@nteczone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=" line Thread-Index: Aca59Ya4CiSSWGqUQgGV2KyOXolmwgAALq0Q From: "Christer Holmberg \(JO/LMF\)" To: "Christian Groves" X-OriginalArrivalTime: 07 Aug 2006 08:41:45.0303 (UTC) FILETIME=[5060E670:01C6B9FD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1d62c0425b8eb8306067ffa3963af1fd X-Mailman-Approved-At: Mon, 07 Aug 2006 09:11:36 -0400 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hi,=20 >>>m =3D 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". >> =20 >> >[CNG] Isn't the format of m=3D?: m=3D >and for "From RFC2327: Formats for non-RTP media should be = registered as MIME content types as described in=20 >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 =3D 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=20 >handling. "Data" is supported - you just need to have a description of it... >>>Yes H.248.20 does use "-" in the c =3D 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. >[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 "-"=20 >>>of whether this is a general mechanism or for specific parameters. I=20 >>>would have thought both media aware and media unaFrom megaco-bounces@ietf.org Mon Aug 07 09:11:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA4tO-000078-08; Mon, 07 Aug 2006 09:11:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA0gI-0008Nf-GC for megaco@ietf.org; Mon, 07 Aug 2006 04:41:50 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA0gF-0000NH-7P for megaco@ietf.org; Mon, 07 Aug 2006 04:41:50 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 719B14F003A; Mon, 7 Aug 2006 10:41:46 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Aug 2006 10:41:45 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Aug 2006 10:41:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F12D6@esealmw113.eemea.ericsson.se> In-Reply-To: <44D6EF88.2040700@nteczone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=" line Thread-Index: Aca59Ya4CiSSWGqUQgGV2KyOXolmwgAALq0Q From: "Christer Holmberg \(JO/LMF\)" To: "Christian Groves" X-OriginalArrivalTime: 07 Aug 2006 08:41:45.0303 (UTC) FILETIME=[5060E670:01C6B9FD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1d62c0425b8eb8306067ffa3963af1fd X-Mailman-Approved-At: Mon, 07 Aug 2006 09:11:36 -0400 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hi,=20 >>>m =3D 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". >> =20 >> >[CNG] Isn't the format of m=3D?: m=3D >and for "From RFC2327: Formats for non-RTP media should be = registered as MIME content types as described in=20 >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 =3D 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=20 >handling. "Data" is supported - you just need to have a description of it... >>>Yes H.248.20 does use "-" in the c =3D 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. >[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 "-"=20 >>>of whether this is a general mechanism or for specific parameters. I=20 >>>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=3D line. A subsequent version = of=20 >>>H.248.1 could be based on RFC4566 and would then allow the use of "-" = in m=3D. I'm little hesitant in saying "-" can be=20 >>>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=20 >perspective I don't see any syntax problem by also allowing "-". I = don't even think updating the reference to RFC4566 is=20 >going to change that fact. I do, however, agree that adding text about = "-" to H.248.1 is considered new functionlity -=20 >EVEN if the RFC reference is updated (the new RFC does not specify the = USAGE of "-" either). > > =20 > >[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=20 >support it? A SDP syntax error results because "-" cannot be present in = an RFC2327 in a m=3D line.=20 >If RFC4566 was supported then you wouldn't get the basic syntax error = because "-" IS supported in the m=3Dline. 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=20 >>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=20 >>having profiles refering 4566, even if H.248.1 refers 2327, so I don't = think the "legalizing" Albrecht is talking about=20 >>is needed.=20 >[CNG] Profiles were about enhancing interoperability. Adding things to = syntax, do things in a different way to the core=20 >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 >Regards, Christian > >Christer Holmberg (JO/LMF) wrote: > > =20 > >>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=3D line where we need it. = H.248.20 uses "-" in the c=3D line.=20 >> >>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:Christian.Groves@nteczone.com] >>Sent: 4. elokuuta 2006 4:28 >>To: CHATRAS Bruno ware 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=3D line. A subsequent version = of=20 >>>H.248.1 could be based on RFC4566 and would then allow the use of "-" = in m=3D. I'm little hesitant in saying "-" can be=20 >>>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=20 >perspective I don't see any syntax problem by also allowing "-". I = don't even think updating the reference to RFC4566 is=20 >going to change that fact. I do, however, agree that adding text about = "-" to H.248.1 is considered new functionlity -=20 >EVEN if the RFC reference is updated (the new RFC does not specify the = USAGE of "-" either). > > =20 > >[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=20 >support it? A SDP syntax error results because "-" cannot be present in = an RFC2327 in a m=3D line.=20 >If RFC4566 was supported then you wouldn't get the basic syntax error = because "-" IS supported in the m=3Dline. 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=20 >>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=20 >>having profiles refering 4566, even if H.248.1 refers 2327, so I don't = think the "legalizing" Albrecht is talking about=20 >>is needed.=20 >[CNG] Profiles were about enhancing interoperability. Adding things to = syntax, do things in a different way to the core=20 >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 >Regards, Christian > >Christer Holmberg (JO/LMF) wrote: > > =20 > >>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=3D line where we need it. = H.248.20 uses "-" in the c=3D line.=20 >> >>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:Christian.Groves@nteczone.com] >>Sent: 4. elokuuta 2006 4:28 >>To: CHATRAS Bruno RD-CORE-ISS >>Cc: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de;=20 >>megaco@ietf.org; Campos, Simao >>Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>'-'in SDP"m=3D" line >> >>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: >> >>=20 >> >> =20 >> >>>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.=20 >>> >>>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:christer.holmberg@ericsson.com] >>>Envoy=E9 : mardi 25 juillet 2006 09:34 >>>=C0 : Christian Groves; Albrecht.Schwarz@alcatel.de Cc : CHATRAS = Bruno=20 >>>RD-CORE-ISS; megaco@ietf.org; Campos, Simao Objet : Re: [Megaco] ETSI >>>H.248 Ia Profile: issue with media value '-'in SDP"m=3D" 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=3D" line >>>Author: "Christian Groves" >>>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.=20 >>>"-" 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 >>> >>>Albrecht.Schwarz@alcatel.de wrote: >>> >>> >>> >>> =20 >>> >>> =20 >>> >>>>Hi, >>>> >>>>it's a syntax issue. An implementatRD-CORE-ISS >>Cc: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de;=20 >>megaco@ietf.org; Campos, Simao >>Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>'-'in SDP"m=3D" line >> >>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: >> >>=20 >> >> =20 >> >>>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.=20 >>> >>>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:christer.holmberg@ericsson.com] >>>Envoy=E9 : mardi 25 juillet 2006 09:34 >>>=C0 : Christian Groves; Albrecht.Schwarz@alcatel.de Cc : CHATRAS = Bruno=20 >>>RD-CORE-ISS; megaco@ietf.org; Campos, Simao Objet : Re: [Megaco] ETSI >>>H.248 Ia Profile: issue with media value '-'in SDP"m=3D" 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=3D" line >>>Author: "Christian Groves" >>>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.=20 >>>"-" 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 >>> >>>Albrecht.Schwarz@alcatel.de wrote: >>> >>> >>> >>> =20 >>> >>> =20 >>> >>>>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=20 >>>>(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=20 >>>>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 >>>> >>>> >>>> >>>> >>>> = =20 >>>> "Christer Holmberg = =20 >>>> \(JO/LMF\)" To: "Kevin = Boyle" , "CHATRAS Bruno RD-CORE-ISS" = >>>> , Albrecht SCHWARZ/DE/ALCATEL@ALCATEL = =20 >>>> icsson.com> cc: = megaco@ietf.org = =20 >>>> Subject: RE: = [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=3D" = line =20 >>>> 21.07.2006 16:42 = =20 >>>> = =20 >>>> >>>> >>>> >>>> >>>> >>>>Hi, >>>> >>>>What we need to say is that "-" is allowed in H.248 usage of SDP(in=20 >>>>case >>>>H.248.1 still refers to RFC 2327), and we need to say what a "-"=20 >>>>value means. >>>> >>>>Regards, >>>> >>>>Christer >>>> >>>> >>>>-----Original Message----- >>>>From: Kevin Boyle [mailto:kboyle@nortel.com] >>>>Sent: 21. hein=E4kuuta 2006 17:23 >>>>To: Christer Holmberg (JO/LMF); CHATRAS Bruno RD-CORE-ISS;=20 >>>>Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>>>'-'in SDP"m=3D" line >>>> >>>>I will draft something to be included in the next IG. Even though=20 >>>>we are talking about something syntactical in nature, the syntax is=20 >>>>that of SDP and not H.248. It also appears that there is a common=20 >>>>understanding of how this is to be used. Therefore, I think this=20 >>>>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=20 >>>>Corrigendum in November. >>>> >>>>Kevin >>>> >>>>-----Original Message----- >>>>From: Christer Holmberg (JO/LMF) >>>>[mailto:christer.holmberg@ericsson.com] >>>>Sent: Friday, July 21, 2006 5:18 AM >>>>To: CHATRAS Bruno RD-CORE-ISS; Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>>>'-'in SDP"m=3D" line >>>> >>>> >>>>Hi, >>>> >>>>I agree with Bruno. >>>> >>>>Also, H.248.1 does already "extend" RFC 2327, by defining some SDP=20 >>>>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=20 >>>>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:bruno.chatras@orange-ft.com] >>>>Sent: 21. hein=E4kuuta 2006 10:26 >>>>To: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>ion following strictly ES 283 018 >>>>v1.1.1 may not work due to RFC 2327 and H.248.1 (09/2005) baseline=20 >>>>(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=20 >>>>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 >>>> >>>> >>>> >>>> >>>> = =20 >>>> "Christer Holmberg = =20 >>>> \(JO/LMF\)" To: "Kevin = Boyle" , "CHATRAS Bruno RD-CORE-ISS" = >>>> , Albrecht SCHWARZ/DE/ALCATEL@ALCATEL = =20 >>>> icsson.com> cc: = megaco@ietf.org = =20 >>>> Subject: RE: = [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=3D" = line =20 >>>> 21.07.2006 16:42 = =20 >>>> = =20 >>>> >>>> >>>> >>>> >>>> >>>>Hi, >>>> >>>>What we need to say is that "-" is allowed in H.248 usage of SDP(in=20 >>>>case >>>>H.248.1 still refers to RFC 2327), and we need to say what a "-"=20 >>>>value means. >>>> >>>>Regards, >>>> >>>>Christer >>>> >>>> >>>>-----Original Message----- >>>>From: Kevin Boyle [mailto:kboyle@nortel.com] >>>>Sent: 21. hein=E4kuuta 2006 17:23 >>>>To: Christer Holmberg (JO/LMF); CHATRAS Bruno RD-CORE-ISS;=20 >>>>Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>>>'-'in SDP"m=3D" line >>>> >>>>I will draft something to be included in the next IG. Even though=20 >>>>we are talking about something syntactical in nature, the syntax is=20 >>>>that of SDP and not H.248. It also appears that there is a common=20 >>>>understanding of how this is to be used. Therefore, I think this=20 >>>>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=20 >>>>Corrigendum in November. >>>> >>>>Kevin >>>> >>>>-----Original Message----- >>>>From: Christer Holmberg (JO/LMF) >>>>[mailto:christer.holmberg@ericsson.com] >>>>Sent: Friday, July 21, 2006 5:18 AM >>>>To: CHATRAS Bruno RD-CORE-ISS; Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>>>'-'in SDP"m=3D" line >>>> >>>> >>>>Hi, >>>> >>>>I agree with Bruno. >>>> >>>>Also, H.248.1 does already "extend" RFC 2327, by defining some SDP=20 >>>>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=20 >>>>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:bruno.chatras@orange-ft.com] >>>>Sent: 21. hein=E4kuuta 2006 10:26 >>>>To: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>>>'-'in SDP"m=3D" line >>>> >>>>Moreover, even if a CR was issued agaisnt ES 283 018 to recommend=20 >>>>using the OMIT token rather than the "-", the "-" would have to be=20 >>>>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:christer.holmberg@ericsson.com] >>>>Envoy=E9 : jeudi 20 juillet 2006 20:46 =C0 : = Albrecht.Schwarz@alcatel.de=20 >>>>Cc : megaco@ietf.org Objet : RE: [Megaco] ETSI H.248 Ia Profile:=20 >>>>issue with media value '-'in SDP"m=3D" line >>>> >>>> >>>>Hi, >>>> >>>>Why can't the Ia profile be based on RFC 4566? RFC 3108 is not=20 >>>>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: Albrecht.Schwarz@alcatel.de >>>>[mailto:Albrecht.Schwarz@alcatel.de] >>>>Sent: 20. hein=E4kuuta 2006 12:00 >>>>To: Christer Holmberg (JO/LMF) >>>>Cc: megaco@ietf.org >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>>>'-'in SDP "m=3D" line >>>> >>>> >>>>Christer, et al., >>>> >>>>I was aware of the SDP extension by '-' in "SDP new" (guess will be=20 >>>>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=20 >>>>unclear to me ("I guess that first H.248.1 will obsolete RFC 2327=20 >>>>and then replace it by RFC 4566, but whether this is a=20 >>>>straightforward task or not, I don't know. Next step then H.248=20 >>>>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=20 >>>>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" >>>>, "B Venkat S.R Swamy" >>>> >>>, "Christian Groves" >>>> >>>> icsson.com> cc: Albrecht >>>>SCHWARZ/DE/ALCATEL@ALCATEL, megaco@ietf.org >>>> Subject: RE:=20 >>>>[Megaco] ETSI H.248 Ia Profile: issue with media value = '-'inSDP"m=3D" 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=3D line are=20 >>>>defined as tokens. >>>> >>>>media =3D token >>>> ;typically "audio", "video", "text" or >>>> ;"application" >>>> >>>>fmt =3D token >>>> ;typically an RTP payload type for audio >>>> ;and video media >>>> >>>>token =3D 1*(token-char) >>>> >>>>token-char =3D %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 = / >>>>%x41-5A / %x5E-7E >>>> >>>>(The ascii code for "-" is %x2D) >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>>>'-'in SDP"m=3D" line >>>> >>>>Moreover, even if a CR was issued agaisnt ES 283 018 to recommend=20 >>>>using the OMIT token rather than the "-", the "-" would have to be=20 >>>>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:christer.holmberg@ericsson.com] >>>>Envoy=E9 : jeudi 20 juillet 2006 20:46 =C0 : = Albrecht.Schwarz@alcatel.de=20 >>>>Cc : megaco@ietf.org Objet : RE: [Megaco] ETSI H.248 Ia Profile:=20 >>>>issue with media value '-'in SDP"m=3D" line >>>> >>>> >>>>Hi, >>>> >>>>Why can't the Ia profile be based on RFC 4566? RFC 3108 is not=20 >>>>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: Albrecht.Schwarz@alcatel.de >>>>[mailto:Albrecht.Schwarz@alcatel.de] >>>>Sent: 20. hein=E4kuuta 2006 12:00 >>>>To: Christer Holmberg (JO/LMF) >>>>Cc: megaco@ietf.org >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>>>'-'in SDP "m=3D" line >>>> >>>> >>>>Christer, et al., >>>> >>>>I was aware of the SDP extension by '-' in "SDP new" (guess will be=20 >>>>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=20 >>>>unclear to me ("I guess that first H.248.1 will obsolete RFC 2327=20 >>>>and then replace it by RFC 4566, but whether this is a=20 >>>>straightforward task or not, I don't know. Next step then H.248=20 >>>>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=20 >>>>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" >>>>, "B Venkat S.R Swamy" >>>> >>>, "Christian Groves" >>>> >>>> icsson.com> cc: Albrecht >>>>SCHWARZ/DE/ALCATEL@ALCATEL, megaco@ietf.org >>>> Subject: RE:=20 >>>>[Megaco] ETSI H.248 Ia Profile: issue with media value = '-'inSDP"m=3D" 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=3D line are=20 >>>>defined as tokens. >>>> >>>>media =3D token >>>> ;typically "audio", "video", "text" or >>>> ;"application" >>>> >>>>fmt =3D token >>>> ;typically an RTP payload type for audio >>>> ;and video media >>>> >>>>token =3D 1*(token-char) >>>> >>>>token-char =3D %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:kboyle@nortel.com] >>>>Sent: 17. hein=E4kuuta 2006 19:58 >>>>To: B Venkat S.R Swamy; Christian Groves >>>>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; Christer Holmberg >>>>(JO/LMF) >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>>>'-'inSDP"m=3D" line >>>> >>>>The MGC could place "$" there if it truly did not care. This would=20 >>>>align better with the intent of both SDP and H.248. >>>> >>>>Kevin >>>> >>>>________________________________ >>>> >>>>From: B Venkat S.R Swamy [mailto:b.swamy@flextronicssoftware.com] >>>>Sent: Monday, July 17, 2006 12:40 AM >>>>To: Christian Groves >>>>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org;=20 >>>>christer.holmberg@ericsson.com >>>>Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value = '-' >>>>inSDP"m=3D" line >>>> >>>> >>>> >>>>Hi >>>> >>>>Although you are right these are don't care values, but the point=20 >>>>here was SDP grammar does not support "-" in the media as shown = below. >>>> >>>>"m=3D" media space port ["/" integer] space proto 1*(space fmt) CRLF >>>> >>>>media =3D 1*(alpha-numeric) >>>>;typically "audio", "video", "application" >>>>;or "data" >>>> >>>>therefore the string "OMIT" was suggested for the media, so as not=20 >>>>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 >>>> >>>> >>>> >>>> >>>> Christian Groves=20 >>>> >>>> >>>> 07/17/2006 06:36 AM >>>> >>>> >>>> >>>>To >>>> >>>>Albrecht.Schwarz@alcatel.de >>>> >>>> >>>>cc >>>> >>>>B Venkat S.R Swamy/HSS@HSS, megaco@ietf.org,=20 >>>>christer.holmberg@ericsson.com >>>> >>>> >>>>Subject >>>> >>>>Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-' = inSDP"m=3D" >>>>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=20 >>>>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=20 >>>>receives normal SDP values in those positions these can simply be=20 >>>>ignored. No need to say OMIT. >>>> >>>>Regards, Christian >>>> >>>>Albrecht.Schwarz@alcatel.de wrote: >>>> >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>Thanks for pointing to =A7 2.5/RFC 3108! >>>>>" The string "OMIT" can be used in lieu of "-" for an omitted >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>parameter." >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>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 >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>[1] >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> do not include special characters that are neither alphabets nor = >>>>> digits. An exception is the "/" character used in the value =20 >>>>> "RTP/AVP" of transport sub-field of the 'm' line. >>>>> >>>>> String values used in SDP descriptions of ATM connections retain >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>this >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> convention, while allowing the use of the special character "/" >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>in a >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> manner commensurate with [1]. In addition, the special >>>>>=20 >>>>> >>>>> > >>>> >>>>Regards, >>>> >>>>Christer >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Kevin Boyle [mailto:kboyle@nortel.com] >>>>Sent: 17. hein=E4kuuta 2006 19:58 >>>>To: B Venkat S.R Swamy; Christian Groves >>>>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; Christer Holmberg >>>>(JO/LMF) >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value=20 >>>>'-'inSDP"m=3D" line >>>> >>>>The MGC could place "$" there if it truly did not care. This would=20 >>>>align better with the intent of both SDP and H.248. >>>> >>>>Kevin >>>> >>>>________________________________ >>>> >>>>From: B Venkat S.R Swamy [mailto:b.swamy@flextronicssoftware.com] >>>>Sent: Monday, July 17, 2006 12:40 AM >>>>To: Christian Groves >>>>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org;=20 >>>>christer.holmberg@ericsson.com >>>>Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value = '-' >>>>inSDP"m=3D" line >>>> >>>> >>>> >>>>Hi >>>> >>>>Although you are right these are don't care values, but the point=20 >>>>here was SDP grammar does not support "-" in the media as shown = below. >>>> >>>>"m=3D" media space port ["/" integer] space proto 1*(space fmt) CRLF >>>> >>>>media =3D 1*(alpha-numeric) >>>>;typically "audio", "video", "application" >>>>;or "data" >>>> >>>>therefore the string "OMIT" was suggested for the media, so as not=20 >>>>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 >>>> >>>> >>>> >>>> >>>> Christian Groves=20 >>>> >>>> >>>> 07/17/2006 06:36 AM >>>> >>>> >>>> >>>>To >>>> >>>>Albrecht.Schwarz@alcatel.de >>>> >>>> >>>>cc >>>> >>>>B Venkat S.R Swamy/HSS@HSS, megaco@ietf.org,=20 >>>>christer.holmberg@ericsson.com >>>> >>>> >>>>Subject >>>> >>>>Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-' = inSDP"m=3D" >>>>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=20 >>>>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=20 >>>>receives normal SDP values in those positions these can simply be=20 >>>>ignored. No need to say OMIT. >>>> >>>>Regards, Christian >>>> >>>>Albrecht.Schwarz@alcatel.de wrote: >>>> >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>Thanks for pointing to =A7 2.5/RFC 3108! >>>>>" The string "OMIT" can be used in lieu of "-" for an omitted >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>parameter." >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>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 >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>[1] >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> do not include special characters that are neither alphabets nor = >>>>> digits. An exception is the "/" character used in the value =20 >>>>> "RTP/AVP" of transport sub-field of the 'm' line. >>>>> >>>>> String values used in SDP descriptions of ATM connections retain >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>this >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> convention, while allowing the use of the special character "/" >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>in a >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> manner commensurate with [1]. In addition, the special >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>characters >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> "$" and "-" are used in the following manner. A "$" value is a =20 >>>>> wildcard that allows the recipient of the SDP description to >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>select >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> any permitted value of the parameter. A "-" value indicates that >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>it >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> is not necessary to specify the value of the parameter in the SDP = =20 >>>>> description because this parameter is irrelevant for this =20 >>>>> application, or because its value can be known from another >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>source >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> such as provisioning, defaults, another protocol, another SDP =20 >>>>> descriptor or another part of the same SDP descriptor. If the >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>use of >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> these special characters is construed as a violation of RFC 2327 >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>[1] >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> syntax, then reserved string values can be used. The string >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>"CHOOSE" >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> can be used in lieu of "$". The string "OMIT" can be used in >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>lieu of >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> "-" for an omitted parameter. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> "B Venkat S.R Swamy" >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> >>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>SCHWARZ/DE/ALCATEL@ALCATEL >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> ftware.com> cc: >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>megaco@ietf.org, christer.holmberg@ericsson.com >>>> >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> Subject: Re: >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>[Megaco] ETSI H.248 Ia Profile: issue with media value '-' in = SDP"m=3D" >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> 14.07.2006 05:59 line >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>Hi >>>>> >>>>>I support the option 2, and we should try to avoid any violation of = >>>>>the >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>RFC >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>2327/RFC 3108. >>>>>The string "OMIT" as suggested by RFC 3108, section 2.5, can be=20 >>>>>used >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>for >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>media. >>>>>Also the use of "-" is not allowed as per RFC 2327/RFC 2848 for the >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>proto >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>field. >>>>> >>>>> >>>>>regards >>>>>B Venkat S.R Swamy >>>>>Sen=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>characters >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> "$" and "-" are used in the following manner. A "$" value is a =20 >>>>> wildcard that allows the recipient of the SDP description to >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>select >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> any permitted value of the parameter. A "-" value indicates that >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>it >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> is not necessary to specify the value of the parameter in the SDP = =20 >>>>> description because this parameter is irrelevant for this =20 >>>>> application, or because its value can be known from another >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>source >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> such as provisioning, defaults, another protocol, another SDP =20 >>>>> descriptor or another part of the same SDP descriptor. If the >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>use of >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> these special characters is construed as a violation of RFC 2327 >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>[1] >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> syntax, then reserved string values can be used. The string >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>"CHOOSE" >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> can be used in lieu of "$". The string "OMIT" can be used in >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>lieu of >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> "-" for an omitted parameter. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> "B Venkat S.R Swamy" >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> >>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>SCHWARZ/DE/ALCATEL@ALCATEL >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> ftware.com> cc: >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>megaco@ietf.org, christer.holmberg@ericsson.com >>>> >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> Subject: Re: >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>[Megaco] ETSI H.248 Ia Profile: issue with media value '-' in = SDP"m=3D" >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> 14.07.2006 05:59 line >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>Hi >>>>> >>>>>I support the option 2, and we should try to avoid any violation of = >>>>>the >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>RFC >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>2327/RFC 3108. >>>>>The string "OMIT" as suggested by RFC 3108, section 2.5, can be=20 >>>>>used >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>for >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>media. >>>>>Also the use of "-" is not allowed as per RFC 2327/RFC 2848 for the >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>proto >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>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:=20 >>>>>pic12377.gif)Albrecht.Schwarz@alcatel.de >>>>> >>>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> Albrecht >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> .Schwarz >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> @alcatel >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> .de (Embedded image moved to file: >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> pic00224.gif) >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>To >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> 07/13/20 (Embedded image moved to >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>file: >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> 06 09:49 pic02722.gif) >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> PM >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>christer.holmberg@ericsson.com, >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> taylor@nortel.com >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> (Embedded image moved to file: >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> pic31609.gif) >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>cc >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> (Embedded image moved to >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>file: >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> pic17314.gif) >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> megaco@ietf.org >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> (Embedded image moved to file: >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> pic14997.gif) >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>Subject >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> (Embedded image moved to >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>file: >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> pic24297.gif) >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> [Megaco] ETSI H.248 Ia >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>Profile: >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> ior Technical Leader >>>>>Flextronics Software Systems >>>>>Phone: +91-124- 4176213 >>>>>Fax: +91-124-4300247 >>>>>web: www.flextronicssoftware.com >>>>>(Embedded image moved to file:=20 >>>>>pic12377.gif)Albrecht.Schwarz@alcatel.de >>>>> >>>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> Albrecht >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> .Schwarz >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> @alcatel >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> .de (Embedded image moved to file: >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> pic00224.gif) >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>To >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> 07/13/20 (Embedded image moved to >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>file: >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> 06 09:49 pic02722.gif) >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> PM >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>christer.holmberg@ericsson.com, >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> taylor@nortel.com >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> (Embedded image moved to file: >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> pic31609.gif) >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>cc >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> (Embedded image moved to >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>file: >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> pic17314.gif) >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> megaco@ietf.org >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> (Embedded image moved to file: >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> pic14997.gif) >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>Subject >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> (Embedded image moved to >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>file: >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> pic24297.gif) >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> [Megaco] ETSI H.248 Ia >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>Profile: >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> issue with media value '-' >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>in >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> SDP"m=3D" line >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> >>>> >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> (Embedded image moved to file: >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> pic24565.gif) >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> (Embedded image moved to file: >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> pic28141.gif) >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> >>>> >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>Christer, et al., >>>>> >>>>>media value '-' is not allowed by RFC 2327 (& RFC 3108) in our >>>>>understanding: >>>>> >>>>>RFC 2327: >>>>> >>>>> >>>>>media-descriptions =3D *( media-field >>>>> >>>>> >>>>> information-field >>>>> >>>>> >>>>> *(connection-field) >>>>> >>>>> >>>>> bandwidth-fields >>>>> >>>>> >>>>> key-field >>>>> >>>>> >>>>> attribute-fields ) >>>>> >>>>> >>>>> media-field =3D "m=3D" media space port ["/" integer] >>>>> >>>>> >>>>> space proto 1*(space fmt) CRLF >>>>> >>>>> >>>>> media =3D 1*(alpha-numeric) >>>>> >>>>> >>>>> ;typically "audio", "video", "application" >>>>> >>>>> >>>>> ;or "data" >>>>> >>>>> >>>>>RFC 3108: >>>>> >>>>> >>>>>media-descriptions =3D *(media-description) >>>>> >>>>> >>>>>media-description =3D media-field information-field >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>*(connection-field) >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> bandwidth-fields key-field attribute-fields >>>>> >>>>> >>>>>media-field =3D RFC 2327-media-field / RFC 2848-media-field / >>>>> >>>>> >>>>> atm-media-field >>>>> >>>>> >>>>> ; RFC 2327-media-field and RFC 2848-media-field defined in those=20 >>>>>rfc's >>>>> >>>>> >>>>>atm-media-field =3D "m=3D" media space vcId space transport-fmts = EOL >>>>> >>>>> >>>>> ; superset of RFC 2327 definition >>>>> >>>>> >>>>>media =3D "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=20 >>>>>to further differences between H.248/SDP and SIP/SDP, with further=20 >>>>>mapping requirements for the "SDP mapper" (ETSI TR 183 046;=20 >>>>>WI-03062), or >>>>> >>>>>(2) alternatively we could change the codepoint '-' to an allowed >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>codepoint >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>(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=20 >>>>>insights >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>with >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>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 ann issue with media value '-' >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>in >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> SDP"m=3D" line >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> >>>> >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> (Embedded image moved to file: >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> pic24565.gif) >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> (Embedded image moved to file: >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> pic28141.gif) >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>> >>>> >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>Christer, et al., >>>>> >>>>>media value '-' is not allowed by RFC 2327 (& RFC 3108) in our >>>>>understanding: >>>>> >>>>>RFC 2327: >>>>> >>>>> >>>>>media-descriptions =3D *( media-field >>>>> >>>>> >>>>> information-field >>>>> >>>>> >>>>> *(connection-field) >>>>> >>>>> >>>>> bandwidth-fields >>>>> >>>>> >>>>> key-field >>>>> >>>>> >>>>> attribute-fields ) >>>>> >>>>> >>>>> media-field =3D "m=3D" media space port ["/" integer] >>>>> >>>>> >>>>> space proto 1*(space fmt) CRLF >>>>> >>>>> >>>>> media =3D 1*(alpha-numeric) >>>>> >>>>> >>>>> ;typically "audio", "video", "application" >>>>> >>>>> >>>>> ;or "data" >>>>> >>>>> >>>>>RFC 3108: >>>>> >>>>> >>>>>media-descriptions =3D *(media-description) >>>>> >>>>> >>>>>media-description =3D media-field information-field >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>*(connection-field) >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> bandwidth-fields key-field attribute-fields >>>>> >>>>> >>>>>media-field =3D RFC 2327-media-field / RFC 2848-media-field / >>>>> >>>>> >>>>> atm-media-field >>>>> >>>>> >>>>> ; RFC 2327-media-field and RFC 2848-media-field defined in those=20 >>>>>rfc's >>>>> >>>>> >>>>>atm-media-field =3D "m=3D" media space vcId space transport-fmts = EOL >>>>> >>>>> >>>>> ; superset of RFC 2327 definition >>>>> >>>>> >>>>>media =3D "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=20 >>>>>to further differences between H.248/SDP and SIP/SDP, with further=20 >>>>>mapping requirements for the "SDP mapper" (ETSI TR 183 046;=20 >>>>>WI-03062), or >>>>> >>>>>(2) alternatively we could change the codepoint '-' to an allowed >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>codepoint >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>(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=20 >>>>>insights >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>with >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>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 >>>>>|---------------------------+---------------------------+---------- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>---------------| >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>| SDP Information Element | Mandatory/optional | >>>>>Description | >>>>>|---------------------------+---------------------------+---------- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>---------------| >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>| Protocol version | Mandatory | The value >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>must >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>always be | >>>>>| "v=3D" line | | equals = to >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>zero: >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>| >>>>>| | | v=3D0 >>>>>| >>>>>|---------------------------+---------------------------+---------- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>---------------| >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>| Connection | Mandatory | The = network >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>type >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>must always| >>>>>| "c=3D" line | | be = "IN". >>>>>| >>>>>| | | >>>>>| >>>>>| | |The = address >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>type >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>value must | >>>>>| | |be "IP4" = or >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>"IP6". >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>| >>>>>| | | >>>>>| >>>>>| | |The = connection >>>>>address value | >>>>>| | |may be >>>>>underspecified with | >>>>>| | |CHOOSE >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>wildcard >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>("$"). | >>>>>|---------------------------+---------------------------+---------- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>---------------| >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>| Media ex C information elements >>>>> >>>>> >>>>> >>>>> Table 81: Supported SDP Information Elements >>>>>|---------------------------+---------------------------+---------- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>---------------| >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>| SDP Information Element | Mandatory/optional | >>>>>Description | >>>>>|---------------------------+---------------------------+---------- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>---------------| >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>| Protocol version | Mandatory | The value >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>must >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>always be | >>>>>| "v=3D" line | | equals = to >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>zero: >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>| >>>>>| | | v=3D0 >>>>>| >>>>>|---------------------------+---------------------------+---------- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>---------------| >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>| Connection | Mandatory | The = network >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>type >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>must always| >>>>>| "c=3D" line | | be = "IN". >>>>>| >>>>>| | | >>>>>| >>>>>| | |The = address >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>type >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>value must | >>>>>| | |be "IP4" = or >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>"IP6". >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>| >>>>>| | | >>>>>| >>>>>| | |The = connection >>>>>address value | >>>>>| | |may be >>>>>underspecified with | >>>>>| | |CHOOSE >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>wildcard >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>("$"). | >>>>>|---------------------------+---------------------------+---------- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>---------------| >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>| Media | Mandatory |"-" may be >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>used >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>for the media| >>>>>| "m=3D" line | |value. = Other >>>>>values shall be | >>>>>| | |ignored, >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>unless >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>media | >>>>>| | |specific >>>>>information is | >>>>>| | |required. >>>>>| >>>>>| | | >>>>>| >>>>>| | |The port = value >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>may >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>be | >>>>>| | = |underspecified >>>>>with CHOOSE | >>>>>| | |wildcard >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>("$"). >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>| >>>>>| | | >>>>>| >>>>>| | |"-" may be >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>used >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>for the | >>>>>| | |transport >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>value, >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>unless | >>>>>| | |transport >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>specific >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>behaviour | >>>>>| | |is = required by >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>the >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>MG. | >>>>>| | |(See note) >>>>>| >>>>>| | | "-" may = be >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>used >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>for the | >>>>>| | | format = list >>>>>value. Other | >>>>>| | | values = shall >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>be >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>ignored. | >>>>>|---------------------------+---------------------------+---------- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>---------------| >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Megaco mailing list >>>>>Megaco@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>>> >>>>> >>>>>*********************** FSS-Restricted *********************** >>>>>"DISCLAIMER: This message is proprietary to Flextronics Software=20 >>>>>Systems Limited (FSS) and is intended solely for the use of the=20 >>>>>individual to whom it is addressed. It may contain privileged or=20 >>>>>confidential information and should not b | Mandatory |"-" may be >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>used >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>for the media| >>>>>| "m=3D" line | |value. = Other >>>>>values shall be | >>>>>| | |ignored, >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>unless >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>media | >>>>>| | |specific >>>>>information is | >>>>>| | |required. >>>>>| >>>>>| | | >>>>>| >>>>>| | |The port = value >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>may >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>be | >>>>>| | = |underspecified >>>>>with CHOOSE | >>>>>| | |wildcard >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>("$"). >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>| >>>>>| | | >>>>>| >>>>>| | |"-" may be >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>used >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>for the | >>>>>| | |transport >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>value, >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>unless | >>>>>| | |transport >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>specific >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>behaviour | >>>>>| | |is = required by >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>the >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>MG. | >>>>>| | |(See note) >>>>>| >>>>>| | | "-" may = be >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>used >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>for the | >>>>>| | | format = list >>>>>value. Other | >>>>>| | | values = shall >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>be >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>ignored. | >>>>>|---------------------------+---------------------------+---------- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>---------------| >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Megaco mailing list >>>>>Megaco@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>>> >>>>> >>>>>*********************** FSS-Restricted *********************** >>>>>"DISCLAIMER: This message is proprietary to Flextronics Software=20 >>>>>Systems Limited (FSS) and is intended solely for the use of the=20 >>>>>individual to whom it is addressed. It may contain privileged or=20 >>>>>confidential information and should not be circulated or used for=20 >>>>>any purpose other than for what it is intended. If you have=20 >>>>>received this message in error, please notify the originator = immediately. >>>>>If you are not the intended recipient, you are notified that you=20 >>>>>are strictly prohibited from using, copying, altering, or=20 >>>>>disclosing the contents of this message. FSS accepts no=20 >>>>>responsibility for loss or damage arising from the use of the=20 >>>>>information transmitted by this email including damage from virus." >>>>>_______________________________________________ >>>>>Megaco mailing list >>>>>Megaco@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>------------------------------------------------------------------- >>>>>- >>>>>- >>>>>- >>>>>- >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>- >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>_______________________________________________ >>>>>Megaco mailing list >>>>>Megaco@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>*********************** FSS-Restricted *********************** >>>>"DISCLAIMER: This message is proprietary to Flextronics Software=20 >>>>Systems Limited (FSS) and is intended solely for the use of the=20 >>>>individual to whom it is addressed. It may contain privileged or=20 >>>>confidential information and should not be circulated or used for=20 >>>>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=20 >>>>damage arising from the use of the informatione circulated or used for=20 >>>>>any purpose other than for what it is intended. If you have=20 >>>>>received this message in error, please notify the originator = immediately. >>>>>If you are not the intended recipient, you are notified that you=20 >>>>>are strictly prohibited from using, copying, altering, or=20 >>>>>disclosing the contents of this message. FSS accepts no=20 >>>>>responsibility for loss or damage arising from the use of the=20 >>>>>information transmitted by this email including damage from virus." >>>>>_______________________________________________ >>>>>Megaco mailing list >>>>>Megaco@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>------------------------------------------------------------------- >>>>>- >>>>>- >>>>>- >>>>>- >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>- >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>_______________________________________________ >>>>>Megaco mailing list >>>>>Megaco@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>*********************** FSS-Restricted *********************** >>>>"DISCLAIMER: This message is proprietary to Flextronics Software=20 >>>>Systems Limited (FSS) and is intended solely for the use of the=20 >>>>individual to whom it is addressed. It may contain privileged or=20 >>>>confidential information and should not be circulated or used for=20 >>>>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=20 >>>>damage arising from the use of the information transmitted by this=20 >>>>email including damage from virus." >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> >>> >>> >>> >>> =20 >>> >>> =20 >>> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >> >> >> >>=20 >> >> =20 >> > > > > > > =20 > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Aug 07 09:11:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA4tO-00007L-Au; Mon, 07 Aug 2006 09:11:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA1nJ-0001aU-H7 for megaco@ietf.org; Mon, 07 Aug 2006 05:53:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA00R-0000cM-K3 for megaco@ietf.org; Mon, 07 Aug 2006 03:58:35 -0400 Received: from quantum.websiteactive.com ([70.86.207.162]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G9zo2-0002Jy-LA for megaco@ietf.org; Mon, 07 Aug 2006 03:45:50 -0400 Received: from cpe-61-9-144-63.vic.bigpond.net.au ([61.9.144.63]:11107 helo=[127.0.0.1]) by quantum.websiteactive.com with esmtpa (Exim 4.52) id 1G9znn-0007kF-2T; Mon, 07 Aug 2006 17:45:40 +1000 Message-ID: <44D6EF88.2040700@nteczone.com> Date: Mon, 07 Aug 2006 17:45:12 +1000 From: Christian Groves User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=" line References: <5EB80D22825EEE42872083AD5BFFB594017F12D4@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F12D4@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - quantum.websiteactive.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.6 (--) X-Scan-Signature: b94dc4bdf198bbac576fbc9df2060daa X-Mailman-Approved-At: Mon, 07 Aug 2006 09:11:36 -0400 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , >>>email including damage from virus." >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> >>> >>> >>> >>> =20 >>> >>> =20 >>> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >> >> >> >>=20 >> >> =20 >> > > > > > > =20 > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Aug 07 09:11:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA4tO-00007L-Au; Mon, 07 Aug 2006 09:11:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA1nJ-0001aU-H7 for megaco@ietf.org; Mon, 07 Aug 2006 05:53:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA00R-0000cM-K3 for megaco@ietf.org; Mon, 07 Aug 2006 03:58:35 -0400 Received: from quantum.websiteactive.com ([70.86.207.162]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G9zo2-0002Jy-LA for megaco@ietf.org; Mon, 07 Aug 2006 03:45:50 -0400 Received: from cpe-61-9-144-63.vic.bigpond.net.au ([61.9.144.63]:11107 helo=[127.0.0.1]) by quantum.websiteactive.com with esmtpa (Exim 4.52) id 1G9znn-0007kF-2T; Mon, 07 Aug 2006 17:45:40 +1000 Message-ID: <44D6EF88.2040700@nteczone.com> Date: Mon, 07 Aug 2006 17:45:12 +1000 From: Christian Groves User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=" line References: <5EB80D22825EEE42872083AD5BFFB594017F12D4@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F12D4@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - quantum.websiteactive.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.6 (--) X-Scan-Signature: b94dc4bdf198bbac576fbc9df2060daa X-Mailman-Approved-At: Mon, 07 Aug 2006 09:11:36 -0400 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hello Christer, Please see my response below [CNG]. Cheers, Christian Christer Holmberg (JO/LMF) wrote: >Hi Christian, > > > >>You could use: >> >>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". > > [CNG] Isn't the format of m=?: m= and for "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 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. > > [CNG] At least we agree that H.248.1 isn't the place to do it. The key is the syntax allows it. > > >>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). > > > [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. >>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. >> >> > >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. >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: > > > >>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 fest@ietf.org?subject=subscribe> Errors-To: megaco-bounces@ietf.org Hello Christer, Please see my response below [CNG]. Cheers, Christian Christer Holmberg (JO/LMF) wrote: >Hi Christian, > > > >>You could use: >> >>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". > > [CNG] Isn't the format of m=?: m= and for "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 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. > > [CNG] At least we agree that H.248.1 isn't the place to do it. The key is the syntax allows it. > > >>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). > > > [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. >>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. >> >> > >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. >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: > > > >>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:Christian.Groves@nteczone.com] >>Sent: 4. elokuuta 2006 4:28 >>To: CHATRAS Bruno RD-CORE-ISS >>Cc: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de; >>megaco@ietf.org; Campos, Simao >>Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value >>'-'in SDP"m=" line >> >>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:christer.holmberg@ericsson.com] >>>Envoyé : mardi 25 juillet 2006 09:34 >>>À : Christian Groves; Albrecht.Schwarz@alcatel.de Cc : CHATRAS Bruno >>>RD-CORE-ISS; megaco@ietf.org; 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" >>>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 tmt 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:Christian.Groves@nteczone.com] >>Sent: 4. elokuuta 2006 4:28 >>To: CHATRAS Bruno RD-CORE-ISS >>Cc: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de; >>megaco@ietf.org; Campos, Simao >>Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value >>'-'in SDP"m=" line >> >>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:christer.holmberg@ericsson.com] >>>Envoyé : mardi 25 juillet 2006 09:34 >>>À : Christian Groves; Albrecht.Schwarz@alcatel.de Cc : CHATRAS Bruno >>>RD-CORE-ISS; megaco@ietf.org; 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" >>>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 >>> >>>Albrecht.Schwarz@alcatel.de 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" , "CHATRAS Bruno RD-CORE-ISS" >>>> , Albrecht SCHWARZ/DE/ALCATEL@ALCATEL >>>> icsson.com> cc: megaco@ietf.org >>>> 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:kboyle@nortel.com] >>>>Sent: 21. heinäkuuta 2006 17:23 >>>>To: Christer Holmberg (JO/LMF); CHATRAS Bruno RD-CORE-ISS; >>>>Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>>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:christer.holmberg@ericsson.com] >>>>Sent: Friday, July 21, 2006 5:18 AM >>>>To: CHATRAS Bruno RD-CORE-ISS; Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value >>>>'-'in SDP"m=" lhe 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 >>> >>>Albrecht.Schwarz@alcatel.de 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" , "CHATRAS Bruno RD-CORE-ISS" >>>> , Albrecht SCHWARZ/DE/ALCATEL@ALCATEL >>>> icsson.com> cc: megaco@ietf.org >>>> 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:kboyle@nortel.com] >>>>Sent: 21. heinäkuuta 2006 17:23 >>>>To: Christer Holmberg (JO/LMF); CHATRAS Bruno RD-CORE-ISS; >>>>Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>>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:christer.holmberg@ericsson.com] >>>>Sent: Friday, July 21, 2006 5:18 AM >>>>To: CHATRAS Bruno RD-CORE-ISS; Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>>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:bruno.chatras@orange-ft.com] >>>>Sent: 21. heinäkuuta 2006 10:26 >>>>To: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>>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:christer.holmberg@ericsson.com] >>>>Envoyé : jeudi 20 juillet 2006 20:46 >>>>À : Albrecht.Schwarz@alcatel.de >>>>Cc : megaco@ietf.org >>>>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: Albrecht.Schwarz@alcatel.de >>>>[mailto:Albrecht.Schwarz@alcatel.de] >>>>Sent: 20. heinäkuuta 2006 12:00 >>>>To: Christer Holmberg (JO/LMF) >>>>Cc: megaco@ietf.org >>>>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" >>>>, "B Venkat S.R Swamy" >>>> >>>, "Christian Groves" >>>> >>>> icsson.com> cc: Albrecht >>>>SCHWARZ/DE/ALCATEL@ALCATEL, megaco@ietf.org >>>> Subject: RE: >>>>[Megaco] ETSI H.248 Ia Profile: issue with media value '-'inSDP"m=" line >>>> 17.07.2006 22:00 >>>> >>ine >>>> >>>> >>>>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:bruno.chatras@orange-ft.com] >>>>Sent: 21. heinäkuuta 2006 10:26 >>>>To: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>>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:christer.holmberg@ericsson.com] >>>>Envoyé : jeudi 20 juillet 2006 20:46 >>>>À : Albrecht.Schwarz@alcatel.de >>>>Cc : megaco@ietf.org >>>>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: Albrecht.Schwarz@alcatel.de >>>>[mailto:Albrecht.Schwarz@alcatel.de] >>>>Sent: 20. heinäkuuta 2006 12:00 >>>>To: Christer Holmberg (JO/LMF) >>>>Cc: megaco@ietf.org >>>>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" >>>>, "B Venkat S.R Swamy" >>>> >>>, "Christian Groves" >>>> >>>> icsson.com> cc: Albrecht >>>>SCHWARZ/DE/ALCATEL@ALCATEL, megaco@ietf.org >>>> 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:kboyle@nortel.com] >>>>Sent: 17. heinäkuuta 2006 19:58 >>>>To: B Venkat S.R Swamy; Christian Groves >>>>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; 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:b.swamy@flextronicssoftware.com] >>>>Sent: Monday, July 17, 2006 12:40 AM >>>>To: Christian Groves >>>>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; >>>>christer.holmberg@ericsson.com >>>>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 >>>> >>>> >>>> >>>> >>>> Christian Groves >>>> >>>> >>>> 07/17/2006 06:36 AM >>>> >>>> >>>> >>>>To >>>> >>>>Albrecht.Schwarz@alcatel.de >>>> >>>> >>>>cc >>>> >>>>B Venkat S.R Swamy/HSS@HSS, megaco@ietf.org, >>>>christer.holmberg@ericsson.com >>>> >>>> >>>>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 >>>> >>>>Albrecht.Schwarz@alcatel.de 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>> >>>> >>>> >>>> >>>> >>>> >>>>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:kboyle@nortel.com] >>>>Sent: 17. heinäkuuta 2006 19:58 >>>>To: B Venkat S.R Swamy; Christian Groves >>>>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; 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:b.swamy@flextronicssoftware.com] >>>>Sent: Monday, July 17, 2006 12:40 AM >>>>To: Christian Groves >>>>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; >>>>christer.holmberg@ericsson.com >>>>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 >>>> >>>> >>>> >>>> >>>> Christian Groves >>>> >>>> >>>> 07/17/2006 06:36 AM >>>> >>>> >>>> >>>>To >>>> >>>>Albrecht.Schwarz@alcatel.de >>>> >>>> >>>>cc >>>> >>>>B Venkat S.R Swamy/HSS@HSS, megaco@ietf.org, >>>>christer.holmberg@ericsson.com >>>> >>>> >>>>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 >>>> >>>>Albrecht.Schwarz@alcatel.de 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" >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>SCHWARZ/DE/ALCATEL@ALCATEL >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> ftware.com> cc: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>megaco@ietf.org, christer.holmberg@ericsson.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> 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 >>>> >>>> >>> 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" >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>SCHWARZ/DE/ALCATEL@ALCATEL >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> ftware.com> cc: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>megaco@ietf.org, christer.holmberg@ericsson.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> 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)Albrecht.Schwarz@alcatel.de >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>christer.holmberg@ericsson.com, >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> taylor@nortel.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> (Embedded image moved to file: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> pic31609.gif) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>cc >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> (Embedded image moved to >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>file: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> pic17314.gif) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> megaco@ietf.org >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> (Embedded image moved to file: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> pic14997.gif) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Subject >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> (Embedded image moved to >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>file: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> pic24297.gif) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> [Megaco] ETSI H.248 Ia >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Profile: >>>> >>>> >>>> >>>> >>>> >>>> >>>> > >>>> >>>> >>>> >>>> >>>> >>>>>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)Albrecht.Schwarz@alcatel.de >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>christer.holmberg@ericsson.com, >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> taylor@nortel.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> (Embedded image moved to file: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> pic31609.gif) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>cc >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> (Embedded image moved to >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>file: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> pic17314.gif) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> megaco@ietf.org >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> (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 >>>>>|--------- >>>> >>>>> 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 ------------------+---------------------------+----------- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>---------------| >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>| 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 >>>>>Megaco@ietf.org >>>>>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 >>>>>Megaco@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> | >>>>>| | |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 >>>>>Megaco@ietf.org >>>>>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 >>>>>Megaco@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>--------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>--------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>--------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>--------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>--------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>--------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>--------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>--------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>--------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>-------------------------------------------------------------------- >>>>>- >>>>>- >>>>>- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>_______________________________________________ >>>>>Megaco mailing list >>>>>Megaco@ietf.org >>>>>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 >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>_______________________________________________>--------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>--------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>--------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>--------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>--------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>--------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>--------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>--------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>--------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>-------------------------------------------------------------------- >>>>>- >>>>>- >>>>>- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>_______________________________________________ >>>>>Megaco mailing list >>>>>Megaco@ietf.org >>>>>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 >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >> >> >> >> >> >> >> > > > > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >> >> >> >> >> >> >> > > > > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Aug 10 16:12:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBGt9-0002Lw-4U; Thu, 10 Aug 2006 16:12:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBGt7-0002Lj-QX for megaco@ietf.org; Thu, 10 Aug 2006 16:12:17 -0400 Received: from david.siemens.gr ([212.251.43.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBGt6-0008UM-4Q for megaco@ietf.org; Thu, 10 Aug 2006 16:12:17 -0400 Received: from mail.siemens.gr (localhost [127.0.0.1]) by david.siemens.gr (8.12.6/8.12.6) with ESMTP id k7AKCEai009496 for ; Thu, 10 Aug 2006 22:12:15 +0200 Received: from atha112a.gr001.siemens.net ([141.29.38.98]) by mail.siemens.gr (8.12.6/8.12.6) with ESMTP id k7AKC4ql005669 for ; Thu, 10 Aug 2006 22:12:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Aug 2006 23:12:02 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: which error code replaces error code 540 (Unexpected Initial Hook State)? Thread-Index: Aca8uT3j4SDxHyKWRYadw8e/0KYhrg== From: "Oikonomou, Ioannis" To: X-Spam-Score: 0.3 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Subject: [Megaco] which error code replaces error code 540 (Unexpected Initial Hook State)? X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0764744188==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0764744188== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6BCB9.3F1577E5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6BCB9.3F1577E5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 I just realized that in the latest version of H.248.8 (09/2005), the error code 540 (Unexpected Initial Hook State) has been removed! What error code are we supposed to use now for the detection of hook state with 'failWrong' parameter? =20 Ioannis Oikonomou Senior Software Engineer Siemens SA Greece =20 =20 ------_=_NextPart_001_01C6BCB9.3F1577E5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I just realized that in the latest version of = H.248.8 (09/2005), the error code 540 (Unexpected Initial Hook State) has been = removed!

What error code are we supposed to use now for = the detection of hook state with ‘failWrong’ = parameter?

 

Ioannis Oikonomou

Senior Software = Engineer

Siemens SA

Greece

 

 

------_=_NextPart_001_01C6BCB9.3F1577E5-- --===============0764744188== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0764744188==-- From megaco-bounces@ietf.org Thu Aug 10 16:35:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBHFB-0002Bh-Tc; Thu, 10 Aug 2006 16:35:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBHFA-0002Bc-IW for megaco@ietf.org; Thu, 10 Aug 2006 16:35:04 -0400 Received: from david.siemens.gr ([212.251.43.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBHF8-0007AY-OQ for megaco@ietf.org; Thu, 10 Aug 2006 16:35:04 -0400 Received: from mail.siemens.gr (localhost [127.0.0.1]) by david.siemens.gr (8.12.6/8.12.6) with ESMTP id k7AKZ1AN013402 for ; Thu, 10 Aug 2006 22:35:01 +0200 Received: from atha112a.gr001.siemens.net ([141.29.38.98]) by mail.siemens.gr (8.12.6/8.12.6) with ESMTP id k7AKYpQU011216 for ; Thu, 10 Aug 2006 22:35:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Aug 2006 23:34:49 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ServiceChange indicating multiple terminations Thread-Index: Aca8vG0qmNc2TaLURRSMRnNPUHQMKw== From: "Oikonomou, Ioannis" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b Subject: [Megaco] ServiceChange indicating multiple terminations X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1208452134==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1208452134== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6BCBC.6DE84473" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6BCBC.6DE84473 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 I have 2 questions concerning the ServiceChange command: =20 1) ServiceChange(Handoff) is the only ServiceChange command that an MGC is allowed to send towards an MG. Is this correct? =20 2) Is the following syntax allowed? =20 MEGACO/1 [216.33.33.61]: 25000 Transaction =3D 4321 { Context =3D - { ServiceChange =3D TermA, TermB, TermC { Services { Method =3D Forced } } } } =20 The syntax for ServiceChange is the following according to H.248.1: =20 ServiceChangeRequest ::=3D SEQUENCE { terminationID TerminationIDList, serviceChangeParms ServiceChangeParm, ... } =20 TerminationIDList ::=3D SEQUENCE OF TerminationID =20 TerminationID ::=3D SEQUENCE { wildcard SEQUENCE OF WildcardField,=20 id OCTET STRING(SIZE(1..8)), ... } =20 WildcardField ::=3D OCTET STRING(SIZE(1)) =20 Ioannis Oikonomou Senior Software Engineer Siemens SA Greece =20 ------_=_NextPart_001_01C6BCBC.6DE84473 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I have 2 questions concerning the = ServiceChange command:

 

1) ServiceChange(Handoff) is the only = ServiceChange command that an MGC is allowed to send towards an MG. Is this = correct?

 

2) Is the following syntax = allowed?

 

MEGACO/1 [216.33.33.61]: = 25000
Transaction =3D 4321 {
    Context =3D - {
        ServiceChange =3D TermA, TermB, TermC { Services {
            = Method =3D Forced }
        }
    }
}
 

The syntax for ServiceChange is the following according to H.248.1:

 

ServiceChangeRequest ::=3D = SEQUENCE

{

     = terminationID      =         TerminationIDList,

     serviceChangeParms =         = ServiceChangeParm,

     = ...

}

 

TerminationIDList ::=3D SEQUENCE OF TerminationID

 

TerminationID ::=3D = SEQUENCE

{

     wildcard  = SEQUENCE OF WildcardField,

     id    = OCTET STRING(SIZE(1..8)),

     = ...

}

 

WildcardField ::=3D OCTET = STRING(SIZE(1))

 

Ioannis Oikonomou

Senior Software = Engineer

Siemens SA

Greece

 

------_=_NextPart_001_01C6BCBC.6DE84473-- --===============1208452134== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1208452134==-- From megaco-bounces@ietf.org Thu Aug 10 17:09:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBHm9-0001mi-KS; Thu, 10 Aug 2006 17:09:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBHm8-0001md-3c for megaco@ietf.org; Thu, 10 Aug 2006 17:09:08 -0400 Received: from usnwksmtp04e.usa.siemens.com ([12.46.135.35] helo=usnwk224srv.usa.siemens.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBHm4-00021s-Av for megaco@ietf.org; Thu, 10 Aug 2006 17:09:08 -0400 Received: from usnwk206a.ww017.siemens.net ([155.45.111.74]) by 172.16.1.38 with trend_isnt_name_B; Thu, 10 Aug 2006 14:11:37 -0700 Received: from USNWK100MSX.ww017.siemens.net ([155.45.111.54]) by usnwk206a.ww017.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 14:09:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Megaco] ServiceChange indicating multiple terminations Date: Thu, 10 Aug 2006 14:09:01 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] ServiceChange indicating multiple terminations Thread-Index: Aca8vG0qmNc2TaLURRSMRnNPUHQMKwABFTqw From: "Wainwright, John \(Com US\)" To: "Oikonomou, Ioannis" , X-OriginalArrivalTime: 10 Aug 2006 21:09:02.0903 (UTC) FILETIME=[34E8F470:01C6BCC1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0723542475==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0723542475== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6BCC1.3491F74C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6BCC1.3491F74C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable According to H.248.1 v3 sections F.3.9 & F.3.10 the MGC can send a Service Change command to the MG with ServiceChangeMethod of Restart, Forced or Graceful as well as Handoff which you mention. =20 John =20 ________________________________ From: Oikonomou, Ioannis [mailto:Ioannis.Oikonomou@siemens.com]=20 Sent: Thursday, August 10, 2006 3:35 PM To: megaco@ietf.org Subject: [Megaco] ServiceChange indicating multiple terminations Hello, =20 I have 2 questions concerning the ServiceChange command: =20 1) ServiceChange(Handoff) is the only ServiceChange command that an MGC is allowed to send towards an MG. Is this correct? =20 2) Is the following syntax allowed? =20 MEGACO/1 [216.33.33.61]: 25000 Transaction =3D 4321 { Context =3D - { ServiceChange =3D TermA, TermB, TermC { Services { Method =3D Forced } } } } =20 The syntax for ServiceChange is the following according to H.248.1: =20 ServiceChangeRequest ::=3D SEQUENCE { terminationID TerminationIDList, serviceChangeParms ServiceChangeParm, ... } =20 TerminationIDList ::=3D SEQUENCE OF TerminationID =20 TerminationID ::=3D SEQUENCE { wildcard SEQUENCE OF WildcardField,=20 id OCTET STRING(SIZE(1..8)), ... } =20 WildcardField ::=3D OCTET STRING(SIZE(1)) =20 Ioannis Oikonomou Senior Software Engineer Siemens SA Greece =20 ------_=_NextPart_001_01C6BCC1.3491F74C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
According to H.248.1 v3 = sections F.3.9=20 & F.3.10 the MGC can send a Service Change command to the MG with=20 ServiceChangeMethod of Restart, Forced or Graceful as well as Handoff = which you=20 mention.
 
John
 

From: Oikonomou, Ioannis=20 [mailto:Ioannis.Oikonomou@siemens.com]
Sent: Thursday, August = 10,=20 2006 3:35 PM
To: megaco@ietf.org
Subject: [Megaco]=20 ServiceChange indicating multiple terminations

Hello,

 

I have 2 questions = concerning the=20 ServiceChange command:

 

1) ServiceChange(Handoff) = is the=20 only ServiceChange command that an MGC is allowed to send towards an MG. = Is this=20 correct?

 

2) Is the following syntax = allowed?

 

MEGACO/1 [216.33.33.61]:=20 25000
Transaction =3D 4321 = {
    Context =3D=20 - {
       =20 ServiceChange =3D TermA, TermB, TermC { Services=20 {
            = Method =3D=20 Forced }
   =      }
   =20 }
}
 

The syntax for = ServiceChange is the=20 following according to H.248.1:

 

ServiceChangeRequest ::=3D=20 SEQUENCE

{

    =20 terminationID     =20         TerminationIDList,

     serviceChangeParms=20        =20 ServiceChangeParm,

    =20 ...

}

 

TerminationIDList ::=3D SEQUENCE OF = TerminationID

 

TerminationID ::=3D=20 SEQUENCE

{

     wildcard  = SEQUENCE OF=20 WildcardField,

     id    = OCTET=20 STRING(SIZE(1..8)),

    =20 ...

}

 

WildcardField ::=3D OCTET=20 STRING(SIZE(1))

 

Ioannis=20 Oikonomou

Senior Software=20 Engineer

Siemens=20 SA

Greece

 

------_=_NextPart_001_01C6BCC1.3491F74C-- --===============0723542475== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0723542475==-- From megaco-bounces@ietf.org Fri Aug 11 03:05:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBR5I-0000ib-3u; Fri, 11 Aug 2006 03:05:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBR5G-0000ca-NJ for megaco@ietf.org; Fri, 11 Aug 2006 03:05:30 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17] helo=jaguar.hss.hns.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBR5E-0003Hs-7t for megaco@ietf.org; Fri, 11 Aug 2006 03:05:30 -0400 Received: from jaguar.hss.hns.com (localhost [127.0.0.1]) by jaguar.hss.hns.com (8.13.6/8.12.10) with ESMTP id k7B76x7p007505 for ; Fri, 11 Aug 2006 12:37:00 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by jaguar.hss.hns.com (8.13.6/8.13.6) with ESMTP id k7B76s7T007453; Fri, 11 Aug 2006 12:36:54 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id k7B75pe13061; Fri, 11 Aug 2006 12:36:07 +0530 (IST) In-Reply-To: To: "Oikonomou, Ioannis" Subject: Re: [Megaco] ServiceChange indicating multiple terminations MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Sudhanshu Garg Date: Fri, 11 Aug 2006 11:04:02 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 11/08/2006 12:35:07 PM, Serialize complete at 11/08/2006 12:35:07 PM X-Spam-Score: 0.5 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0194635517==" Errors-To: megaco-bounces@ietf.org This is a multipart message in MIME format. --===============0194635517== Content-Type: multipart/alternative; boundary="=_alternative 001E47F8652571C7_=" This is a multipart message in MIME format. --=_alternative 001E47F8652571C7_= Content-Type: text/plain; charset="US-ASCII" Hi, The ABNF syntax of H.248.1 (version 3), provides termination ID list as: termIDList = (TerminationID / LSBRKT TerminationID 1*(COMMA TerminationID) RSBRKT) The termination ID list was not allowed in ABNF syntax in earlier versions of H.248.1 Also the service change reason is mandatory in the service change command request. So the correct syntax should have Megaco version 3, termination list enclosed in square brackets and service change reason present: MEGACO/3 [216.33.33.61]: 25000 Transaction = 4321 { Context = - { ServiceChange = [TermA, TermB, TermC] { Services { Method = Forced, Reason = "905 Term Taken OOS" } } } } Regards, Sudhanshu. Technical Leader Flextronics Software Systems Phone: +91-124-4176301 extn 5109 Fax: +91-124-4300247 web: www.flextronicssoftware.com "Oikonomou, Ioannis" 08/11/2006 02:04 AM To cc Subject [Megaco] ServiceChange indicating multiple terminations Hello, I have 2 questions concerning the ServiceChange command: 1) ServiceChange(Handoff) is the only ServiceChange command that an MGC is allowed to send towards an MG. Is this correct? 2) Is the following syntax allowed? MEGACO/1 [216.33.33.61]: 25000 Transaction = 4321 { Context = - { ServiceChange = TermA, TermB, TermC { Services { Method = Forced } } } } The syntax for ServiceChange is the following according to H.248.1: ServiceChangeRequest ::= SEQUENCE { terminationID TerminationIDList, serviceChangeParms ServiceChangeParm, ... } TerminationIDList ::= SEQUENCE OF TerminationID TerminationID ::= SEQUENCE { wildcard SEQUENCE OF WildcardField, id OCTET STRING(SIZE(1..8)), ... } WildcardField ::= OCTET STRING(SIZE(1)) Ioannis Oikonomou Senior Software Engineer Siemens SA Greece _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco *********************** FSS-Private *********************** --=_alternative 001E47F8652571C7_= Content-Type: text/html; charset="US-ASCII"
Hi,

The ABNF syntax of H.248.1 (version 3), provides termination ID list as:
        termIDList                        = (TerminationID / LSBRKT TerminationID 1*(COMMA
                                                TerminationID) RSBRKT)
The termination ID list was not allowed in ABNF syntax in earlier versions of H.248.1

Also the service change reason is mandatory in the service change command request.

So the correct syntax should have Megaco version 3, termination list enclosed in square brackets and service change reason present:

MEGACO/3 [216.33.33.61]: 25000
Transaction = 4321 {
   Context = - {
       ServiceChange = [TermA, TermB, TermC] { Services {
           Method = Forced, Reason = "905 Term Taken OOS" }
       }
   }
}

Regards,
Sudhanshu.
Technical Leader
Flextronics Software Systems
Phone:  +91-124-4176301 extn 5109
Fax: +91-124-4300247
web: www.flextronicssoftware.com


"Oikonomou, Ioannis" <Ioannis.Oikonomou@siemens.com>

08/11/2006 02:04 AM

To
<megaco@ietf.org>
cc
Subject
[Megaco] ServiceChange indicating multiple terminations





Hello,
 
I have 2 questions concerning the ServiceChange command:
 
1) ServiceChange(Handoff) is the only ServiceChange command that an MGC is allowed to send towards an MG. Is this correct?
 
2) Is the following syntax allowed?
 
MEGACO/1 [216.33.33.61]: 25000
Transaction = 4321 {
   Context = - {
       ServiceChange = TermA, TermB, TermC { Services {
           Method = Forced }
       }
   }
}
The syntax for ServiceChange is the following according to H.248.1:
 
ServiceChangeRequest ::= SEQUENCE
{
     terminationID              TerminationIDList,
     serviceChangeParms         ServiceChangeParm,
     ...
}
 
TerminationIDList ::= SEQUENCE OF TerminationID
 
TerminationID ::= SEQUENCE
{
     wildcard  SEQUENCE OF WildcardField,
     id    OCTET STRING(SIZE(1..8)),
     ...
}
 
WildcardField ::= OCTET STRING(SIZE(1))
 
Ioannis Oikonomou
Senior Software Engineer
Siemens SA
Greece
 _______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


***********************  FSS-Private   *********************** --=_alternative 001E47F8652571C7_=-- --===============0194635517== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0194635517==-- From megaco-bounces@ietf.org Fri Aug 11 04:59:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBSr5-0001rb-Dr; Fri, 11 Aug 2006 04:58:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBSr3-0001rW-R2 for megaco@ietf.org; Fri, 11 Aug 2006 04:58:57 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBSr2-0001p4-Cv for megaco@ietf.org; Fri, 11 Aug 2006 04:58:57 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.11.20060308/8.12.11/ICT TSC MAIL 2005) with ESMTP id k7B8wsp3004129; Fri, 11 Aug 2006 10:58:54 +0200 In-Reply-To: Subject: Re: [Megaco] which error code replaces error code 540 (Unexpected Initial Hook State)? To: "Oikonomou, Ioannis" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Albrecht.Schwarz@alcatel.de Date: Fri, 11 Aug 2006 10:58:52 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/11/2006 10:58:53 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Ioannis, it was not removed, it was moved to clause =A7 E.9.5/H.248.1 V3 to my knowledge. I don't remember the underlying discussion, but I think we concluded to= put package-specific error codes in the package definitions itself. That's = why #540 was moved in the al package spec. - Albrecht = =20 "Oikonomou, Ioannis" = =20 =20 iemens.com> cc: = =20 Subject: [Megaco] wh= ich error code replaces error code 540 (Unexpected Initial =20 10.08.2006 22:12 Hook State)? = =20 = =20 Hello, I just realized that in the latest version of H.248.8 (09/2005), the er= ror code 540 (Unexpected Initial Hook State) has been removed! What error code are we supposed to use now for the detection of hook st= ate with 'failWrong' parameter? Ioannis Oikonomou Senior Software Engineer Siemens SA Greece _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco = _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Aug 14 13:06:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCft8-0004AE-RZ; Mon, 14 Aug 2006 13:06:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCft7-0004A4-6S for Megaco@ietf.org; Mon, 14 Aug 2006 13:06:05 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCft3-0001rV-UE for Megaco@ietf.org; Mon, 14 Aug 2006 13:06:05 -0400 Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id k7EH61Aj012273 for ; Mon, 14 Aug 2006 13:06:01 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Aug 2006 13:06:00 -0400 Message-ID: <97D8957C5565BB41912C3F958914C49F279A75@sonusmail06.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] FAILOVER Thread-Index: Aca2zaPmW9lElHrNR2OeMg3wHJiAdwI5/SPg From: "Kamitses, Jerry" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Subject: [Megaco] Question regarding the order of commands for the InterruptByNewSignalsDesc signal completion event X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Please comment on which of these optional sequences are Megaco V1 = compliant=20 (and the applicable bits of the spec. used as rationale). Note that by=20 "compliant" we are asking which sequences a Megaco V1 compliant MGC=20 should be able to handle. "A" denotes the starting condition, and the three apparently valid = options=20 appear labeled B1, B2, and B3 (A) Modify command on NULL context sent to the termination 3/2/1@MG to = play cg/rg=20 Then Add sent to 3/2/1@MG placing this termination into the context = 17171255,=20 stopping the cg/rt signal, and starting the cg/bt signal. !/1 T=3D17562{C=3D-{MF=3D3/2/1@MG = {E=3D1{g/sc},SG{cg/rt{NC=3D{TO,IBE,IBS}}}}}} !/1 :2345 P=3D17562 { C=3D- { MF=3D3/2/1@MG }} !/1 T=3D17563{C=3D17171255{A=3D3/2/1@MG{M = {ST=3D111{{MO=3DSR,tdmc/ec=3DON}}},E=3D2{g/sc},SG{cg/bt{NC=3D{TO}}}}}} - - - - - - - - - - - -=20 B1 (OPTION 1) 3/2/1@MG generates Notify for the IBS signal completion = event on the NULL context,=20 and then the Termination is added to the context and the cg/bt signal is = started.=20 !/1 :2345 T=3D9053 { C=3D- { N=3D3/2/1@MG { OE =3D 1 { 20060814T13351501:G/SC = {METH =3D SD, SIGID =3D CG/RT } } } }} !/1 :2345 P=3D17563 { C=3D17171255 { A =3D 3/2/1@MG } } - - - - - - - - - - - -=20 .... OR B2 (OPTION 2) 3/2/1@MG is first added to the new context and then the = Notify occurs for the IBS=20 signal completion event on the new context using the new event = descriptor. !/1 :2345 P=3D17563 { C=3D17171255 { A =3D 3/2/1@MG } } !/1 :2345 T=3D9053 { C=3D17171255 { N=3D3/2/1@MG { OE =3D 2 { = 20060814T13351501:G/SC { METH =3D TO, SIGID =3D CG/RT } } } }} - - - - - - - - - - - -=20 ... OR=20 B3 - same as B2 except the NTFY could get ahead of the reply to the = transaction containing the add? !/1 :2345 T=3D9053 { C=3D17171255 { N=3D3/2/1@MG { OE =3D 2 { = 20060814T13351501:G/SC { METH =3D TO, SIGID =3D CG/RT } } } }} !/1 :2345 P=3D17563 { C=3D17171255 { A =3D 3/2/1@MG } } _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Aug 14 17:54:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCkOf-00015S-PL; Mon, 14 Aug 2006 17:54:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCkOd-00015N-U7 for megaco@ietf.org; Mon, 14 Aug 2006 17:54:55 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCkOb-0006xb-Im for megaco@ietf.org; Mon, 14 Aug 2006 17:54:55 -0400 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7ELsoK09856 for ; Mon, 14 Aug 2006 17:54:51 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Megaco] which error code replaces error code 540 (Unexpected Initial Hook State)? Date: Mon, 14 Aug 2006 17:54:47 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A0588F3@zrtphxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] which error code replaces error code 540 (Unexpected Initial Hook State)? Thread-Index: Aca9JrRvS27jbgiyRWeNNtwRfcakywCuvWbg From: "Kevin Boyle" To: , "Oikonomou, Ioannis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Package-specific error codes are defined in the relevant package. Only "generic" error codes live in H.248.8. See the package definition guidelines in Clause 12.1.6/H.248.1 V3. Kevin -----Original Message----- From: Albrecht.Schwarz@alcatel.de [mailto:Albrecht.Schwarz@alcatel.de] Sent: Friday, August 11, 2006 4:59 AM To: Oikonomou, Ioannis Cc: megaco@ietf.org Subject: Re: [Megaco] which error code replaces error code 540 (Unexpected Initial Hook State)? Ioannis, it was not removed, it was moved to clause § E.9.5/H.248.1 V3 to my knowledge. I don't remember the underlying discussion, but I think we concluded to put package-specific error codes in the package definitions itself. That's why #540 was moved in the al package spec. - Albrecht "Oikonomou, Ioannis" iemens.com> cc: Subject: [Megaco] which error code replaces error code 540 (Unexpected Initial 10.08.2006 22:12 Hook State)? Hello, I just realized that in the latest version of H.248.8 (09/2005), the error code 540 (Unexpected Initial Hook State) has been removed! What error code are we supposed to use now for the detection of hook state with 'failWrong' parameter? Ioannis Oikonomou Senior Software Engineer Siemens SA Greece _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Aug 15 12:23:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD1go-0005X1-QN; Tue, 15 Aug 2006 12:22:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD1gn-0005Wv-Ma for megaco@ietf.org; Tue, 15 Aug 2006 12:22:49 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD1gm-0006Rx-Ck for megaco@ietf.org; Tue, 15 Aug 2006 12:22:49 -0400 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7FGMa202767 for ; Tue, 15 Aug 2006 12:22:37 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Megaco] ServiceChange indicating multiple terminations Date: Tue, 15 Aug 2006 12:22:33 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A05920C@zrtphxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] ServiceChange indicating multiple terminations Thread-Index: Aca8vG0qmNc2TaLURRSMRnNPUHQMKwDym2nA From: "Kevin Boyle" To: "Oikonomou, Ioannis" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org In reference to your second question below, you are trying to construct text encoding using the ASN.1 definition. ASN.1 is for binary encoding, and is not suitable for text construction. You need to reference Annex B, which contains the ABNF encoding rules. Kevin ________________________________ From: Oikonomou, Ioannis [mailto:Ioannis.Oikonomou@siemens.com] Sent: Thursday, August 10, 2006 4:35 PM To: megaco@ietf.org Subject: [Megaco] ServiceChange indicating multiple terminations Hello, I have 2 questions concerning the ServiceChange command: 1) ServiceChange(Handoff) is the only ServiceChange command that an MGC is allowed to send towards an MG. Is this correct? 2) Is the following syntax allowed? MEGACO/1 [216.33.33.61]: 25000 Transaction = 4321 { Context = - { ServiceChange = TermA, TermB, TermC { Services { Method = Forced } } } } The syntax for ServiceChange is the following according to H.248.1: ServiceChangeRequest ::= SEQUENCE { terminationID TerminationIDList, serviceChangeParms ServiceChangeParm, ... } TerminationIDList ::= SEQUENCE OF TerminationID TerminationID ::= SEQUENCE { wildcard SEQUENCE OF WildcardField, id OCTET STRING(SIZE(1..8)), ... } WildcardField ::= OCTET STRING(SIZE(1)) Ioannis Oikonomou Senior Software Engineer Siemens SA Greece _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Aug 15 12:56:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2DD-00078x-Tk; Tue, 15 Aug 2006 12:56:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2DC-00078s-U5 for Megaco@ietf.org; Tue, 15 Aug 2006 12:56:18 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD2DB-0008PJ-J0 for Megaco@ietf.org; Tue, 15 Aug 2006 12:56:18 -0400 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7FGuFc12960 for ; Tue, 15 Aug 2006 12:56:15 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Megaco] Question regarding the order of commands for the InterruptByNewSignalsDesc signal completion event Date: Tue, 15 Aug 2006 12:56:13 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A0592C0@zrtphxm2.corp.nortel.com> In-Reply-To: <97D8957C5565BB41912C3F958914C49F279A75@sonusmail06.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Question regarding the order of commands for the InterruptByNewSignalsDesc signal completion event Thread-Index: Aca2zaPmW9lElHrNR2OeMg3wHJiAdwI5/SPgADUwnoA= From: "Kevin Boyle" To: "Kamitses, Jerry" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Because the signal is interrupted by the application of the new Signals Descriptor in the course of applying the new command, I believe the proper way here is to 1) apply each descriptor in the new command, 2) generate the Notify Command that resulted from the application of the new Signals Descriptor, 3) respond indicating success of the command. So, in this instance, I believe B1 to be the correct choice. Unfortunately, I know of no direct text in the spec that would outline this ordering, other than the text that indicates that transactions and commands are executed in the order in which they appear. You did provide an example where the messaging gets out of order for example B2. I would note that this could also happen with B1, such that the Add Reply could appear before the Notify Command. So, ordering is not a problem solely for the second answer scenario you described. Either way, it is possible that the MGC could reject the Notify Command as having a context mismatch. However, well-written implementations would keep track of the fact that a context change is likely to occur and account for the possibility of out-of-order message receipt on unreliable transports. Kevin -----Original Message----- From: Kamitses, Jerry [mailto:jkamitses@sonusnet.com] Sent: Monday, August 14, 2006 1:06 PM To: Megaco@ietf.org Subject: [Megaco] Question regarding the order of commands for the InterruptByNewSignalsDesc signal completion event Please comment on which of these optional sequences are Megaco V1 compliant (and the applicable bits of the spec. used as rationale). Note that by "compliant" we are asking which sequences a Megaco V1 compliant MGC should be able to handle. "A" denotes the starting condition, and the three apparently valid options appear labeled B1, B2, and B3 (A) Modify command on NULL context sent to the termination 3/2/1@MG to play cg/rg Then Add sent to 3/2/1@MG placing this termination into the context 17171255, stopping the cg/rt signal, and starting the cg/bt signal. !/1 T=17562{C=-{MF=3/2/1@MG {E=1{g/sc},SG{cg/rt{NC={TO,IBE,IBS}}}}}} !/1 :2345 P=17562 { C=- { MF=3/2/1@MG }} !/1 T=17563{C=17171255{A=3/2/1@MG{M {ST=111{{MO=SR,tdmc/ec=ON}}},E=2{g/sc},SG{cg/bt{NC={TO}}}}}} - - - - - - - - - - - - B1 (OPTION 1) 3/2/1@MG generates Notify for the IBS signal completion event on the NULL context, and then the Termination is added to the context and the cg/bt signal is started. !/1 :2345 T=9053 { C=- { N=3/2/1@MG { OE = 1 { 20060814T13351501:G/SC {METH = SD, SIGID = CG/RT } } } }} !/1 :2345 P=17563 { C=17171255 { A = 3/2/1@MG } } - - - - - - - - - - - - .... OR B2 (OPTION 2) 3/2/1@MG is first added to the new context and then the Notify occurs for the IBS signal completion event on the new context using the new event descriptor. !/1 :2345 P=17563 { C=17171255 { A = 3/2/1@MG } } !/1 :2345 T=9053 { C=17171255 { N=3/2/1@MG { OE = 2 { 20060814T13351501:G/SC { METH = TO, SIGID = CG/RT } } } }} - - - - - - - - - - - - ... OR B3 - same as B2 except the NTFY could get ahead of the reply to the transaction containing the add? !/1 :2345 T=9053 { C=17171255 { N=3/2/1@MG { OE = 2 { 20060814T13351501:G/SC { METH = TO, SIGID = CG/RT } } } }} !/1 :2345 P=17563 { C=17171255 { A = 3/2/1@MG } } _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Aug 15 13:01:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2Hr-0000YF-OM; Tue, 15 Aug 2006 13:01:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2Hq-0000YA-Jn for megaco@ietf.org; Tue, 15 Aug 2006 13:01:06 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD2Hp-00008a-8a for megaco@ietf.org; Tue, 15 Aug 2006 13:01:06 -0400 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7FH12217191 for ; Tue, 15 Aug 2006 13:01:02 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Megaco] Error format Date: Tue, 15 Aug 2006 13:00:58 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A0592D7@zrtphxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Error format Thread-Index: Acaw5QmUI5vsaTjBQD6ZqDeHf9DQqgFkVbuAAoViOOA= From: "Kevin Boyle" To: "Wainwright, John \(Com US\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Remember that descriptors don't fail -- commands do. If there is something in a descriptor that causes a command to fail, then the entire command fails. So, for commands that result in the creation of terminations or contexts (in the case of a single add or move into a CHOOSE context), the termination and/or context in question do NOT come into existence. The command must succeed in order for the element to be created. I will also note that the Error Descriptor has no such restriction that only the information suggested in the Error Code definitions be present. As long as that information is present, the entity sending the Error Descriptor is free to put other information in the Error Descriptor as well. Kevin -----Original Message----- From: Wainwright, John (Com US) [mailto:john.wainwright@siemens.com] Sent: Wednesday, August 02, 2006 5:03 PM To: megaco@ietf.org Subject: RE: [Megaco] Error format As a follow on to this question, if the original ADD request involved a CHOOSE ($) for the ephemeral then if for example there was an error in the Local Descriptor, such as codec not supported, would the response indicate a failure for ADD of a specific Ephemeral termination or would the entire ADD for the ephemeral fail with the response indicating $ for its terminationId ? i.e. ADD = eph/00337 { ERROR = 515 {"Unsupported Media Type"} Or ADD = $ { ERROR = 515 {"Unsupported Media Type"} Thanks John -----Original Message----- From: Ashish Singh [mailto:ashishs@redback.com] Sent: Wednesday, July 26, 2006 1:55 PM To: Wainwright, John (Com US) Cc: megaco@ietf.org Subject: Re: [Megaco] Error format I guess it will be easier for MGC to parse, if we only include "streamID" and no other text. IMO, error descriptor should look like: ERROR = 515 {"xxx"} Thanks Ashish Wainwright, John (Com US) wrote: > So would a more accurate response have something like the following > ERROR = 515 {"Unsupported Media Type. Stream = xxx" > > If "Stream = 1" can it be omitted and assumed by default ? > > Thanks > John > > > -----Original Message----- > From: Ashish Singh [mailto:ashishs@redback.com] > Sent: Wednesday, July 26, 2006 11:36 AM > To: Wainwright, John (Com US) > Cc: megaco@ietf.org > Subject: Re: [Megaco] Error format > > Hi John, > > The response is correct from syntax point of view. But H.248.8 mentions > to include "stream ID" as Error text for this particular error code. > > There are many other error codes, for which extra information is > required. Like with error codes 433 and 435, contextID is returned, so > that MGC can synchronize its database. > > Thanks > Ashish > > > Wainwright, John (Com US) wrote: > >> Is the following format 'valid' for a response to an ADD request >> containing an unsupported codec in the Local descriptor? Would the >> same format apply, apart from the error code and text, for any other >> type of error in the SDP data within the Local descriptor ? >> >> MEGACO/2 [20.0.4.32]:2084 >> REPLY = 269820167 { >> CONTEXT = 13 { >> ADD = port_1 >> , >> ADD = eph/00337 { >> ERROR = 515 {"Unsupported Media Type"} >> } >> } >> } >> >> Thanks >> John >> >> >> > ------------------------------------------------------------------------ > >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> >> > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Aug 15 13:25:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2fH-0007Zq-04; Tue, 15 Aug 2006 13:25:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2fG-0007Zl-G1 for megaco@ietf.org; Tue, 15 Aug 2006 13:25:18 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD2fE-0001BX-6y for megaco@ietf.org; Tue, 15 Aug 2006 13:25:18 -0400 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7FHPBs04032 for ; Tue, 15 Aug 2006 13:25:11 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Megaco] Add Command Date: Tue, 15 Aug 2006 13:24:47 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A059372@zrtphxm2.corp.nortel.com> In-Reply-To: <31F31018FE2DC941A70BD30477510B0C0B2579B5@biscm02.cn001.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Add Command Thread-Index: AcaxXXTQZWZEP6wXS3yIIa1Pux7gIgPMX39g From: "Kevin Boyle" To: "Liu Ti, SLC Com FN RDC NA\(BJ\)" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org The commands must contain enough information (through the inclusion of the appropriate descriptors) for the receiver to be able to execute the command successfully. There may be situations where the MG has enough information ahead of time that the MG does not require any descriptors to perform the Add Command. When creating an ephemeral termination, I would think that the MGC would have to provide some information, so that the MG can build the correct kind of termination. However, I can conceive of an MG that would already have knowledge how to build ephemerals without needing additional SDP information and the like. It would all depend upon the MG and what it needs to execute the command in question. Kevin ________________________________ From: Liu Ti,SLC Com FN RDC NA(BJ) [mailto:ti.liu@siemens.com] Sent: Wednesday, July 26, 2006 4:30 AM To: megaco@ietf.org; megaco@DOMAIN.HIDDEN Subject: [Megaco] Add Command Hi All: Does there exist such situation: 1 An Add Command does not have any descriptor as parameters. 2 An Add command,used to create a Termination, does not have any descriptor as parameters. Thanks in advance. B.R Ti _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Aug 15 14:13:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3QB-0006Pe-17; Tue, 15 Aug 2006 14:13:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2V5-0004JP-Fa for megaco@ietf.org; Tue, 15 Aug 2006 13:14:47 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD2V3-0000gT-7q for megaco@ietf.org; Tue, 15 Aug 2006 13:14:47 -0400 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7FHEgc20206 for ; Tue, 15 Aug 2006 13:14:43 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=" line Date: Tue, 15 Aug 2006 13:14:41 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A05933A@zrtphxm2.corp.nortel.com> In-Reply-To: <44D6EF88.2040700@nteczone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=" line Thread-Index: Aca6I43NYDLS/r6gTQqACTfbM0v2swGaenzA From: "Kevin Boyle" To: "Christian Groves" , "Christer Holmberg \(JO/LMF\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 279ce412016247daf4102ab2990fbce0 X-Mailman-Approved-At: Tue, 15 Aug 2006 14:13:45 -0400 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org 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:Christian.Groves@nteczone.com] Sent: Monday, August 07, 2006 3:45 AM To: Christer Holmberg (JO/LMF) Cc: megaco@ietf.org Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=" line Hello Christer, Please see my response below [CNG]. Cheers, Christian Christer Holmberg (JO/LMF) wrote: >Hi Christian, > > > >>You could use: >> >>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". > > [CNG] Isn't the format of m=?: m= and for "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 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. > > [CNG] At least we agree that H.248.1 isn't the place to do it. The key is the syntax allows it. > > >>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). > > > [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. >>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. >> >> > >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. >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: > > > >>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:Christian.Groves@nteczone.com] >>Sent: 4. elokuuta 2006 4:28 >>To: CHATRAS Bruno RD-CORE-ISS >>Cc: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de; >>megaco@ietf.org; Campos, Simao >>Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value >>'-'in SDP"m=" line >> >>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:christer.holmberg@ericsson.com] >>>Envoyé : mardi 25 juillet 2006 09:34 >>>À : Christian Groves; Albrecht.Schwarz@alcatel.de Cc : CHATRAS Bruno >>>RD-CORE-ISS; megaco@ietf.org; 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" >>>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 >>> >>>Albrecht.Schwarz@alcatel.de 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" , "CHATRAS Bruno RD-CORE-ISS" >>>> , Albrecht SCHWARZ/DE/ALCATEL@ALCATEL >>>> icsson.com> cc: megaco@ietf.org >>>> 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:kboyle@nortel.com] >>>>Sent: 21. heinäkuuta 2006 17:23 >>>>To: Christer Holmberg (JO/LMF); CHATRAS Bruno RD-CORE-ISS; >>>>Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>>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:christer.holmberg@ericsson.com] >>>>Sent: Friday, July 21, 2006 5:18 AM >>>>To: CHATRAS Bruno RD-CORE-ISS; Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>>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:bruno.chatras@orange-ft.com] >>>>Sent: 21. heinäkuuta 2006 10:26 >>>>To: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>>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:christer.holmberg@ericsson.com] >>>>Envoyé : jeudi 20 juillet 2006 20:46 À : Albrecht.Schwarz@alcatel.de >>>>Cc : megaco@ietf.org 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: Albrecht.Schwarz@alcatel.de >>>>[mailto:Albrecht.Schwarz@alcatel.de] >>>>Sent: 20. heinäkuuta 2006 12:00 >>>>To: Christer Holmberg (JO/LMF) >>>>Cc: megaco@ietf.org >>>>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" >>>>, "B Venkat S.R Swamy" >>>> >>>, "Christian Groves" >>>> >>>> icsson.com> cc: Albrecht >>>>SCHWARZ/DE/ALCATEL@ALCATEL, megaco@ietf.org >>>> 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:kboyle@nortel.com] >>>>Sent: 17. heinäkuuta 2006 19:58 >>>>To: B Venkat S.R Swamy; Christian Groves >>>>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; 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:b.swamy@flextronicssoftware.com] >>>>Sent: Monday, July 17, 2006 12:40 AM >>>>To: Christian Groves >>>>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; >>>>christer.holmberg@ericsson.com >>>>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 >>>> >>>> >>>> >>>> >>>> Christian Groves >>>> >>>> >>>> 07/17/2006 06:36 AM >>>> >>>> >>>> >>>>To >>>> >>>>Albrecht.Schwarz@alcatel.de >>>> >>>> >>>>cc >>>> >>>>B Venkat S.R Swamy/HSS@HSS, megaco@ietf.org, >>>>christer.holmberg@ericsson.com >>>> >>>> >>>>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 >>>> >>>>Albrecht.Schwarz@alcatel.de 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" >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>SCHWARZ/DE/ALCATEL@ALCATEL >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> ftware.com> cc: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>megaco@ietf.org, christer.holmberg@ericsson.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> 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)Albrecht.Schwarz@alcatel.de >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>christer.holmberg@ericsson.com, >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> taylor@nortel.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> (Embedded image moved to file: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> pic31609.gif) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>cc >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> (Embedded image moved to >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>file: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> pic17314.gif) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> megaco@ietf.org >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> (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 >>>>>Megaco@ietf.org >>>>>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 >>>>>Megaco@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-------------------------------------------------------------------- >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>------------------------------------------------------------------- >>>>>- >>>>>- >>>>>- >>>>>- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>_______________________________________________ >>>>>Megaco mailing list >>>>>Megaco@ietf.org >>>>>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 >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >> >> >> >> >> >> >> > > > > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Aug 15 19:30:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD8MH-0005uZ-5A; Tue, 15 Aug 2006 19:30:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD8MF-0005uT-UH for megaco@ietf.org; Tue, 15 Aug 2006 19:30:03 -0400 Received: from [203.145.155.1] (helo=spark.hss.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD8ME-0006pC-2Y for megaco@ietf.org; Tue, 15 Aug 2006 19:30:03 -0400 Received: from Dlfmail1.hss.hns.com (dlfmail1 [10.203.142.23]) by spark.hss.co.in (8.13.6/8.13.6) with ESMTP id k7FNStpS007477 for ; Wed, 16 Aug 2006 04:58:56 +0530 (IST) Importance: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 From: Shobhit Bansal To: megaco@ietf.org Date: Wed, 16 Aug 2006 04:57:59 +0530 Message-ID: X-MIMETrack: Serialize by Notes Server on Jhankar/HSS(Release 6.5|September 26, 2003) at 08/16/2006 04:57:59 AM, Serialize complete at 08/16/2006 04:57:59 AM, Itemize by Notes Server on Jhankar/HSS(Release 6.5|September 26, 2003) at 08/16/2006 04:57:59 AM, Serialize by Router on Dlfmail1/HSS(Release 6.5.2|June 01, 2004) at 08/16/2006 04:59:09 AM, Serialize complete at 08/16/2006 04:59:09 AM MIME-Version: 1.0 X-Spam-Score: 2.7 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Megaco] Validating RTP stream X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0944494094==" Errors-To: megaco-bounces@ietf.org --===============0944494094== Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Hi all,
 
I have some basic questio= ns regarding the media streams.
 
Lets say we have= an ephemeral termination with valid local descriptor (ip addr 192.168.1.10= 0, port 5004) and remote descriptor (ip addr 10.10.4.5, port 6010).
 
1> I understand that remote descriptor means that th= e RTP going out will have the destination ip address as 10.10.4.5 and = port 6010 but can we assume that the RTP stream that will be coming fr= om the other end with have the source ip as 10.10.4.5 and port 6010 ?<= /DIV>
 
2> If not, is there a parameter by which we c= an confirm that the RTP stream is valid or not. Consider a scenario where a= termination is malfunctioning and keeps on generating RTP stream towards t= his ephemeral. How can we reject this RTP stream ?
 
Thanks and regards
Shobhit Bansal
Technical Leader
Flextronics Software Systems

*****FSS-Unclassified= *****" DISCLAIMER: This message is proprietary to Flextronics Software Sys= tems Limited (FSS) and is intended solely for the use of the individual to = whom it is addressed. It may contain privileged or confidential informatio= n 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 noti= fy the originator immediately. If you are not the intended recipient, y= ou are notified that you are strictly prohibited from using, copying= 4; 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."= --===============0944494094== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0944494094==-- From megaco-bounces@ietf.org Wed Aug 16 03:43:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDG3f-0000Sq-AD; Wed, 16 Aug 2006 03:43:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDG3d-0000Sg-0w for megaco@ietf.org; Wed, 16 Aug 2006 03:43:21 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDG3b-00040M-IV for megaco@ietf.org; Wed, 16 Aug 2006 03:43:20 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.11.20060308/8.12.11/ICT TSC MAIL 2005) with ESMTP id k7G7h2Ep031155; Wed, 16 Aug 2006 09:43:02 +0200 In-Reply-To: Subject: RTP crosstalk; Re: [Megaco] Validating RTP stream To: Shobhit Bansal X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Albrecht.Schwarz@alcatel.de Date: Wed, 16 Aug 2006 09:43:01 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/16/2006 09:43:02 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 0.2 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Shobhit: >1: Depends on symmetrical or asymmetrical RTP/IP. You cannot per se suppose symmetry. >2: via "source address/port filtering" See e.g. Draft H.248 Series Supp. X RTPXtalk (H.248.43 (ex. H.248.RTPXtalk)) Guidelines for Resource Management of Resources for H.248 RTP Terminations Note: this Supplement is particularly discussing "... malfunctioning and keeps on generating RTP stream ...", called "RTP crosstalk". ETSI H.248 gm package in ETSI TS 102 333 Work item on Draft H.248.gmgc - Albrecht Shobhit Bansal cc: Subject: [Megaco] Validating RTP stream 16.08.2006 01:27 Hi all, I have some basic questions regarding the media streams. Lets say we have an ephemeral termination with valid local descriptor (ip addr 192.168.1.100, port 5004) and remote descriptor (ip addr 10.10.4.5, port 6010). 1> I understand that remote descriptor means that the RTP going out will have the destination ip address as 10.10.4.5 and port 6010 but can we assume that the RTP stream that will be coming from the other end with have the source ip as 10.10.4.5 and port 6010 ? 2> If not, is there a parameter by which we can confirm that the RTP stream is valid or not. Consider a scenario where a termination is malfunctioning and keeps on generating RTP stream towards this ephemeral. How can we reject this RTP stream ? Thanks and regards Shobhit Bansal Technical Leader Flextronics Software Systems *****FSS-Unclassified *****" 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 Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Aug 16 05:02:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDHIV-00088R-By; Wed, 16 Aug 2006 05:02:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDHIU-00088M-6o for megaco@ietf.org; Wed, 16 Aug 2006 05:02:46 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17] helo=jaguar.hss.hns.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDHIP-000079-Vk for megaco@ietf.org; Wed, 16 Aug 2006 05:02:46 -0400 Received: from jaguar.hss.hns.com (localhost [127.0.0.1]) by jaguar.hss.hns.com (8.13.6/8.12.10) with ESMTP id k7G944Jt029855 for ; Wed, 16 Aug 2006 14:34:04 +0530 (IST) Received: from webmail.hss.hns.com (webmail.hss.hns.com [10.203.158.17]) by jaguar.hss.hns.com (8.13.6/8.13.6) with ESMTP id k7G940GV029725; Wed, 16 Aug 2006 14:34:03 +0530 (IST) In-Reply-To: Subject: Re: RTP crosstalk; Re: [Megaco] Validating RTP stream To: Albrecht.Schwarz@alcatel.de X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: "B Venkat S.R Swamy" Date: Wed, 16 Aug 2006 13:55:02 +0530 X-MIMETrack: Serialize by Router on WebMail/HSS(Release 6.5.2|June 01, 2004) at 08/16/2006 02:32:32 PM MIME-Version: 1.0 X-Spam-Score: 1.2 (+) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0874103089==" Errors-To: megaco-bounces@ietf.org --===============0874103089== Content-type: multipart/related; Boundary="0__=EABBFB5FDFA20D3F8f9e8a93df938690918cEABBFB5FDFA20D3F" Content-Disposition: inline --0__=EABBFB5FDFA20D3F8f9e8a93df938690918cEABBFB5FDFA20D3F Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Hi

Regarding "Source address/port filtering", how does Session c= ontroller know the RTP
source address/port to be used for filtering, since Remote Descriptor o= nly specifies what port remote is listening.
Is it a provisioning data or there is some other signalling mechansim.=


regards
B Venkat S.R Swamy
Senior Technical Leader
Flextronics Software Systems
Phone: +91-124- 4176213
Fax: +91-124-4300247
web: www.flextronicssoftware.com
3D"InactiveAlbrecht.Schwarz@alcatel.de


=
          Albrecht.Schwarz@alcatel.de

          08/16/2006 01:13 PM

 =
3D""
To
3D""
Shobhit Bansal/HSS@HSS
3D""
cc
3D""
megaco@ietf.org
3D""
Subject
3D""
RTP crosstalk; Re: [Megaco] Validating RTP stream
=3D""3D""<= /td>


Shobhit:

>1:
Depends on symmetrical or asymmetrical RTP/IP.
You cannot per se suppose symmetry.

>2:
via "source address/port filtering"

See e.g.
     Draft H.248 Series Supp. X RTPXtalk (H.248.43 (ex.= H.248.RTPXtalk))
     Guidelines for Resource Management of Resources fo= r H.248 RTP
     Terminations

     Note: this Supplement is particularly discussing &= quot;... malfunctioning
     and keeps on generating RTP stream ...", call= ed "RTP crosstalk".

     ETSI H.248 gm package in ETSI TS 102 333
     Work item on Draft H.248.gmgc

- Albrecht



                    =                     &= nbsp;                   &n= bsp;                   &nb= sp;                   &nbs= p;                    = ;                    =    
                    =  Shobhit Bansal               &= nbsp;                   &n= bsp;                   &nb= sp;                   &nbs= p;                    = ;              
                    =  <shobhit.bansal@flextronicsso         To: =      megaco@ietf.org           =                     &= nbsp;                   &n= bsp;          
                    =  ftware.com>               &= nbsp;           cc:        = ;                    =                     =                     &= nbsp;            
                    =                     &= nbsp;                  Sub= ject: [Megaco] Validating RTP stream          =                     =                
                    =  16.08.2006 01:27              =                     =                     &= nbsp;                   &n= bsp;                   &nb= sp;            
                    =                     &= nbsp;                   &n= bsp;                   &nb= sp;                   &nbs= p;                    = ;                    =    




Hi all,

I have some basic questions regarding the media streams.

Lets say we have an ephemeral termination with valid local descriptor (= ip
addr 192.168.1.100, port 5004) and remote descriptor (ip addr 10.10.4.5= ,
port 6010).

1> I understand that remote descriptor means that the RTP going out = will
have the destination ip address as 10.10.4.5 and port 6010 but can we assume that the RTP stream that will be coming from the other end with = have
the source ip as 10.10.4.5 and port 6010 ?

2> If not, is there a parameter by which we can confirm that the RTP= stream
is valid or not. Consider a scenario where a termination is malfunction= ing
and keeps on generating RTP stream towards this ephemeral. How can we reject this RTP stream ?

Thanks and regards
Shobhit Bansal
Technical Leader
Flextronics Software Systems

*****FSS-Unclassified *****" DISCLAIMER: This message is proprieta= ry to
Flextronics Software Systems Limited (FSS) and is intended solely for t= he
use of the individual to whom it is addressed. It may contain privilege= d 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 prohibit= ed
from using, copying, altering, or disclosing the contents of this messa= ge.
FSS accepts no responsibility for loss or damage arising from the use o= f
the information transmitted by this email including damage from virus.&= quot;
_______________________________________________
Megaco mailing list
Megaco@ietf.org
http= s://www1.ietf.org/mailman/listinfo/megaco





_______________________________________________
Megaco mailing list
Megaco@ietf.org
http= s://www1.ietf.org/mailman/listinfo/megaco



*********************** FSS-Restricted ***********************
"DISCLAIMER: This message is proprietary to Flextronics Software <= br> 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."= --0__=EABBFB5FDFA20D3F8f9e8a93df938690918cEABBFB5FDFA20D3F Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <00__=EABBFB5FDFA20D3F@flextronicssoftware.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=EABBFB5FDFA20D3F8f9e8a93df938690918cEABBFB5FDFA20D3F Content-type: image/gif; name="pic24084.gif" Content-Disposition: inline; filename="pic24084.gif" Content-ID: <10__=EABBFB5FDFA20D3F@flextronicssoftware.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=EABBFB5FDFA20D3F8f9e8a93df938690918cEABBFB5FDFA20D3F Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=EABBFB5FDFA20D3F@flextronicssoftware.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=EABBFB5FDFA20D3F8f9e8a93df938690918cEABBFB5FDFA20D3F-- --===============0874103089== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0874103089==-- From megaco-bounces@ietf.org Wed Aug 16 07:13:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDJKD-0003bC-8E; Wed, 16 Aug 2006 07:12:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDJKB-0003b7-As for megaco@ietf.org; Wed, 16 Aug 2006 07:12:39 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDJK7-0004KW-Kb for megaco@ietf.org; Wed, 16 Aug 2006 07:12:39 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.11.20060308/8.12.11/ICT TSC MAIL 2005) with ESMTP id k7GBCNHM029392; Wed, 16 Aug 2006 13:12:23 +0200 In-Reply-To: Subject: Re: RTP crosstalk; Re: [Megaco] Validating RTP stream To: "B Venkat S.R Swamy" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Albrecht.Schwarz@alcatel.de Date: Wed, 16 Aug 2006 13:12:21 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/16/2006 13:12:22 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=4EBBFB5FDFAF3AEF8f9e8a93df938690918c4EBBFB5FDFAF3AEF" Content-Disposition: inline X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org --0__=4EBBFB5FDFAF3AEF8f9e8a93df938690918c4EBBFB5FDFAF3AEF Content-type: text/plain; charset=us-ascii In my opinion: a) provisioning => Not possible. b) implicit "signalling" by 'symmetry assumptions' => possible [Note: this is then an underlying operations requirement for all RTP equipment in such a RTP domain.] c) explicit signalling, e.g. via gm package (gm properties saf, sam, spf, spr) => possible [Note: implies of course that the MGC has access on such information, from call/session control signalling; or from a database in case of "static configurations"] - Albrecht PS Venkat: if you've still concerns/question, then I would appreciate contributions against Draft ITU-T H.Sup.RTPXtalk. "B Venkat S.R Swamy" cc: megaco@ietf.org Subject: Re: RTP crosstalk; Re: [Megaco] Validating RTP stream 16.08.2006 10:25 Hi Regarding "Source address/port filtering", how does Session controller know the RTP source address/port to be used for filtering, since Remote Descriptor only specifies what port remote is listening. Is it a provisioning data or there is some other signalling mechansim. 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: pic09542.gif)Albrecht.Schwarz@alcatel.de Albrecht.S chwarz@alc atel.de (Embedded image moved to file: pic26157.gif) 08/16/2006 To 01:13 PM (Embedded image moved to file: pic18290.gif) Shobhit Bansal/HSS@HSS (Embedded image moved to file: pic02576.gif) cc (Embedded image moved to file: pic14905.gif) megaco@ietf.org (Embedded image moved to file: pic04288.gif) Subject (Embedded image moved to file: pic24019.gif) RTP crosstalk; Re: [Megaco] Validating RTP stream (Embedded image moved to file: pic03378.gif) (Embedded image moved to file: pic11584.gif) Shobhit: >1: Depends on symmetrical or asymmetrical RTP/IP. You cannot per se suppose symmetry. >2: via "source address/port filtering" See e.g. Draft H.248 Series Supp. X RTPXtalk (H.248.43 (ex. H.248.RTPXtalk)) Guidelines for Resource Management of Resources for H.248 RTP Terminations Note: this Supplement is particularly discussing "... malfunctioning and keeps on generating RTP stream ...", called "RTP crosstalk". ETSI H.248 gm package in ETSI TS 102 333 Work item on Draft H.248.gmgc - Albrecht Shobhit Bansal cc: Subject: [Megaco] Validating RTP stream 16.08.2006 01:27 Hi all, I have some basic questions regarding the media streams. Lets say we have an ephemeral termination with valid local descriptor (ip addr 192.168.1.100, port 5004) and remote descriptor (ip addr 10.10.4.5, port 6010). 1> I understand that remote descriptor means that the RTP going out will have the destination ip address as 10.10.4.5 and port 6010 but can we assume that the RTP stream that will be coming from the other end with have the source ip as 10.10.4.5 and port 6010 ? 2> If not, is there a parameter by which we can confirm that the RTP stream is valid or not. Consider a scenario where a termination is malfunctioning and keeps on generating RTP stream towards this ephemeral. How can we reject this RTP stream ? Thanks and regards Shobhit Bansal Technical Leader Flextronics Software Systems *****FSS-Unclassified *****" 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 Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org 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 Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --0__=4EBBFB5FDFAF3AEF8f9e8a93df938690918c4EBBFB5FDFAF3AEF Content-type: image/gif; name="pic09542.gif" Content-Disposition: attachment; filename="pic09542.gif" Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBFB5FDFAF3AEF8f9e8a93df938690918c4EBBFB5FDFAF3AEF Content-type: image/gif; name="pic26157.gif" Content-Disposition: attachment; filename="pic26157.gif" Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFB5FDFAF3AEF8f9e8a93df938690918c4EBBFB5FDFAF3AEF Content-type: image/gif; name="pic18290.gif" Content-Disposition: attachment; filename="pic18290.gif" Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFB5FDFAF3AEF8f9e8a93df938690918c4EBBFB5FDFAF3AEF Content-type: image/gif; name="pic02576.gif" Content-Disposition: attachment; filename="pic02576.gif" Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFB5FDFAF3AEF8f9e8a93df938690918c4EBBFB5FDFAF3AEF Content-type: image/gif; name="pic14905.gif" Content-Disposition: attachment; filename="pic14905.gif" Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFB5FDFAF3AEF8f9e8a93df938690918c4EBBFB5FDFAF3AEF Content-type: image/gif; name="pic04288.gif" Content-Disposition: attachment; filename="pic04288.gif" Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFB5FDFAF3AEF8f9e8a93df938690918c4EBBFB5FDFAF3AEF Content-type: image/gif; name="pic24019.gif" Content-Disposition: attachment; filename="pic24019.gif" Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFB5FDFAF3AEF8f9e8a93df938690918c4EBBFB5FDFAF3AEF Content-type: image/gif; name="pic03378.gif" Content-Disposition: attachment; filename="pic03378.gif" Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFB5FDFAF3AEF8f9e8a93df938690918c4EBBFB5FDFAF3AEF Content-type: image/gif; name="pic11584.gif" Content-Disposition: attachment; filename="pic11584.gif" Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFB5FDFAF3AEF8f9e8a93df938690918c4EBBFB5FDFAF3AEF Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --0__=4EBBFB5FDFAF3AEF8f9e8a93df938690918c4EBBFB5FDFAF3AEF-- From megaco-bounces@ietf.org Wed Aug 16 07:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDJWc-0007Oa-OQ; Wed, 16 Aug 2006 07:25:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDJWb-0007OV-QF for megaco@ietf.org; Wed, 16 Aug 2006 07:25:29 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDJWa-0005dm-8y for megaco@ietf.org; Wed, 16 Aug 2006 07:25:29 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.11.20060308/8.12.11/ICT TSC MAIL 2005) with ESMTP id k7GBPQT3002905; Wed, 16 Aug 2006 13:25:26 +0200 In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA40A05933A@zrtphxm2.corp.nortel.com> Subject: Replacement of obsoleted RFC 2327 by RFC 4566; RE: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=" line To: "Kevin Boyle" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Albrecht.Schwarz@alcatel.de Date: Wed, 16 Aug 2006 13:25:25 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/16/2006 13:25:26 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 0.2 (/) X-Scan-Signature: 5d7a9cc58ba8f7c7e08dc302757a990b Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org fyi, we've prepared a contribution for the Ottawa meeting, providing an init= ial 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 specificat= ion rules" of the underlying SDP grammar. That means, the basic ABNF gramma= r behind SDP (RFC 2327 or RFC 4566; complemented by =A7 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 th= at this is an implementation specific item, but I'm sure, the experts fami= liar with protocol stack implementations know what I mean.) - Albrecht = =20 "Kevin Boyle" = =20 , "Christer Holmberg =20 om> \(JO/LMF\)" =20 cc: megaco@ietf.org= =20 15.08.2006 19:14 Subject: RE: [Megaco] ET= SI H.248 Ia Profile: issue with media value '-'in SDP"m=3D" =20 line = =20 = =20 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 numbe= r 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 th= e 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 th= e 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:Christian.Groves@nteczone.com] Sent: Monday, August 07, 2006 3:45 AM To: Christer Holmberg (JO/LMF) Cc: megaco@ietf.org Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=3D" line Hello Christer, Please see my response below [CNG]. Cheers, Christian Christer Holmberg (JO/LMF) wrote: >Hi Christian, > > > >>You could use: >> >>m =3D 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". > > [CNG] Isn't the format of m=3D?: m=3D and for "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 H.248.20 does use "-" in the c =3D however it is allowed to do t= his by RFC2327. >> >> > >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. > > >>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=3D line. A subsequent version o= f >>H.248.1 could be based on RFC4566 and would then allow the use of "-"= in m=3D. 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 th= e 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=3D lin= e. If RFC4566 was supported then you wouldn't get the basic syntax error because "-" IS supported in the m=3Dline. 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. >>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. >> >> > >I think TISPAN can continue using "-" even in future versions of the I= a 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 t= o 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 abou= t is needed. > > [CNG] Profiles were about enhancing interoperability. Adding things to syntax, do things in a different way to the core specification certainl= y doesn't assist in those aims. >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: > > > >>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=3D line where we need it. H.248.= 20 uses "-" in the c=3D 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 tha= t the receiver sometimes shall care, and in other cases it doesn't need t= o 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:Christian.Groves@nteczone.com] >>Sent: 4. elokuuta 2006 4:28 >>To: CHATRAS Bruno RD-CORE-ISS >>Cc: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de; >>megaco@ietf.org; Campos, Simao >>Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value >>'-'in SDP"m=3D" line >> >>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 t= o 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:christer.holmberg@ericsson.com] >>>Envoy=E9 : mardi 25 juillet 2006 09:34 >>>=C0 : Christian Groves; Albrecht.Schwarz@alcatel.de Cc : CHATRAS Bru= no >>>RD-CORE-ISS; megaco@ietf.org; Campos, Simao Objet : Re: [Megaco] ETS= I >>>H.248 Ia Profile: issue with media value '-'in SDP"m=3D" 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=3D" line >>>Author: "Christian Groves" >>>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 ou= t 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) the= n "-" is never sent and this can be fixed in the Ia profile which introduced this problem. >>> >>>Regards, Christian >>> >>>Albrecht.Schwarz@alcatel.de wrote: >>> >>> >>> >>> >>> >>> >>> >>>>Hi, >>>> >>>>it's a syntax issue. An implementation following strictly ES 283 01= 8 >>>>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 ou= t >>>>explicitly the syntax extension. >>>> >>>>Thanks, >>>>regards, >>>> >>>>Albrecht >>>> >>>> >>>> >>>> >>>> >>>> "Christer Holmberg >>>> \(JO/LMF\)" To: "Kevin Boyle" , "CHATRAS Bruno RD-CORE-ISS" >>>> , Albrecht SCHWARZ/DE/ALCATEL@ALCATEL >>>> icsson.com> cc: megaco@ietf.org >>>> Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=3D"= 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:kboyle@nortel.com] >>>>Sent: 21. hein=E4kuuta 2006 17:23 >>>>To: Christer Holmberg (JO/LMF); CHATRAS Bruno RD-CORE-ISS; >>>>Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value= >>>>'-'in SDP"m=3D" 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 i= f >>>>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:christer.holmberg@ericsson.com] >>>>Sent: Friday, July 21, 2006 5:18 AM >>>>To: CHATRAS Bruno RD-CORE-ISS; Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value= >>>>'-'in SDP"m=3D" 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:bruno.chatras@orange-ft.com= ] >>>>Sent: 21. hein=E4kuuta 2006 10:26 >>>>To: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value= >>>>'-'in SDP"m=3D" 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 comman= d >>>>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:christer.holmberg@ericsson.com] >>>>Envoy=E9 : jeudi 20 juillet 2006 20:46 =C0 : Albrecht.Schwarz@alcat= el.de >>>>Cc : megaco@ietf.org Objet : RE: [Megaco] ETSI H.248 Ia Profile: >>>>issue with media value '-'in SDP"m=3D" 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 say= s >>>>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: Albrecht.Schwarz@alcatel.de >>>>[mailto:Albrecht.Schwarz@alcatel.de] >>>>Sent: 20. hein=E4kuuta 2006 12:00 >>>>To: Christer Holmberg (JO/LMF) >>>>Cc: megaco@ietf.org >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value= >>>>'-'in SDP "m=3D" 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 conside= r >>>>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" >>>>, "B Venkat S.R Swamy" >>>> >>>, "Christian Groves" >>>> >>>> icsson.com> cc: Albrecht >>>>SCHWARZ/DE/ALCATEL@ALCATEL, megaco@ietf.org >>>> Subject: RE: >>>>[Megaco] ETSI H.248 Ia Profile: issue with media value '-'inSDP"m=3D= " 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=3D line are >>>>defined as tokens. >>>> >>>>media =3D token >>>> ;typically "audio", "video", "text" or >>>> ;"application" >>>> >>>>fmt =3D token >>>> ;typically an RTP payload type for audio >>>> ;and video media >>>> >>>>token =3D 1*(token-char) >>>> >>>>token-char =3D %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-3= 9 / >>>>%x41-5A / %x5E-7E >>>> >>>>(The ascii code for "-" is %x2D) >>>> >>>> >>>>Regards, >>>> >>>>Christer >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Kevin Boyle [mailto:kboyle@nortel.com] >>>>Sent: 17. hein=E4kuuta 2006 19:58 >>>>To: B Venkat S.R Swamy; Christian Groves >>>>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; Christer Holmberg= >>>>(JO/LMF) >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value= >>>>'-'inSDP"m=3D" 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:b.swamy@flextronicssoftware.com] >>>>Sent: Monday, July 17, 2006 12:40 AM >>>>To: Christian Groves >>>>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; >>>>christer.holmberg@ericsson.com >>>>Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value= '-' >>>>inSDP"m=3D" 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=3D" media space port ["/" integer] space proto 1*(space fmt) CRL= F >>>> >>>>media =3D 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 >>>> >>>>"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 >>>> >>>>Albrecht.Schwarz@alcatel.de wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Thanks for pointing to =A7 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 tha= t >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>it >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> is not necessary to specify the value of the parameter in the SD= P >>>>> 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" >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>SCHWARZ/DE/ALCATEL@ALCATEL >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> ftware.com> cc: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>megaco@ietf.org, christer.holmberg@ericsson.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Subject: Re: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>[Megaco] ETSI H.248 Ia Profile: issue with media value '-' in SDP"m=3D" >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> 14.07.2006 05:59 line >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Hi >>>>> >>>>>I support the option 2, and we should try to avoid any violation o= f >>>>>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 th= e >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>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)Albrecht.Schwarz@alcatel.de >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>christer.holmberg@ericsson.com, >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> taylor@nortel.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> (Embedded image moved to file: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> pic31609.gif) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>cc >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> (Embedded image moved to >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>file: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> pic17314.gif) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> megaco@ietf.org >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> (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=3D" 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 =3D *( media-field >>>>> >>>>> >>>>> information-field >>>>> >>>>> >>>>> *(connection-field) >>>>> >>>>> >>>>> bandwidth-fields >>>>> >>>>> >>>>> key-field >>>>> >>>>> >>>>> attribute-fields ) >>>>> >>>>> >>>>> media-field =3D "m=3D" media space port ["/" integer] >>>>> >>>>> >>>>> space proto 1*(space fmt) CRLF >>>>> >>>>> >>>>> media =3D 1*(alpha-numeric) >>>>> >>>>> >>>>> ;typically "audio", "video", "application" >>>>> >>>>> >>>>> ;or "data" >>>>> >>>>> >>>>>RFC 3108: >>>>> >>>>> >>>>>media-descriptions =3D *(media-description) >>>>> >>>>> >>>>>media-description =3D media-field information-field >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>*(connection-field) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> bandwidth-fields key-field attribute-fields >>>>> >>>>> >>>>>media-field =3D 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 =3D "m=3D" media space vcId space transport-fmts E= OL >>>>> >>>>> >>>>> ; superset of RFC 2327 definition >>>>> >>>>> >>>>>media =3D "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) >>>>> >>>>> = _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Aug 16 11:17:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDN9D-00058P-EU; Wed, 16 Aug 2006 11:17:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDGID-00056b-G1 for megaco@ietf.org; Wed, 16 Aug 2006 03:58:25 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDGIA-0004dO-Oj for megaco@ietf.org; Wed, 16 Aug 2006 03:58:25 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.11.20060308/8.12.11/ICT TSC MAIL 2005) with ESMTP id k7G7wLcw006491; Wed, 16 Aug 2006 09:58:21 +0200 In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA40A05933A@zrtphxm2.corp.nortel.com> Subject: Replacement of obsoleted RFC 2327 by RFC 4566; RE: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=" line To: "Kevin Boyle" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Albrecht.Schwarz@alcatel.de Date: Wed, 16 Aug 2006 09:58:18 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/16/2006 09:58:20 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8d87e090b7fa4c4a6c55b799a14c2a67 X-Mailman-Approved-At: Wed, 16 Aug 2006 11:17:33 -0400 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org fyi, we've prepared a contribution for the Ottawa meeting, providing an init= ial 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 specificat= ion rules" of the underlying SDP grammar. That means, the basic ABNF gramma= r behind SDP (RFC 2327 or RFC 4566; complemented by =A7 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 th= at this is an implementation specific item, but I'm sure, the experts fami= liar with protocol stack implementations know what I mean.) - Albrecht = =20 "Kevin Boyle" = =20 , "Christer Holmberg =20 om> \(JO/LMF\)" =20 cc: megaco@ietf.org= =20 15.08.2006 19:14 Subject: RE: [Megaco] ET= SI H.248 Ia Profile: issue with media value '-'in SDP"m=3D" =20 line = =20 = =20 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 numbe= r 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 th= e 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 th= e 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:Christian.Groves@nteczone.com] Sent: Monday, August 07, 2006 3:45 AM To: Christer Holmberg (JO/LMF) Cc: megaco@ietf.org Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=3D" line Hello Christer, Please see my response below [CNG]. Cheers, Christian Christer Holmberg (JO/LMF) wrote: >Hi Christian, > > > >>You could use: >> >>m =3D 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". > > [CNG] Isn't the format of m=3D?: m=3D and for "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 H.248.20 does use "-" in the c =3D however it is allowed to do t= his by RFC2327. >> >> > >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. > > >>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=3D line. A subsequent version o= f >>H.248.1 could be based on RFC4566 and would then allow the use of "-"= in m=3D. 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 th= e 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=3D lin= e. If RFC4566 was supported then you wouldn't get the basic syntax error because "-" IS supported in the m=3Dline. 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. >>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. >> >> > >I think TISPAN can continue using "-" even in future versions of the I= a 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 t= o 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 abou= t is needed. > > [CNG] Profiles were about enhancing interoperability. Adding things to syntax, do things in a different way to the core specification certainl= y doesn't assist in those aims. >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: > > > >>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=3D line where we need it. H.248.= 20 uses "-" in the c=3D 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 tha= t the receiver sometimes shall care, and in other cases it doesn't need t= o 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:Christian.Groves@nteczone.com] >>Sent: 4. elokuuta 2006 4:28 >>To: CHATRAS Bruno RD-CORE-ISS >>Cc: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de; >>megaco@ietf.org; Campos, Simao >>Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value >>'-'in SDP"m=3D" line >> >>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 t= o 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:christer.holmberg@ericsson.com] >>>Envoy=E9 : mardi 25 juillet 2006 09:34 >>>=C0 : Christian Groves; Albrecht.Schwarz@alcatel.de Cc : CHATRAS Bru= no >>>RD-CORE-ISS; megaco@ietf.org; Campos, Simao Objet : Re: [Megaco] ETS= I >>>H.248 Ia Profile: issue with media value '-'in SDP"m=3D" 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=3D" line >>>Author: "Christian Groves" >>>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 ou= t 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) the= n "-" is never sent and this can be fixed in the Ia profile which introduced this problem. >>> >>>Regards, Christian >>> >>>Albrecht.Schwarz@alcatel.de wrote: >>> >>> >>> >>> >>> >>> >>> >>>>Hi, >>>> >>>>it's a syntax issue. An implementation following strictly ES 283 01= 8 >>>>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 ou= t >>>>explicitly the syntax extension. >>>> >>>>Thanks, >>>>regards, >>>> >>>>Albrecht >>>> >>>> >>>> >>>> >>>> >>>> "Christer Holmberg >>>> \(JO/LMF\)" To: "Kevin Boyle" , "CHATRAS Bruno RD-CORE-ISS" >>>> , Albrecht SCHWARZ/DE/ALCATEL@ALCATEL >>>> icsson.com> cc: megaco@ietf.org >>>> Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value '-'in SDP"m=3D"= 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:kboyle@nortel.com] >>>>Sent: 21. hein=E4kuuta 2006 17:23 >>>>To: Christer Holmberg (JO/LMF); CHATRAS Bruno RD-CORE-ISS; >>>>Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value= >>>>'-'in SDP"m=3D" 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 i= f >>>>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:christer.holmberg@ericsson.com] >>>>Sent: Friday, July 21, 2006 5:18 AM >>>>To: CHATRAS Bruno RD-CORE-ISS; Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value= >>>>'-'in SDP"m=3D" 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:bruno.chatras@orange-ft.com= ] >>>>Sent: 21. hein=E4kuuta 2006 10:26 >>>>To: Christer Holmberg (JO/LMF); Albrecht.Schwarz@alcatel.de >>>>Cc: megaco@ietf.org >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value= >>>>'-'in SDP"m=3D" 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 comman= d >>>>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:christer.holmberg@ericsson.com] >>>>Envoy=E9 : jeudi 20 juillet 2006 20:46 =C0 : Albrecht.Schwarz@alcat= el.de >>>>Cc : megaco@ietf.org Objet : RE: [Megaco] ETSI H.248 Ia Profile: >>>>issue with media value '-'in SDP"m=3D" 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 say= s >>>>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: Albrecht.Schwarz@alcatel.de >>>>[mailto:Albrecht.Schwarz@alcatel.de] >>>>Sent: 20. hein=E4kuuta 2006 12:00 >>>>To: Christer Holmberg (JO/LMF) >>>>Cc: megaco@ietf.org >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value= >>>>'-'in SDP "m=3D" 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 conside= r >>>>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" >>>>, "B Venkat S.R Swamy" >>>> >>>, "Christian Groves" >>>> >>>> icsson.com> cc: Albrecht >>>>SCHWARZ/DE/ALCATEL@ALCATEL, megaco@ietf.org >>>> Subject: RE: >>>>[Megaco] ETSI H.248 Ia Profile: issue with media value '-'inSDP"m=3D= " 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=3D line are >>>>defined as tokens. >>>> >>>>media =3D token >>>> ;typically "audio", "video", "text" or >>>> ;"application" >>>> >>>>fmt =3D token >>>> ;typically an RTP payload type for audio >>>> ;and video media >>>> >>>>token =3D 1*(token-char) >>>> >>>>token-char =3D %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-3= 9 / >>>>%x41-5A / %x5E-7E >>>> >>>>(The ascii code for "-" is %x2D) >>>> >>>> >>>>Regards, >>>> >>>>Christer >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Kevin Boyle [mailto:kboyle@nortel.com] >>>>Sent: 17. hein=E4kuuta 2006 19:58 >>>>To: B Venkat S.R Swamy; Christian Groves >>>>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; Christer Holmberg= >>>>(JO/LMF) >>>>Subject: RE: [Megaco] ETSI H.248 Ia Profile: issue with media value= >>>>'-'inSDP"m=3D" 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:b.swamy@flextronicssoftware.com] >>>>Sent: Monday, July 17, 2006 12:40 AM >>>>To: Christian Groves >>>>Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; >>>>christer.holmberg@ericsson.com >>>>Subject: Re: [Megaco] ETSI H.248 Ia Profile: issue with media value= '-' >>>>inSDP"m=3D" 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=3D" media space port ["/" integer] space proto 1*(space fmt) CRL= F >>>> >>>>media =3D 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 >>>> >>>> >>>> >>>> >>>> Christian Groves >>>> >>>> >>>> 07/17/2006 06:36 AM >>>> >>>> >>>> >>>>To >>>> >>>>Albrecht.Schwarz@alcatel.de >>>> >>>> >>>>cc >>>> >>>>B Venkat S.R Swamy/HSS@HSS, megaco@ietf.org, >>>>christer.holmberg@ericsson.com >>>> >>>> >>>>Subject >>>> >>>>Re: [Megaco] ETSI H.248 Ia Profile: issue with media value '-' inSDP"m=3D" >>>>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 >>>> >>>>Albrecht.Schwarz@alcatel.de wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Thanks for pointing to =A7 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 tha= t >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>it >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> is not necessary to specify the value of the parameter in the SD= P >>>>> 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" >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>SCHWARZ/DE/ALCATEL@ALCATEL >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> ftware.com> cc: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>megaco@ietf.org, christer.holmberg@ericsson.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Subject: Re: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>[Megaco] ETSI H.248 Ia Profile: issue with media value '-' in SDP"m=3D" >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> 14.07.2006 05:59 line >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Hi >>>>> >>>>>I support the option 2, and we should try to avoid any violation o= f >>>>>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 th= e >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>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)Albrecht.Schwarz@alcatel.de >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>christer.holmberg@ericsson.com, >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> taylor@nortel.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> (Embedded image moved to file: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> pic31609.gif) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>cc >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> (Embedded image moved to >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>file: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> pic17314.gif) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> megaco@ietf.org >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> (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=3D" 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 =3D *( media-field >>>>> >>>>> >>>>> information-field >>>>> >>>>> >>>>> *(connection-field) >>>>> >>>>> >>>>> bandwidth-fields >>>>> >>>>> >>>>> key-field >>>>> >>>>> >>>>> attribute-fields ) >>>>> >>>>> >>>>> media-field =3D "m=3D" media space port ["/" integer] >>>>> >>>>> >>>>> space proto 1*(space fmt) CRLF >>>>> >>>>> >>>>> media =3D 1*(alpha-numeric) >>>>> >>>>> >>>>> ;typically "audio", "video", "application" >>>>> >>>>> >>>>> ;or "data" >>>>> >>>>> >>>>>RFC 3108: >>>>> >>>>> = >>>>>media-descriptions =3D *(media-description) >>>>> >>>>> >>>>>media-description =3D media-field information-field >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>*(connection-field) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> bandwidth-fields key-field attribute-fields >>>>> >>>>> >>>>>media-field =3D 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 =3D "m=3D" media space vcId space transport-fmts E= OL >>>>> >>>>> >>>>> ; superset of RFC 2327 definition >>>>> >>>>> >>>>>media =3D "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 valu= e >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>must >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>always be | >>>>>| "v=3D" line | | equals= to >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>zero: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>| >>>>>| | | v=3D0 >>>>>| >>>>>|---------------------------+---------------------------+---------= - >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>>|---------------------------+---------------------------+- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>---------------| >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>| Connection | Mandatory | The network >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>type >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>must always| >>>>>| "c=3D" 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 b= e >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>used >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>for the media| >>>>>| "m=3D" line | |value. Other >>>>>values shall be | >>>>>| | |ignored, >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>unless >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>media | >>>>>| | |specific >>>>>information is | >>>>>| | |required.= >>>>>| >>>>>| | | >>>>>| >>>>>| | |The port value >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>may >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>be | >>>>>| | |underspecified >>>>>with CHOOSE | >>>>>| | |wildcard >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>("$"). >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>| >>>>>| | | >>>>>| >>>>>| | |"-" may b= e >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>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 >>>>>Megaco@ietf.org >>>>>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 >>>>>Megaco@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-------------------------------------------------------------------= - >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-------------------------------------------------------------------= - >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-------------------------------------------------------------------= - >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-------------------------------------------------------------------= - >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-------------------------------------------------------------------= - >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-------------------------------------------------------------------= - >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-------------------------------------------------------------------= - >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-------------------------------------------------------------------= - >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-------------------------------------------------------------------= - >>>>- >>>>- >>>>- >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>------------------------------------------------------------------= - >>>>>- >>>>>- >>>>>- >>>>>- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>_______________________________________________ >>>>>Megaco mailing list >>>>>Megaco@ietf.org >>>>>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 receive= d >>>>this message in error, please notify the originator immediately. >>>>If you are not the intended recipient, you are notified that you ar= e >>>>strictly prohibited from using, copying, altering, or disclosing th= e >>>>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 >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> >> >> >> >> >> >> >> > > > > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco = _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Aug 16 15:48:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDRMX-0003z1-9n; Wed, 16 Aug 2006 15:47:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDRMV-0003y5-LN for megaco@ietf.org; Wed, 16 Aug 2006 15:47:35 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17] helo=jaguar.hss.hns.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDRM0-0004Ce-E9 for megaco@ietf.org; Wed, 16 Aug 2006 15:47:06 -0400 Received: from jaguar.hss.hns.com (localhost [127.0.0.1]) by jaguar.hss.hns.com (8.13.6/8.12.10) with ESMTP id k7GJmN8J000474 for ; Thu, 17 Aug 2006 01:18:23 +0530 (IST) Received: from webmail.hss.hns.com (webmail.hss.hns.com [10.203.158.17]) by jaguar.hss.hns.com (8.13.6/8.13.6) with ESMTP id k7GJmIse000451; Thu, 17 Aug 2006 01:18:20 +0530 (IST) Received: from Dlfmail1.hss.hns.com ([10.203.142.23]) by webmail.hss.hns.com (Lotus Domino Release 6.5.2) with ESMTP id 2006081701164081-19728 ; Thu, 17 Aug 2006 01:16:40 +0530 Importance: Normal X-Priority: 3 (Normal) Subject: Re: RTP crosstalk; Re: [Megaco] Validating RTP stream From: Shobhit Bansal To: Albrecht.Schwarz@alcatel.de Date: Thu, 17 Aug 2006 01:14:23 +0530 Message-ID: X-MIMETrack: Serialize by Notes Server on Jhankar/HSS(Release 6.5|September 26, 2003) at 08/17/2006 01:14:23 AM, Serialize complete at 08/17/2006 01:14:23 AM, Itemize by Notes Server on Jhankar/HSS(Release 6.5|September 26, 2003) at 08/17/2006 01:14:23 AM, Serialize by Router on Dlfmail1/HSS(Release 6.5.2|June 01, 2004) at 08/17/2006 01:15:49 AM, Serialize complete at 08/17/2006 01:15:49 AM, Itemize by SMTP Server on WebMail/HSS(Release 6.5.2|June 01, 2004) at 08/17/2006 01:16:40 AM, Serialize by Router on WebMail/HSS(Release 6.5.2|June 01, 2004) at 08/17/2006 01:16:49 AM, Serialize complete at 08/17/2006 01:16:49 AM MIME-Version: 1.0 X-Spam-Score: 2.6 (++) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1869820848==" Errors-To: megaco-bounces@ietf.org --===============1869820848== Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 =

Hi Albrecht,
 
There are three causes mentioned in the docu= ment H.248.RTPcrosstalk
The first two talk about avoiding any RTP termination to go in a hang= ing state so that they don't keep on generating the RTP when they shou= ld not be.
The thi= rd one actually talks about a solution as to how a termination can del= ay a situation of receiving two media streams. A waiting period c= an avoid situations where signal (megaco) processing is dela= yed but not those situations where a RTP termination is= malfunctioning.
 
In my opinion t= here should be some way at the receiving side to validate or filter th= e media stream it is receiving like exchanging the ssrc value which will be= part of the RTP stream.
 
Thanks = and regards
Shobhit Bansal
= Technical Leader
Flextronics Software Systems
<= DIV align=3Dleft> -----Albrecht.Schwarz@al= catel.de wrote: -----

To: B Venkat S.R Swamy/HSS@HSS
From: Albrecht.Schwarz@a= lcatel.de
Date: 08/16/2006 07:12AM
cc: megaco@ietf.org
Subject:= Re: RTP crosstalk; Re: [Megaco] Validating RTP stream

In my opinion:

a) provisioning =3D> Not possible. =

b) implicit "signalling" by 'symmetry assumptions' =3D> possible=
  [Note: this is then an underlying operations requirement for al= l RTP
equipment in such a RTP domain.]

c) explicit signalling, = e.g. via gm package (gm properties saf, sam, spf,
spr) =3D> possible=
  [Note: implies of course that the MGC has access on such inform= ation,
from call/session control signalling; or from a database in case= of "static
configurations"]

- Albrecht

PS
Venkat: = if you've still concerns/question, then I would appreciate
contribution= s against Draft ITU-T H.Sup.RTPXtalk.




    &nb= sp;                     &= nbsp;                    =                     &nbs= p;                     &n= bsp;                     =                      = ;    
               =      "B Venkat S.R Swamy"          = ;                     &nb= sp;                     &= nbsp;                    =                     &nbs= p;
                   = ;                  =      ftware.com>           &nbs= p;        cc:      megaco@ietf.org  = ;                     &nb= sp;                     &= nbsp;                
  &n= bsp;                     =                      = ;       Subject: Re: RTP crosstalk; Re: [Megaco] Validating = RTP stream                   &= nbsp;    
              &n= bsp;      16.08.2006 10:25          = ;                     &nb= sp;                     &= nbsp;                    =                     &nbs= p;    
               = ;                     &nb= sp;                     &= nbsp;                    =                     &nbs= p;                     &n= bsp;              




H= i

Regarding "Source address/port filtering", how does Session contr= oller know
the RTP
source address/port to be used for filtering, si= nce Remote Descriptor only
specifies what port remote is listening. Is it a provisioning data or there is some other signalling mechansim.

regards
B Venkat S.R Swamy
Senior Technical Leader
Fle= xtronics Software Systems
Phone: +91-124- 4176213
Fax: +91-124-4300= 247
web: www.flextronicssoftware.com
(Embedded image moved to file:= pic09542.gif)Albrecht.Schwarz@alcatel.de

      &nbs= p;                     &n= bsp;                     =                      = ;  
                 =       Albrecht.S             =                      = ;      
             =           chwarz@alc         =                      = ;          
         =               atel.de     &nb= sp;                     &= nbsp;              
    &n= bsp;                     =          (Embedded image moved to file:   &nb= sp;    
              &nbs= p;                    pic= 26157.gif)                   &= nbsp;      
            &n= bsp;           08/16/2006       &nb= sp;                     &= nbsp;       To
           =             01:13 PM       &n= bsp;      (Embedded image moved to    
  =                      = ;                     &nb= sp; file: pic18290.gif)        
     = ;                     &nb= sp;                   Shobhit = Bansal/HSS@HSS      
          =                      = ;    (Embedded image moved to file:         <= BR>                    &n= bsp;              pic02576.gif)   &= nbsp;                    =  
                  =                      = ;                     &nb= sp;          cc
        &n= bsp;                     =                 (Embedded image mov= ed to    
              &n= bsp;                     =           file: pic14905.gif)      =  
                  =                      = ;       megaco@ietf.org           &= nbsp;
                  &n= bsp;                (Embedded image= moved to file:        
       =                     &nbs= p;      pic04288.gif)           &nb= sp;              
    &nbs= p;                     &n= bsp;                     =                   Subject
=                      = ;                     &nb= sp;   (Embedded image moved to    
      =                      = ;                   file: pic2= 4019.gif)        
         = ;                     &nb= sp;               RTP crosstalk; Re: [Me= gaco]
                  &n= bsp;                     =       Validating RTP stream      
  =                      = ;                     &nb= sp;                     &= nbsp;      
            &n= bsp;                     =                      = ;                  
 =                     &nbs= p;            (Embedded image moved to file: =        
            &= nbsp;                    =  pic03378.gif)                = ;          
         =                     &nbs= p;           (Embedded image moved to file:  =
                    =                      = ; pic11584.gif)                 &nb= sp;
                  &nbs= p;                     &n= bsp;                     =            
        &= nbsp;                    =                     &nbs= p;                     &n= bsp;




Shobhit:

>1:
Depends on symmetrical= or asymmetrical RTP/IP.
You cannot per se suppose symmetry.

&g= t;2:
via "source address/port filtering"

See e.g.
  &n= bsp; Draft H.248 Series Supp. X RTPXtalk (H.248.43 (ex. H.248.RTPXtalk))     Guidelines for Resource Management of Resources for H.248 R= TP
    Terminations

    Note: this Suppleme= nt is particularly discussing "... malfunctioning
    and kee= ps on generating RTP stream ...", called "RTP crosstalk".

  &n= bsp; ETSI H.248 gm package in ETSI TS 102 333
    Work item o= n Draft H.248.gmgc

- Albrecht




    &nb= sp;               Shobhit Bansal
                    megaco@ietf.org

  &nbs= p;                 ftware.com> &= nbsp;                    =     cc:

             =                     &nbs= p;                     &n= bsp; Subject:
[Megaco] Validating RTP stream

    &nbs= p;               16.08.2006 01:27





Hi all,

I have some basic questions regarding= the media streams.

Lets say we have an ephemeral termination with = valid local descriptor (ip
addr 192.168.1.100, port 5004) and remote de= scriptor (ip addr 10.10.4.5,
port 6010).

1> I understand tha= t remote descriptor means that the RTP going out will
have the destinat= ion ip address as 10.10.4.5 and port 6010 but can we
assume that the RT= P stream that will be coming from the other end with have
the source ip= as 10.10.4.5 and port 6010 ?

2> If not, is there a parameter by= which we can confirm that the RTP stream
is valid or not. Consider a s= cenario where a termination is malfunctioning
and keeps on generating R= TP stream towards this ephemeral. How can we
reject this RTP stream ? <= BR>
Thanks and regards
Shobhit Bansal
Technical Leader
Flext= ronics Software Systems

*****FSS-Unclassified *****" DISCLAIMER: Th= is message is proprietary to
Flextronics Software Systems Limited (FSS)= and is intended solely for the
use of the individual to whom it is add= ressed. It may contain privileged or
confidential information and shoul= d not be circulated or used for any
purpose other than for what it is i= ntended. 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 responsibi= lity for loss or damage arising from the use of
the information transmi= tted by this email including damage from virus."
=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Megaco mailing list
M= egaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

=



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/megaco



*********************** FSS-= Restricted ***********************
"DISCLAIMER: This message is proprie= tary to Flextronics Software
Systems Limited (FSS) and is intended sole= ly for the use of the
individual to whom it is addressed. It may contai= n privileged or
confidential information and should not be circulated o= r used for
any purpose other than for what it is intended. If you have = received
this message in error, please notify the originator immediatel= y.
If you are not the intended recipient, you are notified that you are=
strictly prohibited from using, copying, altering, or disclosing
t= he contents of this message. FSS accepts no responsibility for
loss or = damage arising from the use of the information transmitted
by this emai= l including damage from virus."
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F
Megaco mailing list
Megaco@ietf.org h= ttps://www1.ietf.org/mailman/listinfo/megaco


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/megaco


*****= FSS-Unclassified ***** " DISCLAIMER: This message is proprietary to Flextronics Softwar= e Systems Limited (FSS) and is intended solely for the use of the individua= l to whom it is addressed. It may contain privileged or confidential infor= mation 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&#= 44; you are notified that you are strictly prohibited from using, copyi= ng, altering, or disclosing the contents of this message. FSS accep= ts no responsibility for loss or damage arising from the use of the informa= tion transmitted by this email including damage from virus."= --===============1869820848== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1869820848==-- From megaco-bounces@ietf.org Wed Aug 16 16:05:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDRdz-0006br-6N; Wed, 16 Aug 2006 16:05:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDRdx-0006aO-1y for megaco@ietf.org; Wed, 16 Aug 2006 16:05:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDRdw-00069O-VM for megaco@ietf.org; Wed, 16 Aug 2006 16:05:37 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDRd1-0003st-MY for megaco@ietf.org; Wed, 16 Aug 2006 16:04:44 -0400 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7GK4V022355 for ; Wed, 16 Aug 2006 16:04:31 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: RTP crosstalk; Re: [Megaco] Validating RTP stream Date: Wed, 16 Aug 2006 16:03:58 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A118D3F@zrtphxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RTP crosstalk; Re: [Megaco] Validating RTP stream Thread-Index: AcbBbZED9r1X0I7/TJG/YjgcDCjAjgAARLvQ From: "Kevin Boyle" To: "Shobhit Bansal" , X-Spam-Score: -2.6 (--) X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org It seems to me that this is an SDP problem, not an H.248 problem. Remember that H.248 operates between the MGC and the MG. The problem you describe is a potential interworking problem between two end MGs. H.248 is not directly involved here. How is this potential issue solved by other SDP-dependent protocols? Keep in mind that we CANNOT force symmetry here, as there are many reasons why asymmetrical RTP streams could occur -- including having a firewall in the middle or some other middlebox regulating traffic. Kevin ________________________________ From: Shobhit Bansal [mailto:shobhit.bansal@flextronicssoftware.com] Sent: Wednesday, August 16, 2006 3:44 PM To: Albrecht.Schwarz@alcatel.de Cc: megaco@ietf.org Subject: Re: RTP crosstalk; Re: [Megaco] Validating RTP stream Hi Albrecht, There are three causes mentioned in the document H.248.RTPcrosstalk The first two talk about avoiding any RTP termination to go in a hanging state so that they don't keep on generating the RTP when they should not be. The third one actually talks about a solution as to how a termination can delay a situation of receiving two media streams. A waiting period can avoid situations where signal (megaco) processing is delayed but not those situations where a RTP termination is malfunctioning. In my opinion there should be some way at the receiving side to validate or filter the media stream it is receiving like exchanging the ssrc value which will be part of the RTP stream. Thanks and regards Shobhit Bansal Technical Leader Flextronics Software Systems -----Albrecht.Schwarz@alcatel.de wrote: ----- To: B Venkat S.R Swamy/HSS@HSS From: Albrecht.Schwarz@alcatel.de Date: 08/16/2006 07:12AM cc: megaco@ietf.org Subject: Re: RTP crosstalk; Re: [Megaco] Validating RTP stream In my opinion: a) provisioning => Not possible. b) implicit "signalling" by 'symmetry assumptions' => possible [Note: this is then an underlying operations requirement for all RTP equipment in such a RTP domain.] c) explicit signalling, e.g. via gm package (gm properties saf, sam, spf, spr) => possible [Note: implies of course that the MGC has access on such information, from call/session control signalling; or from a database in case of "static configurations"] - Albrecht PS Venkat: if you've still concerns/question, then I would appreciate contributions against Draft ITU-T H.Sup.RTPXtalk. "B Venkat S.R Swamy" ftware.com> cc: megaco@ietf.org Subject: Re: RTP crosstalk; Re: [Megaco] Validating RTP stream 16.08.2006 10:25 Hi Regarding "Source address/port filtering", how does Session controller know the RTP source address/port to be used for filtering, since Remote Descriptor only specifies what port remote is listening. Is it a provisioning data or there is some other signalling mechansim. 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: pic09542.gif)Albrecht.Schwarz@alcatel.de Albrecht.S chwarz@alc atel.de (Embedded image moved to file: pic26157.gif) 08/16/2006 To 01:13 PM (Embedded image moved to file: pic18290.gif) Shobhit Bansal/HSS@HSS (Embedded image moved to file: pic02576.gif) cc (Embedded image moved to file: pic14905.gif) megaco@ietf.org (Embedded image moved to file: pic04288.gif) Subject (Embedded image moved to file: pic24019.gif) RTP crosstalk; Re: [Megaco] Validating RTP stream (Embedded image moved to file: pic03378.gif) (Embedded image moved to file: pic11584.gif) Shobhit: >1: Depends on symmetrical or asymmetrical RTP/IP. You cannot per se suppose symmetry. >2: via "source address/port filtering" See e.g. Draft H.248 Series Supp. X RTPXtalk (H.248.43 (ex. H.248.RTPXtalk)) Guidelines for Resource Management of Resources for H.248 RTP Terminations Note: this Supplement is particularly discussing "... malfunctioning and keeps on generating RTP stream ...", called "RTP crosstalk". ETSI H.248 gm package in ETSI TS 102 333 Work item on Draft H.248.gmgc - Albrecht Shobhit Bansal megaco@ietf.org ftware.com> cc: Subject: [Megaco] Validating RTP stream 16.08.2006 01:27 Hi all, I have some basic questions regarding the media streams. Lets say we have an ephemeral termination with valid local descriptor (ip addr 192.168.1.100, port 5004) and remote descriptor (ip addr 10.10.4.5, port 6010). 1> I understand that remote descriptor means that the RTP going out will have the destination ip address as 10.10.4.5 and port 6010 but can we assume that the RTP stream that will be coming from the other end with have the source ip as 10.10.4.5 and port 6010 ? 2> If not, is there a parameter by which we can confirm that the RTP stream is valid or not. Consider a scenario where a termination is malfunctioning and keeps on generating RTP stream towards this ephemeral. How can we reject this RTP stream ? Thanks and regards Shobhit Bansal Technical Leader Flextronics Software Systems *****FSS-Unclassified *****" 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 Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org 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 Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco *****FSS-Unclassified ***** " 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 Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Aug 17 07:52:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDgPf-0007II-2L; Thu, 17 Aug 2006 07:51:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDgPe-0007ID-9d for megaco@ietf.org; Thu, 17 Aug 2006 07:51:50 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDgPb-0001jd-P5 for megaco@ietf.org; Thu, 17 Aug 2006 07:51:50 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.11.20060308/8.12.11/ICT TSC MAIL 2005) with ESMTP id k7HBpL88024714; Thu, 17 Aug 2006 13:51:21 +0200 In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA4097BC1CC@zrtphxm2.corp.nortel.com> Subject: RE: [Megaco] ASN-ABNF differences in H.248.1 V3 To: "B Venkat S.R Swamy" , "; \"Kevin Boyle\"" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Albrecht.Schwarz@alcatel.de Date: Thu, 17 Aug 2006 13:51:20 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/17/2006 13:51:21 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 0.2 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: megaco ietf , Christian Groves X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Venkat, you made a good analysis and cross-check. I would appreciate if we could safe your work. I'm inline with comments from Kevin and Christian, ie. I do agree that your summary requires a slight revision in order to get acceptable change proposal inputs for IMG, and for V4 living list ("what part of your proposal do you believe can go into an IG and what needs to wait until H.248.1v4?"). Could you provide such a revision for our upcoming WP2/16 meeting? Thanks, Albrecht "Kevin Boyle" , "B Venkat S.R Swamy" om> cc: megaco ietf 17.07.2006 18:54 Subject: RE: [Megaco] ASN-ABNF differences in H.248.1 V3 One clarification: We can alter the syntax in the IG, but only if it is a problem with the syntax that is a severe defect. Syntax loops, missing required symbols or different elements both defined as the same symbol are good examples of issues we can fix in the IG. Mismatches between the ABNF and the ASN.1, inconvenient expression or items "left out" are not issues that we can syntactically correct in the IG. Kevin -----Original Message----- From: Christian Groves [mailto:Christian.Groves@nteczone.com] Sent: Sunday, July 16, 2006 10:27 PM To: B Venkat S.R Swamy Cc: megaco ietf Subject: Re: [Megaco] ASN-ABNF differences in H.248.1 V3 Hello, I agree that we should have consistency between the ASN.1 and ABNF versions of H.248 many of the proposed changes go further than what we can do in an implementor's guide. In an implementor's guide we can offer clarifications of behaviour but cannot change syntax. A version update of the protocol is needed to do this. Even when a new version is produced it has to be done in a backwards compatible manner. So for instance: we can't remove the OPTIONALity of a parameter in the syntax, but we can say that from version X on this parameter is mandatory. I believe the vice versa is true also, we can't make a mandatory parameter suddenly be OPTIONAL in the ASN.1 (although i'd be very happy for a ASN.1 expert to correct me on this). In q.3/16 we do have a "living list" of items which we are collecting for inclusion into H.248.1v4 when we decide to start working on it. So my question is given the above explanation, what part of your proposal do you believe can go into an IG and what needs to wait until H.248.1v4? Regards, Christian B Venkat S.R Swamy wrote: > Hi > > Please find attached word document capturing the differences of ASN > and ABNF constructs in H.2481. V3(Sep 2005). The differences are > mostly in the Individual AuditItems grammar. The aim of the document > is to achieve the consistency in the grammar for both ASN and ABNF. > > Would request you all to comment on the differences, so that the > necessary correction can be taken in V3 IG by authors. > > > /(See attached file: H248.1_v3_ASN_TEXT_differences.doc)/ > > regards > B Venkat S.R Swamy > Senior Technical Leader > Flextronics Software Systems > Phone: +91-124- 4176213 > Fax: +91-124-4300247 > web: www.flextronicssoftware.com > > *********************** 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 >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Sun Aug 20 21:51:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEywL-0006J4-Pg; Sun, 20 Aug 2006 21:50:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEywJ-0006Iz-Tf for megaco@ietf.org; Sun, 20 Aug 2006 21:50:55 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEywE-0005zK-Vk for megaco@ietf.org; Sun, 20 Aug 2006 21:50:55 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4B007ZDS8JLA@szxga03-in.huawei.com> for megaco@ietf.org; Mon, 21 Aug 2006 10:00:19 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4B00GRRS8IX1@szxga03-in.huawei.com> for megaco@ietf.org; Mon, 21 Aug 2006 10:00:19 +0800 (CST) Received: from z26452a ([10.70.145.98]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4B00H79RXHE0@szxml03-in.huawei.com> for megaco@ietf.org; Mon, 21 Aug 2006 09:53:44 +0800 (CST) Date: Mon, 21 Aug 2006 09:49:50 +0800 From: Tony Zhang To: megaco@ietf.org Message-id: <004801c6c4c4$16dc0570$6291460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcbCoDkZ3Q9M2eVhRqeAK0nhp4eeqQCI7D5w X-Spam-Score: 1.3 (+) X-Scan-Signature: 6ec0f3d4960e6167ab597cf7076be2db Subject: [Megaco] H248 V3 question X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1559089390==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1559089390== Content-type: multipart/alternative; boundary="Boundary_(ID_HAXDvk0sXSUT5lslnxKTtw)" This is a multi-part message in MIME format. --Boundary_(ID_HAXDvk0sXSUT5lslnxKTtw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable first choice(red word is the path)=EF=BC=9A contextAudit =3D ContextAuditToken LBRKT (contextAuditProperties=20 *(COMMA contextAuditProperties)) / indAudcontextAttrDescriptor RBRKT =20 ; at-most-once except contextAuditSelector contextAuditProperties =3D (TopologyToken / EmergencyToken / PriorityToken /IEPSToken/ pkgdName / contextAuditSelector) ; at-most-once contextAuditSelector =3D priority / emergencyValue / iepsValue /=20 contextAttrDescriptor / = auditSelectLogic =20 contextAttrDescriptor =3D ContextAttrToken LBRKT (contextIdList / propertyParm *(COMMA propertyParm)) = RBRKT =20 propertyParm =3D pkgdName parmValue =20 second choice=EF=BC=9A contextAudit =3D ContextAuditToken LBRKT (contextAuditProperties = *(COMMA contextAuditProperties)) / indAudcontextAttrDescriptor RBRKT =20 indAudcontextAttrDescriptor =3D ContextAttrToken LBRKT = contextAuditProperties *(COMMA contextAuditProperties) RBRKT =20 =20 question: if appear ContextAttrToken after 'ContextAuditToken { ',we can = not differentiate between indAudcontextAttrDescriptor and = contextAuditProperties. =20 --Boundary_(ID_HAXDvk0sXSUT5lslnxKTtw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

firs= t choice(red word is the path)=EF=BC= =9A

con= textAudit        =3D ContextAuditToken LBRKT (conte= xtAuditProperties

 = ;            =              *(COMMA contextAuditProperties)) = /

&nb= sp;           &nbs= p;            = ;   indAudcontextAttrDescriptor     = RBRKT

 

; = at-most-once except contextAuditSelector

con= textAuditProperties     =3D (TopologyToken / EmergencyToken /

&nb= sp;           &nbs= p;            = ;         PriorityToken /IEPSToken/ pkgdName /

&nb= sp;           &nbs= p;            = ;         contextAuditSelector)

; = at-most-once

con= textAuditSelector        =3D priority / emergencyValue / = iepsValue /

&nb= sp;           &nbs= p;            = ;         contextAttrDescriptor / = auditSelectLogic

 

con= textAttrDescriptor      =3D Conte= xtAttrToken LBRKT (contextIdList = /

&nb= sp;           &nbs= p;            = ;         propertyParm *(COMMA propertyParm)) RBRKT

 

pro= pertyParm         =3D pkgdN= ame parmValue

 

seco= nd choice=EF=BC=9A

con= textAudit         =3D ContextAuditToken LBRKT (contextAuditProperties =

&nb= sp;           &nbs= p;            = ; *(COMMA contextAuditProperties)) /

&nb= sp;           &nbs= p;            = ;   indAudcontextAttrDescrip= tor     RBR= KT

 

ind= AudcontextAttrDescriptor

&nb= sp;           &nbs= p;            = ;  =3D Conte= xtAttrToken LBRKT = contextAuditProperties

&nb= sp;           &nbs= p;            = ;         *(COMMA contextAuditProperties) RBRKT

 

 

que= stion:

&nb= sp;      if appear Conte= xtAttrToken after 'ContextAuditToken { ',we can not = differentiate between indAudcontextAttrDescriptor and contextAuditProperties.

 

--Boundary_(ID_HAXDvk0sXSUT5lslnxKTtw)-- --===============1559089390== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1559089390==-- From megaco-bounces@ietf.org Sun Aug 20 22:07:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEzCo-0003hL-Ed; Sun, 20 Aug 2006 22:07:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEzCm-0003fF-Tx for megaco@ietf.org; Sun, 20 Aug 2006 22:07:56 -0400 Received: from quantum.websiteactive.com ([70.86.207.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEzCi-0008SR-MT for megaco@ietf.org; Sun, 20 Aug 2006 22:07:56 -0400 Received: from cpe-61-9-144-63.vic.bigpond.net.au ([61.9.144.63]:10390 helo=[127.0.0.1]) by quantum.websiteactive.com with esmtpa (Exim 4.52) id 1GEzCh-0004Lz-VD for megaco@ietf.org; Mon, 21 Aug 2006 12:07:52 +1000 Message-ID: <44E91571.4070704@nteczone.com> Date: Mon, 21 Aug 2006 12:07:45 +1000 From: Christian Groves User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco ietf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - quantum.websiteactive.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Megaco] Q.3/16 Meeting X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hello all, FYI. H.248 related contributions to the upcoming Q.3/16 meeting in Ottawa can be found at: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0608_Ott/0608_Ott.html A number of the contributions pick up from discussion from the list. e.g. AVD-2908. Regards, Christian _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Aug 21 00:43:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF1cT-00026G-Ss; Mon, 21 Aug 2006 00:42:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF1cS-00026B-Fk for megaco@ietf.org; Mon, 21 Aug 2006 00:42:36 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF1cS-0002Ny-DB for megaco@ietf.org; Mon, 21 Aug 2006 00:42:36 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17] helo=jaguar.hss.hns.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GF1cN-0003mu-4f for megaco@ietf.org; Mon, 21 Aug 2006 00:42:35 -0400 Received: from jaguar.hss.hns.com (localhost [127.0.0.1]) by jaguar.hss.hns.com (8.13.6/8.12.10) with ESMTP id k7L4i3j0001249 for ; Mon, 21 Aug 2006 10:14:03 +0530 (IST) Received: from webmail.hss.hns.com (webmail.hss.hns.com [10.203.158.17]) by jaguar.hss.hns.com (8.13.6/8.13.6) with ESMTP id k7L4hwYn001210; Mon, 21 Aug 2006 10:14:00 +0530 (IST) Received: from Dlfmail1.hss.hns.com ([10.203.142.23]) by webmail.hss.hns.com (Lotus Domino Release 6.5.2) with ESMTP id 2006082110121988-28718 ; Mon, 21 Aug 2006 10:12:19 +0530 In-Reply-To: <004801c6c4c4$16dc0570$6291460a@china.huawei.com> Subject: Re: [Megaco] H248 V3 question To: Tony Zhang X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: "B Venkat S.R Swamy" Date: Mon, 21 Aug 2006 10:15:09 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on Dlfmail1/HSS(Release 6.5.2|June 01, 2004) at 08/21/2006 10:11:25 AM, Itemize by SMTP Server on WebMail/HSS(Release 6.5.2|June 01, 2004) at 08/21/2006 10:12:19 AM, Serialize by Router on WebMail/HSS(Release 6.5.2|June 01, 2004) at 08/21/2006 10:12:28 AM, Serialize complete at 08/21/2006 10:12:28 AM Content-type: text/plain; charset=ISO-2022-JP X-Spam-Score: -2.3 (--) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hi Yes you are right, the ContextAudit constructs are quite confusing and we have initiated a similiar thread earlier also. "[Megaco] V3 related clarifications required", Sudhanshu Garg, 5th June 2006 "[Megaco] Individual context audit", Sudhanshu Garg, 7th July 2006 Also there is a difference in the ASN and ABNF constructs for the ContextAudit grammar. On this we have floated one document on V3 ASN-ABNF grammar differences in mailing list "[Megaco] ASN-ABNF differences in H.248.1 V3" dated 10th July. Therefore it is important that the grammar be simplified and remove any redundant constructs and tokens so that it can be used effectively. regards B Venkat S.R Swamy Senior Technical Leader Flextronics Software Systems Phone: +91-124- 4176213 Fax: +91-124-4300247 web: www.flextronicssoftware.com Tony Zhang To megaco@ietf.org 08/21/2006 07:19 cc AM Subject [Megaco] H248 V3 question first choice(red word is the path)$B!'(B contextAudit = ContextAuditToken LBRKT (contextAuditProperties *(COMMA contextAuditProperties)) / indAudcontextAttrDescriptor RBRKT ; at-most-once except contextAuditSelector contextAuditProperties = (TopologyToken / EmergencyToken / PriorityToken /IEPSToken/ pkgdName / contextAuditSelector) ; at-most-once contextAuditSelector = priority / emergencyValue / iepsValue / contextAttrDescriptor / auditSelectLogic contextAttrDescriptor = ContextAttrToken LBRKT (contextIdList / propertyParm *(COMMA propertyParm)) RBRKT propertyParm = pkgdName parmValue second choice$B!'(B contextAudit = ContextAuditToken LBRKT (contextAuditProperties *(COMMA contextAuditProperties)) / indAudcontextAttrDescriptor RBRKT indAudcontextAttrDescriptor = ContextAttrToken LBRKT contextAuditProperties *(COMMA contextAuditProperties) RBRKT question: if appear ContextAttrToken after 'ContextAuditToken { ',we can not differentiate between indAudcontextAttrDescriptor and contextAuditProperties. _______________________________________________ Megaco mailing list Megaco@ietf.org 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 Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Aug 21 13:42:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFDmd-0007I6-S5; Mon, 21 Aug 2006 13:41:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDzix-0001p8-Lg for megaco@ietf.org; Fri, 18 Aug 2006 04:29:03 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDzit-0002Bj-CM for megaco@ietf.org; Fri, 18 Aug 2006 04:29:03 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4600K91R0EAA@szxga02-in.huawei.com> for megaco@ietf.org; Fri, 18 Aug 2006 16:45:50 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J46001N5R0C3P@szxga02-in.huawei.com> for megaco@ietf.org; Fri, 18 Aug 2006 16:45:50 +0800 (CST) Received: from z26452a ([10.70.145.98]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J46004Y5QQVM1@szxml04-in.huawei.com> for megaco@ietf.org; Fri, 18 Aug 2006 16:40:10 +0800 (CST) Date: Fri, 18 Aug 2006 16:28:03 +0800 From: Tony Zhang To: megaco@ietf.org Message-id: <000c01c6c2a0$39499f80$6291460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcbCoDkZ3Q9M2eVhRqeAK0nhp4eeqQ== X-Spam-Score: 1.3 (+) X-Scan-Signature: 66f400f61005d4d0a97f265bc4a7a9ca X-Mailman-Approved-At: Mon, 21 Aug 2006 13:41:54 -0400 Subject: [Megaco] H248 V3 question X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1525246987==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1525246987== Content-type: multipart/alternative; boundary="Boundary_(ID_ovXoYe/olwiMHFTxEQMw8A)" This is a multi-part message in MIME format. --Boundary_(ID_ovXoYe/olwiMHFTxEQMw8A) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable =20 first choice(red word is the path)=EF=BC=9A contextAudit =3D ContextAuditToken LBRKT (contextAuditProperties=20 *(COMMA contextAuditProperties)) / indAudcontextAttrDescriptor RBRKT =20 ; at-most-once except contextAuditSelector contextAuditProperties =3D (TopologyToken / EmergencyToken / PriorityToken /IEPSToken/ pkgdName / contextAuditSelector) ; at-most-once contextAuditSelector =3D priority / emergencyValue / iepsValue /=20 contextAttrDescriptor / = auditSelectLogic =20 contextAttrDescriptor =3D ContextAttrToken LBRKT (contextIdList / propertyParm *(COMMA propertyParm)) = RBRKT =20 propertyParm =3D pkgdName parmValue =20 second choice=EF=BC=9A contextAudit =3D ContextAuditToken LBRKT (contextAuditProperties = *(COMMA contextAuditProperties)) / indAudcontextAttrDescriptor RBRKT =20 indAudcontextAttrDescriptor =3D ContextAttrToken LBRKT = contextAuditProperties *(COMMA contextAuditProperties) RBRKT =20 question: if appear ContextAttrToken after 'ContextAuditToken { ',we can = not differentiate between indAudcontextAttrDescriptor and = contextAuditProperties. =20 =20 regards =20 Tony.Zhang.Tao@hotmail.com =20 --Boundary_(ID_ovXoYe/olwiMHFTxEQMw8A) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

 

first choice(red word is the path)=EF=BC=9A

contextAudit=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D = ContextAuditToken LBRKT (contextAuditPropertie= s

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 *(COMMA contextAuditProperties)) = /

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 indAudcontextAttrDescriptor =C2=A0=C2=A0=C2=A0 = RBRKT

 

; at-most-once except = contextAuditSelector

contextAuditProperties=C2=A0=C2=A0=C2=A0=C2=A0 =3D (TopologyToken = / EmergencyToken /

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PriorityToken = /IEPSToken/ pkgdName /

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = contextAuditSelector)

; at-most-once

contextAuditSelector =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D = priority / emergencyValue / iepsValue /

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = contextAttrDescriptor / = auditSelectLogic

 

contextAttrDescriptor=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D = ContextAttrToken LBRKT (contextIdList = /

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = propertyParm *(COMMA propertyParm)) = RBRKT

 

propertyParm=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D = pkgdName parmValue

 

second choice=EF=BC=9A

contextAudit=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D = ContextAuditToken LBRKT (contextAuditProperties =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 *(COMMA contextAuditProperties)) /

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 indAudcontextAttrDescriptor =C2=A0=C2=A0=C2=A0 RBRKT

 

indAudcontextAttrDescriptor

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 =3D ContextAttrToken LBRKT = contextAuditProperties

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *(COMMA = contextAuditProperties) RBRKT

 

question:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if appear ContextAttrToken after 'ContextAuditToken { ',we can not differentiate between = indAudcontextAttrDesc= riptor and = contextAuditProperties.

 

 

regards<= /span>

 =

Tony.Zhang.Tao@hotmail.com

 

--Boundary_(ID_ovXoYe/olwiMHFTxEQMw8A)-- --===============1525246987== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1525246987==-- From megaco-bounces@ietf.org Tue Aug 22 23:38:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFjYy-00073c-E3; Tue, 22 Aug 2006 23:37:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFjYx-00073X-7L for megaco@ietf.org; Tue, 22 Aug 2006 23:37:55 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFjYr-0007KG-5B for megaco@ietf.org; Tue, 22 Aug 2006 23:37:55 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4F005HYMGAOO@szxga03-in.huawei.com> for megaco@ietf.org; Wed, 23 Aug 2006 11:45:47 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4F002VHMG8JD@szxga03-in.huawei.com> for megaco@ietf.org; Wed, 23 Aug 2006 11:45:46 +0800 (CST) Received: from z26452a ([10.70.145.98]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4F0036IMJ111@szxml04-in.huawei.com> for megaco@ietf.org; Wed, 23 Aug 2006 11:47:28 +0800 (CST) Date: Wed, 23 Aug 2006 11:35:15 +0800 From: Tony Zhang To: megaco@ietf.org Message-id: <000601c6c665$2610a760$6291460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcbGZSXoBHMzWzuUQrSVQhcjVX709A== X-Spam-Score: 0.2 (/) X-Scan-Signature: 5e838aaa8742d88b45f835f097988b1d Subject: [Megaco] Another question about H248V3 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1869711909==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1869711909== Content-type: multipart/alternative; boundary="Boundary_(ID_rIJ+vLg43yC3vi+M+4CghA)" This is a multi-part message in MIME format. --Boundary_(ID_rIJ+vLg43yC3vi+M+4CghA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Hi: I have some question to ask: transactionReply = ReplyToken EQUAL TransactionID [SLASH segmentNumber [SLASH SegmentationCompleteToken]] LBRKT [ImmAckRequiredToken COMMA] (errorDescriptor / actionReplyList) RBRKT actionReplyList = actionReply *(COMMA actionReply) actionReply = CtxToken EQUAL ContextID [LBRKT (errorDescriptor / commandReply /(commandReply COMMA errorDescriptor)) RBRKT] commandReply = ((contextProperties [COMMA commandReplyList]) / commandReplyList) commandReplyList = commandReplys *(COMMA commandReplys) commandReplys = (serviceChangeReply / auditReply / ammsReply / notifyReply) contextProperties = contextProperty *(COMMA contextProperty) question: If (contextProperties [COMMA commandReplyList]) appear in commandReply,how to deal with this circs when segment? Is there has particular rules to segment? regards Tony.Zhang.Tao@hotmail.com --Boundary_(ID_rIJ+vLg43yC3vi+M+4CghA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi:

I have some question to ask:

 

transactionReply=C2=A0=C2=A0=C2=A0=C2=A0 =3D ReplyToken EQUAL = TransactionID [SLASH segmentNumber

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [SLASH = SegmentationCompleteToken]] LBRKT

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = [ImmAckRequiredToken COMMA]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (errorDescriptor = / actionReplyList) RBRKT

 

actionReplyList=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D actionReply = *(COMMA actionReply)

 

actionReply =3D CtxToken EQUAL ContextID [LBRKT (errorDescriptor = /

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 commandReply = /(commandReply COMMA

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 errorDescriptor)) = RBRKT]

 

commandReply=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D = ((contextProperties [COMMA commandReplyList]) = /

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = commandReplyList)

 

commandReplyList=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =3D commandReplys *(COMMA = commandReplys)

 

commandReplys=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D = (serviceChangeReply / auditReply / ammsReply = /

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = notifyReply)

 

contextProperties=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =3D contextProperty *(COMMA = contextProperty)

 

question:

If (contextProperties [COMMA commandReplyList]) appear in commandReply,how to deal with this circs when = segment?

 

Is there has particular rules to = segment?

 

regards<= /span>

 =

Tony.Zhang.Tao@hotmail.com

 

--Boundary_(ID_rIJ+vLg43yC3vi+M+4CghA)-- --===============1869711909== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1869711909==-- From megaco-bounces@ietf.org Wed Aug 23 00:55:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFkmD-0005zc-8d; Wed, 23 Aug 2006 00:55:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFkmB-0005xK-Jh for megaco@ietf.org; Wed, 23 Aug 2006 00:55:39 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17] helo=jaguar.hss.hns.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFkcH-0004mv-1B for megaco@ietf.org; Wed, 23 Aug 2006 00:45:28 -0400 Received: from jaguar.hss.hns.com (localhost [127.0.0.1]) by jaguar.hss.hns.com (8.13.6/8.12.10) with ESMTP id k7N4l1lw023389 for ; Wed, 23 Aug 2006 10:17:01 +0530 (IST) Received: from webmail.hss.hns.com (webmail.hss.hns.com [10.203.158.17]) by jaguar.hss.hns.com (8.13.6/8.13.6) with ESMTP id k7N4l0J6023368; Wed, 23 Aug 2006 10:17:01 +0530 (IST) Received: from Dlfmail1.hss.hns.com ([10.203.142.23]) by webmail.hss.hns.com (Lotus Domino Release 6.5.2) with ESMTP id 2006082310152262-35179 ; Wed, 23 Aug 2006 10:15:22 +0530 In-Reply-To: <000601c6c665$2610a760$6291460a@china.huawei.com> Subject: Re: [Megaco] Another question about H248V3 To: Tony Zhang X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: "B Venkat S.R Swamy" Date: Wed, 23 Aug 2006 10:18:38 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on Dlfmail1/HSS(Release 6.5.2|June 01, 2004) at 08/23/2006 10:14:27 AM, Itemize by SMTP Server on WebMail/HSS(Release 6.5.2|June 01, 2004) at 08/23/2006 10:15:22 AM, Serialize by Router on WebMail/HSS(Release 6.5.2|June 01, 2004) at 08/23/2006 10:15:29 AM, Serialize complete at 08/23/2006 10:15:29 AM Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hi IMO, the procedures section in E.14 of H.248.1 V3(Sep 2005), clearly mentions that segmentation has to be done in such a way that each individual seg= ment are syntactically valid constructs. The example in the same section highlights such a case for a wildcarded Audit scenario. Also each segment should b= e limited to the size (MGMaxPDUSize/MGCMaxPDUSize) properties as mentioned in the package. As far as your particular query is concerned, the segmentation can be d= one at Action level and in the first segment, the context properties and so= me command replies(limited by size propertis) can be sent and in the next segment rest of the command replies can be sent without repeating the context properties in subsequent segments. regards B Venkat S.R Swamy Senior Technical Leader Flextronics Software Systems Phone: +91-124- 4176213 Fax: +91-124-4300247 web: www.flextronicssoftware.com = Tony Zhang = = To megaco@ietf.org = 08/23/2006 09:05 = cc AM = Subj= ect [Megaco] Another question about = H248V3 = = = = = = = Hi: I have some question to ask: transactionReply=A0=A0=A0=A0 =3D ReplyToken EQUAL TransactionID [SLASH = segmentNumber =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 [SLASH SegmentationCompleteToken]] LBRKT =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 [ImmAckRequiredToken COMMA] =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 (errorDescriptor / actionReplyList) RBRKT actionReplyList=A0=A0=A0=A0=A0 =3D actionReply *(COMMA actionReply) actionReply =3D CtxToken EQUAL ContextID [LBRKT (errorDescriptor / =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 commandReply /(commandReply COMMA =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 errorDescriptor)) RBRKT] commandReply=A0=A0=A0=A0=A0=A0=A0=A0 =3D ((contextProperties [COMMA com= mandReplyList]) / =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 commandReplyList) commandReplyList=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D commandReplys *(COMM= A commandReplys) commandReplys=A0=A0=A0=A0=A0=A0=A0 =3D (serviceChangeReply / auditReply= / ammsReply / =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 notifyReply) contextProperties=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D contextProperty *(COMM= A contextProperty) question: If (contextProperties [COMMA commandReplyList]) appear in commandReply,= how to deal with this circs when segment? Is there has particular rules to segment? regards Tony.Zhang.Tao@hotmail.com _______________________________________________ Megaco mailing list Megaco@ietf.org 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 Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Aug 23 22:23:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG4rs-0000si-0f; Wed, 23 Aug 2006 22:22:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG4rq-0000sc-3E for megaco@ietf.org; Wed, 23 Aug 2006 22:22:50 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG4rm-0006fN-Ri for megaco@ietf.org; Wed, 23 Aug 2006 22:22:50 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4H00K14E2FTM@szxga02-in.huawei.com> for megaco@ietf.org; Thu, 24 Aug 2006 10:39:51 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4H001HUE2EOB@szxga02-in.huawei.com> for megaco@ietf.org; Thu, 24 Aug 2006 10:39:51 +0800 (CST) Received: from z26452a ([10.70.145.98]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4H003PJDF7SW@szxml03-in.huawei.com> for megaco@ietf.org; Thu, 24 Aug 2006 10:25:58 +0800 (CST) Date: Thu, 24 Aug 2006 10:21:56 +0800 From: Tony Zhang To: megaco@ietf.org Message-id: <000301c6c724$12522040$6291460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcbHJBIUKWNhf1P7SL2k/X4jxjRWYg== X-Spam-Score: 0.2 (/) X-Scan-Signature: 75ffc14afb41eeead069d201c6c1d81f Subject: [Megaco] Response should resend? X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1353239212==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1353239212== Content-type: multipart/alternative; boundary="Boundary_(ID_qtIaZbxJnb1Sudumzv6bBg)" This is a multi-part message in MIME format. --Boundary_(ID_qtIaZbxJnb1Sudumzv6bBg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT HI All: I have a question about Three-way handshake. If a response have been send, but the response entity do not received the response acknowledgement. Then, Is it necessary or possible or unnecessary that the response should be initiative resent by respond entity in Three-way handshake mode? Thanks. Best regards! --Boundary_(ID_qtIaZbxJnb1Sudumzv6bBg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

HI All:

=C2=A0=C2=A0=C2=A0 I have a question about=C2=A0 Three-way = handshake. If a response have been send, but the response entity do not received the response = acknowledgement. Then, Is it necessary or possible or unnecessary that the response = should be initiative resent by respond entity in Three-way handshake mode? = Thanks.

 

Best regards!

 =

--Boundary_(ID_qtIaZbxJnb1Sudumzv6bBg)-- --===============1353239212== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1353239212==-- From megaco-bounces@ietf.org Thu Aug 24 02:47:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG90E-0006ez-3q; Thu, 24 Aug 2006 02:47:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG90D-0006eu-8D for megaco@ietf.org; Thu, 24 Aug 2006 02:47:45 -0400 Received: from mail.tdsoft.com ([212.143.64.34] helo=vocaltec.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GG90A-0006Er-SY for megaco@ietf.org; Thu, 24 Aug 2006 02:47:45 -0400 Received: from mailserver.vocaltec.co.il ([172.16.1.203]) by eSafe SMTP Relay 1156390736; Thu, 24 Aug 2006 09:46:57 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Megaco] Response should resend? Date: Thu, 24 Aug 2006 09:48:01 +0200 Message-ID: <431F3BDE11BF2F42A22CBEFA36BD88A461D1D9@mailserver.vocaltec.local> In-Reply-To: <000301c6c724$12522040$6291460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Response should resend? Thread-Index: AcbHJBIUKWNhf1P7SL2k/X4jxjRWYgALMAzA From: "Raphael Tryster" To: "Tony Zhang" , X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 73948e4d005645343fd08e813e5615ef Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0533394745==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0533394745== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C751.9FDE5068" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C751.9FDE5068 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHJlc3BvbmRlciBzaG91bGQgbm90IHJldHJhbnNtaXQgdGhlIHJlc3BvbnNlIGFzIGEgcmVz dWx0IG9mIG5vdCByZWNlaXZpbmcgYWNrLiAgSWYgdGhlIGluaXRpYXRvciBvZiB0aGUgcmVxdWVz dCBkb2VzIG5vdCByZWNlaXZlIHRoZSByZXNwb25zZSwgaXQgd2lsbCByZXRyYW5zbWl0IHRoZSBy ZXF1ZXN0LCBhbmQgdGhlIHJlc3BvbmRlciBzaG91bGQgdGhlbiByZXRyYW5zbWl0IHRoZSByZXNw b25zZS4gIEFjayBqdXN0IHRlbGxzIHRoZSByZXNwb25kZXIgdGhhdCBpdCBjYW4gZGVsZXRlIHRo ZSByZXNwb25zZSBiZWNhdXNlIGl0IGtub3dzIGl0IHdhcyByZWNlaXZlZC4gIElmIG5vIGFjayBp cyByZWNlaXZlZCwgdGhlIHJlc3BvbmRlciBuZWVkcyB0byBrZWVwIGEgY29weSBvZiBpdCBmb3Ig YSB3aGlsZSAoc2VlIHRoZSBzdGFuZGFyZCBmb3IgcHJlY2lzZSBkZWZpbml0aW9uKSBpbiBjYXNl IGl0IHJlY2VpdmVzIGEgcmV0cmFuc21pdHRlZCByZXF1ZXN0Lg0KIA0KUmFwaGFlbCBUcnlzdGVy DQogDQoiVGhpbmdzIHNob3VsZCBiZSBtYWRlIGFzIHNpbXBsZSBhcyBwb3NzaWJsZSwgYnV0IG5v dCBhbnkgc2ltcGxlci4iICAtIEFsYmVydCBFaW5zdGVpbg0KIA0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IFRvbnkgWmhhbmcgW21haWx0bzp6aGFuZ3Rhb19od0BodWF3ZWkuY29t XQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAyNCwgMjAwNiA0OjIyIEFNDQpUbzogbWVnYWNvQGll dGYub3JnDQpTdWJqZWN0OiBbTWVnYWNvXSBSZXNwb25zZSBzaG91bGQgcmVzZW5kPw0KIA0KSEkg QWxsOg0KICAgIEkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0ICBUaHJlZS13YXkgaGFuZHNoYWtlLiBJ ZiBhIHJlc3BvbnNlIGhhdmUgYmVlbiBzZW5kLCBidXQgdGhlIHJlc3BvbnNlIGVudGl0eSBkbyBu b3QgcmVjZWl2ZWQgdGhlIHJlc3BvbnNlIGFja25vd2xlZGdlbWVudC4gVGhlbiwgSXMgaXQgbmVj ZXNzYXJ5IG9yIHBvc3NpYmxlIG9yIHVubmVjZXNzYXJ5IHRoYXQgdGhlIHJlc3BvbnNlIHNob3Vs ZCBiZSBpbml0aWF0aXZlIHJlc2VudCBieSByZXNwb25kIGVudGl0eSBpbiBUaHJlZS13YXkgaGFu ZHNoYWtlIG1vZGU/IFRoYW5rcy4NCiANCkJlc3QgcmVnYXJkcyENCiANCioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioNClRoaXMgZS1tYWlsIGNvbnRhaW5zIGNvbmZpZGVudGlh bCwgcHJpdmlsZWdlZCBvciBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiB0byBWb2NhbFRlYyBDb21t dW5pY2F0aW9ucy4NCklmIHlvdSByZWNlaXZlZCB0aGlzIG1lc3NlZ2UgYnkgbWlzdGFrZSwgcGxl YXNlIGluZm9ybSB1cyBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbGwgY29waWVz Lg0KKioqIGVTYWZlIHNjYW5uZWQgdGhpcyBlbWFpbCBmb3IgdmlydXNlcywgdmFuZGFscywgYW5k IG1hbGljaW91cyBjb250ZW50LiAqKioNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioNCg== ------_=_NextPart_001_01C6C751.9FDE5068 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RS L1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIg Q09OVEVOVD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCg0KDQo8bWV0YSBuYW1lPVByb2dJ ZCBjb250ZW50PVdvcmQuRG9jdW1lbnQ+DQo8bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50PSJN aWNyb3NvZnQgV29yZCA5Ij4NCjxtZXRhIG5hbWU9T3JpZ2luYXRvciBjb250ZW50PSJNaWNyb3Nv ZnQgV29yZCA5Ij4NCjxsaW5rIHJlbD1GaWxlLUxpc3QgaHJlZj0iY2lkOmZpbGVsaXN0LnhtbEAw MUM2Qzc2Mi42NUFDRTU3MCI+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpPZmZpY2VE b2N1bWVudFNldHRpbmdzPg0KICA8bzpEb05vdFJlbHlPbkNTUy8+DQogPC9vOk9mZmljZURvY3Vt ZW50U2V0dGluZ3M+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CiA8dzpXb3JkRG9jdW1lbnQ+DQogIDx3Olpvb20+MDwvdzpab29tPg0KICA8dzpEb2N1bWVudEtp bmQ+RG9jdW1lbnRFbWFpbDwvdzpEb2N1bWVudEtpbmQ+DQogIDx3OkVudmVsb3BlVmlzLz4NCiA8 L3c6V29yZERvY3VtZW50Pg0KPC94bWw+PCFbZW5kaWZdLS0+DQo8c3R5bGU+DQo8IS0tDQpwLkEN Cgl7bXNvLXBhcmEtbWFyZ2luLXRvcDoxLjBnZDsNCgltc28tcGFyYS1tYXJnaW4tcmlnaHQ6MGNt Ow0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206MGNtOw0KCW1zby1wYXJhLW1hcmdpbi1sZWZ0OjU0 LjQ1cHQ7DQoJbXNvLXBhcmEtbWFyZ2luLWJvdHRvbTouMDAwMXB0O30NCmxpLkENCgl7bXNvLXBh cmEtbWFyZ2luLXRvcDoxLjBnZDsNCgltc28tcGFyYS1tYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1w YXJhLW1hcmdpbi1ib3R0b206MGNtOw0KCW1zby1wYXJhLW1hcmdpbi1sZWZ0OjU0LjQ1cHQ7DQoJ bXNvLXBhcmEtbWFyZ2luLWJvdHRvbTouMDAwMXB0O30NCmRpdi5BDQoJe21zby1wYXJhLW1hcmdp bi10b3A6MS4wZ2Q7DQoJbXNvLXBhcmEtbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tcGFyYS1tYXJn aW4tYm90dG9tOjBjbTsNCgltc28tcGFyYS1tYXJnaW4tbGVmdDo1NC40NXB0Ow0KCW1zby1wYXJh LW1hcmdpbi1ib3R0b206LjAwMDFwdDt9DQpwLkEyDQoJe21zby1wYXJhLW1hcmdpbi10b3A6MGNt Ow0KCW1zby1wYXJhLW1hcmdpbi1yaWdodDowY207DQoJbXNvLXBhcmEtbWFyZ2luLWJvdHRvbTox LjBnZDsNCgltc28tcGFyYS1tYXJnaW4tbGVmdDo1NC40NXB0O30NCmxpLkEyDQoJe21zby1wYXJh LW1hcmdpbi10b3A6MGNtOw0KCW1zby1wYXJhLW1hcmdpbi1yaWdodDowY207DQoJbXNvLXBhcmEt bWFyZ2luLWJvdHRvbToxLjBnZDsNCgltc28tcGFyYS1tYXJnaW4tbGVmdDo1NC40NXB0O30NCmRp di5BMg0KCXttc28tcGFyYS1tYXJnaW4tdG9wOjBjbTsNCgltc28tcGFyYS1tYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206MS4wZ2Q7DQoJbXNvLXBhcmEtbWFyZ2luLWxl ZnQ6NTQuNDVwdDt9DQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7DQoJbXNvLWZv bnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250 LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZToxNjI3NDIxMzE5IC0yMTQ3NDgz NjQ4IDggMCA2NjA0NyAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkFyaWFsIFVuaWNv ZGUgTVMiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0Ow0KCW1zby1mb250LWNoYXJz ZXQ6MTI4Ow0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNo OnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotMSAtMzY5MDk4NzUzIDYzIDAgNDEyOTAy MyAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCW1zby1mb250LWFsdDoi VGltZXMgTmV3IFJvbWFuIjsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9u dC1mYW1pbHk6YXV0bzsNCgltc28tZm9udC1waXRjaDphdXRvOw0KCW1zby1mb250LXNpZ25hdHVy ZTowIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oum7keS9kzsNCgltc28t Zm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6YXV0bzsNCgltc28tZm9u dC1waXRjaDphdXRvOw0KCW1zby1mb250LXNpZ25hdHVyZTowIDAgMCAwIDAgMDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQEFyaWFsIFVuaWNvZGUgTVMiOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDIgMiAyIDIgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MTI4Ow0KCW1zby1nZW5lcmljLWZv bnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNp Z25hdHVyZTotMSAtMzY5MDk4NzUzIDYzIDAgNDEyOTAyMyAwO30NCiAvKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttc28t c3R5bGUtcGFyZW50OiIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWxpbmUtaGVpZ2h0OjE1MCU7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWxheW91 dC1ncmlkLW1vZGU6Y2hhcjsNCgl0ZXh0LWF1dG9zcGFjZTpub25lOw0KCWZvbnQtc2l6ZToxMC41 cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6IkFyaWFsIFVuaWNvZGUgTVMiO30NCmgxDQoJe21hcmdpbi10b3A6MTIuMHB0Ow0KCW1h cmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbToxMi4wcHQ7DQoJbWFyZ2luLWxlZnQ6MjEu NnB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0LWluZGVudDotMjEuNnB0Ow0KCW1zby1w YWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglwYWdlLWJyZWFrLWFmdGVyOmF2b2lkOw0KCW1zby1v dXRsaW5lLWxldmVsOjE7DQoJbXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzI7DQoJdGFiLXN0b3BzOmxp c3QgMjEuNnB0Ow0KCWZvbnQtc2l6ZToxNi4wcHQ7DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6IkFyaWFsIFVuaWNvZGUgTVMiO30NCmgyDQoJe21hcmdpbi10 b3A6MTIuMHB0Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbToxMi4wcHQ7DQoJ bWFyZ2luLWxlZnQ6MjguOHB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0LWluZGVudDot MjguOHB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglwYWdlLWJyZWFrLWFmdGVy OmF2b2lkOw0KCW1zby1vdXRsaW5lLWxldmVsOjI7DQoJbXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzI7 DQoJdGFiLXN0b3BzOmxpc3QgMjguOHB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6QXJpYWw7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IkFyaWFsIFVuaWNvZGUgTVMiOw0K CWZvbnQtd2VpZ2h0Om5vcm1hbDt9DQpoMw0KCXttYXJnaW4tdG9wOjEzLjBwdDsNCgltYXJnaW4t cmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MTMuMHB0Ow0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsN Cgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1pbmRlbnQ6LTM2LjBwdDsNCglsaW5lLWhlaWdo dDoxNzIlOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglwYWdlLWJyZWFrLWFmdGVy OmF2b2lkOw0KCW1zby1vdXRsaW5lLWxldmVsOjM7DQoJbXNvLWxpc3Q6bDEgbGV2ZWwzIGxmbzI7 DQoJdGFiLXN0b3BzOmxpc3QgMzYuMHB0Ow0KCWxheW91dC1ncmlkLW1vZGU6Y2hhcjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiJBcmlhbCBVbmljb2RlIE1TIjsNCglmb250LXdlaWdodDpub3JtYWw7 fQ0KcC5Nc29IZWFkZXIsIGxpLk1zb0hlYWRlciwgZGl2Lk1zb0hlYWRlcg0KCXttYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJbXNvLXBh Z2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWxheW91dC1ncmlkLW1vZGU6Y2hhcjsNCglmb250LXNp emU6OS4wcHQ7DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 IkFyaWFsIFVuaWNvZGUgTVMiO30NCnAuTXNvRm9vdGVyLCBsaS5Nc29Gb290ZXIsIGRpdi5Nc29G b290ZXINCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2lu YXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTpBcmlh bDsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiQXJpYWwgVW5pY29kZSBNUyI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXtjb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KcC5Nc29BdXRvU2lnLCBsaS5Nc29BdXRvU2ln LCBkaXYuTXNvQXV0b1NpZw0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZv bnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6IkFyaWFsIFVuaWNvZGUgTVMiO30NCnAuYSwgbGkuYSwgZGl2LmEN Cgl7bXNvLXN0eWxlLW5hbWU6YTsNCgltYXJnaW4tdG9wOjEyLjBwdDsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjU0LjQ1cHQ7DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246Y2VudGVyOw0KCXRleHQtaW5kZW50Oi0xOC40 NXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCgltc28tbGlzdDpsMCBsZXZlbDkg bGZvNDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6IkFyaWFsIFVuaWNvZGUgTVMiO30NCnAuYTAsIGxpLmEwLCBkaXYuYTAN Cgl7bXNvLXN0eWxlLW5hbWU6YTA7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJ Zm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IkFyaWFsIFVuaWNv ZGUgTVMiO30NCnAuYTEsIGxpLmExLCBkaXYuYTENCgl7bXNvLXN0eWxlLW5hbWU6YTE7DQoJbWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpjZW50ZXI7DQoJ bXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1m YW1pbHk6QXJpYWw7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IkFyaWFsIFVuaWNvZGUgTVMi Ow0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KcC5hMiwgbGkuYTIsIGRpdi5hMg0KCXttc28tc3R5bGUt bmFtZTphMjsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1i b3R0b206MTIuMHB0Ow0KCW1hcmdpbi1sZWZ0OjU0LjQ1cHQ7DQoJdGV4dC1hbGlnbjpjZW50ZXI7 DQoJdGV4dC1pbmRlbnQ6LTE4LjQ1cHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0K CW1zby1saXN0OmwwIGxldmVsOCBsZm80Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWls eTpBcmlhbDsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiQXJpYWwgVW5pY29kZSBNUyI7fQ0K cC5hMywgbGkuYTMsIGRpdi5hMw0KCXttc28tc3R5bGUtbmFtZTphMzsNCgltYXJnaW4tdG9wOjQu MHB0Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTo0LjBwdDsNCgltYXJnaW4t bGVmdDowY207DQoJdGV4dC1hbGlnbjpjZW50ZXI7DQoJbGluZS1oZWlnaHQ6MTUwJTsNCgltc28t cGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJcGFnZS1icmVhay1hZnRlcjphdm9pZDsNCglsYXlv dXQtZ3JpZC1tb2RlOmNoYXI7DQoJdGV4dC1hdXRvc3BhY2U6bm9uZTsNCglmb250LXNpemU6MTAu NXB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiJBcmlhbCBVbmljb2RlIE1TIjt9DQpwLmE0LCBsaS5hNCwgZGl2LmE0DQoJe21zby1z dHlsZS1uYW1lOmE0Ow0KCW1hcmdpbi10b3A6MTUuMHB0Ow0KCW1hcmdpbi1yaWdodDowY207DQoJ bWFyZ2luLWJvdHRvbToxNS4wcHQ7DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCXRleHQtYWxpZ246Y2Vu dGVyOw0KCWxpbmUtaGVpZ2h0OjE1MCU7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0K CWxheW91dC1ncmlkLW1vZGU6Y2hhcjsNCgl0ZXh0LWF1dG9zcGFjZTpub25lOw0KCWZvbnQtc2l6 ZToxOC4wcHQ7DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 IkFyaWFsIFVuaWNvZGUgTVMiO30NCnAuYTUsIGxpLmE1LCBkaXYuYTUNCgl7bXNvLXN0eWxlLW5h bWU6YTU7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbGluZS1oZWln aHQ6MTUwJTsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJbGF5b3V0LWdyaWQtbW9k ZTpjaGFyOw0KCXRleHQtYXV0b3NwYWNlOm5vbmU7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiQXJp YWwgVW5pY29kZSBNUyI7fQ0KcC5hNiwgbGkuYTYsIGRpdi5hNg0KCXttc28tc3R5bGUtbmFtZTph NjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1 c3RpZnk7DQoJbGluZS1oZWlnaHQ6MTUwJTsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47 DQoJbGF5b3V0LWdyaWQtbW9kZTpjaGFyOw0KCXRleHQtYXV0b3NwYWNlOm5vbmU7DQoJZm9udC1z aXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5OkFyaWFsOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiJBcmlhbCBVbmljb2RlIE1TIjt9DQpwLmE3LCBsaS5hNywgZGl2LmE3DQoJe21zby1zdHlsZS1u YW1lOmE3Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxp Z246anVzdGlmeTsNCgl0ZXh0LWluZGVudDoxOC4wcHQ7DQoJbGluZS1oZWlnaHQ6MTUwJTsNCglt c28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJbGF5b3V0LWdyaWQtbW9kZTpjaGFyOw0KCXRl eHQtYXV0b3NwYWNlOm5vbmU7DQoJZm9udC1zaXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5OkFyaWFs Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJBcmlhbCBVbmljb2RlIE1TIjt9DQpwLmE4LCBs aS5hOCwgZGl2LmE4DQoJe21zby1zdHlsZS1uYW1lOmE4Ow0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtaW5kZW50OjIxLjBwdDsNCglsaW5lLWhlaWdodDoxNTAl Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglsYXlvdXQtZ3JpZC1tb2RlOmNoYXI7 DQoJdGV4dC1hdXRvc3BhY2U6bm9uZTsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5 OkFyaWFsOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJBcmlhbCBVbmljb2RlIE1TIjsNCglj b2xvcjpibHVlOw0KCWZvbnQtc3R5bGU6aXRhbGljO30NCnNwYW4uYTkNCgl7bXNvLXN0eWxlLW5h bWU6YTk7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OuWui+S9kzsNCgltc28taGFuc2ktZm9udC1m YW1pbHk65a6L5L2TOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0Kc3Bhbi5h YQ0KCXttc28tc3R5bGUtbmFtZTphYTsNCgltc28tYXNjaWktZm9udC1mYW1pbHk65a6L5L2TOw0K CW1zby1oYW5zaS1mb250LWZhbWlseTrlrovkvZM7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWln aHQ6Ym9sZDt9DQpzcGFuLkVtYWlsU3R5bGUzMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cgltc28tYXNjaWktZm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkFy aWFsOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFsOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K c3Bhbi5FbWFpbFN0eWxlMzMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6QXJpYWw7DQoJ bXNvLWhhbnNpLWZvbnQtZmFtaWx5OkFyaWFsOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFs Ow0KCWNvbG9yOm5hdnk7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo1OTUuM3B0IDg0MS45cHQ7 DQoJbWFyZ2luOjY1LjZwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDsNCgltc28taGVhZGVyLW1hcmdp bjozNS40cHQ7DQoJbXNvLWZvb3Rlci1tYXJnaW46MzUuNHB0Ow0KCW1zby1wYXBlci1zb3VyY2U6 MDsNCgltc28tZ3V0dGVyLWRpcmVjdGlvbjpydGw7DQoJbGF5b3V0LWdyaWQ6MTUuNnB0O30NCmRp di5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCiAvKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTIzOTY0NjgyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czozMDE5MDc2NzA7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdWZmaXg6bm9uZTsN Cgltc28tbGV2ZWwtdGV4dDoiJTEgICI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCgl0ZXh0LWlu ZGVudDowY207DQoJbXNvLWFuc2ktZm9udC1zaXplOjE4LjBwdDsNCgltc28tYmlkaS1mb250LXNp emU6MTguMHB0Ow0KCWZvbnQtZmFtaWx5OkFyaWFsOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 Oum7keS9kzsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28t YW5zaS1mb250LXdlaWdodDpub3JtYWw7DQoJbXNvLWFuc2ktZm9udC1zdHlsZTpub3JtYWw7fQ0K QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1zdWZmaXg6bm9uZTsNCgltc28tbGV2ZWwtdGV4 dDoiJTFcLiUyICAiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDowY207DQoJdGV4dC1pbmRlbnQ6MGNtOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxNS4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjE1LjBwdDsN Cglmb250LWZhbWlseTpBcmlhbDsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjsNCgltc28tYW5zaS1mb250LXdlaWdodDpub3JtYWw7DQoJbXNvLWFuc2ktZm9udC1zdHls ZTpub3JtYWw7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1zdWZmaXg6bm9uZTsNCglt c28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4lMyAgIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCXRl eHQtaW5kZW50OjBjbTsNCgltc28tYW5zaS1mb250LXNpemU6MTIuMHB0Ow0KCW1zby1iaWRpLWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6bm9ybWFsOw0KCW1z by1hbnNpLWZvbnQtc3R5bGU6bm9ybWFsO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwt c3VmZml4Om5vbmU7DQoJbXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuJTNcLiU0ICAiOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCglt YXJnaW4tbGVmdDowY207DQoJdGV4dC1pbmRlbnQ6MGNtOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC41cHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseTpBcmlhbDsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYW5zaS1mb250 LXdlaWdodDpub3JtYWw7DQoJbXNvLWFuc2ktZm9udC1zdHlsZTpub3JtYWw7fQ0KQGxpc3QgbDA6 bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBjbTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6Mi4wY207DQoJdGV4dC1pbmRlbnQ6LTE1LjZwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuNXB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMC41cHQ7 DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6bm9ybWFsOw0KCW1zby1hbnNpLWZvbnQtc3R5 bGU6bm9ybWFsO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtdGV4dDoiJTZcKSI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIuMGNtOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDoyLjBjbTsNCgl0ZXh0LWluZGVudDotMTUuNnB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC41cHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZh bWlseTpBcmlhbDsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCglt c28tYW5zaS1mb250LXdlaWdodDpub3JtYWw7DQoJbXNvLWFuc2ktZm9udC1zdHlsZTpub3JtYWw7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBjbTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJbWFyZ2luLWxlZnQ6Mi4wY207DQoJdGV4dC1pbmRlbnQ6LTE1LjZwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuNXB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9u dC1mYW1pbHk6QXJpYWw7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6bm9ybWFsOw0KCW1zby1hbnNpLWZvbnQtc3R5bGU6bm9y bWFsO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtcmVzZXQtbGV2ZWw6bGV2ZWwxOw0K CW1zby1sZXZlbC1zdWZmaXg6c3BhY2U7DQoJbXNvLWxldmVsLXRleHQ65Zu+JTg7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpjZW50ZXI7DQoJ bWFyZ2luLWxlZnQ6MGNtOw0KCXRleHQtaW5kZW50OjBjbTsNCgltc28tYW5zaS1mb250LXNpemU6 OS4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5OkFyaWFsOw0K CW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5Oum7keS9kzsNCgltc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjsNCgltc28tYW5zaS1mb250LXdlaWdodDpub3JtYWw7DQoJbXNvLWFu c2ktZm9udC1zdHlsZTpub3JtYWw7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1yZXNl dC1sZXZlbDpsZXZlbDE7DQoJbXNvLWxldmVsLXN1ZmZpeDpzcGFjZTsNCgltc28tbGV2ZWwtdGV4 dDrooaglOTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmNlbnRlcjsNCgltYXJnaW4tbGVmdDowY207DQoJdGV4dC1pbmRlbnQ6MGNtOw0KCW1z by1hbnNpLWZvbnQtc2l6ZTo5LjBwdDsNCgltc28tYmlkaS1mb250LXNpemU6OS4wcHQ7DQoJZm9u dC1mYW1pbHk6QXJpYWw7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk66buR5L2TOw0KCW1zby1i aWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1hbnNpLWZvbnQtd2VpZ2h0 Om5vcm1hbDsNCgltc28tYW5zaS1mb250LXN0eWxlOm5vcm1hbDt9DQpAbGlzdCBsMQ0KCXttc28t bGlzdC1pZDoxNjY2NDc1MDQ5Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjg5NDU1MDI7fQ0K QGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiUxOw0KCW1zby1sZXZlbC10YWItc3Rv cDoyMS42cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0 OjIxLjZwdDsNCgl0ZXh0LWluZGVudDotMjEuNnB0O30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28t bGV2ZWwtdGV4dDoiJTFcLiUyIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjguOHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyOC44cHQ7DQoJdGV4dC1p bmRlbnQ6LTI4LjhwdDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLXRleHQ6IiUxXC4l MlwuJTMiOw0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgl0ZXh0LWluZGVudDotMzYuMHB0 O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS4wY207DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjQ2LjhwdDsNCgl0ZXh0LWlu ZGVudDotMzQuMHB0O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtdGV4dDolNe+8iTsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MS4wY207DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCW1hcmdpbi1sZWZ0OjQ2LjhwdDsNCgl0ZXh0LWluZGVudDotMzQuMHB0O30NCkBsaXN0 IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGV4dDolNu+8iTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4wY207DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjQ2LjhwdDsNCgl0ZXh0LWluZGVu dDotMzQuMHB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpy b21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGV4dDolNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4w Y207DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjQ2Ljhw dDsNCgl0ZXh0LWluZGVudDotMzQuMHB0O30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwt dGV4dDoiJTFcLiUyXC4lM1wuJTRcLiU1XC4lNlwuJTdcLiU4IjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVm dDo3Mi4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTcyLjBwdDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNv LWxldmVsLXRleHQ6IiUxXC4lMlwuJTNcLiU0XC4lNVwuJTZcLiU3XC4lOFwuJTkiOw0KCW1zby1s ZXZlbC10YWItc3RvcDo3OS4ycHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0Ojc5LjJwdDsNCgl0ZXh0LWluZGVudDotNzkuMnB0O30NCm9sDQoJe21hcmdp bi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPg0KPC9zdHlsZT4N CjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjciLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiLz4NCiAgPG86cmVncm91cHRhYmxlIHY6ZXh0PSJlZGl0Ij4NCiAgIDxvOmVu dHJ5IG5ldz0iMSIgb2xkPSIwIi8+DQogIDwvbzpyZWdyb3VwdGFibGU+DQogPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVTIGxpbms9 Ymx1ZSB2bGluaz1wdXJwbGUgc3R5bGU9J3RhYi1pbnRlcnZhbDozNi4wcHQ7dGV4dC1qdXN0aWZ5 LXRyaW06DQpwdW5jdHVhdGlvbic+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjEgZGlyPVJUTCBzdHls ZT0nbGF5b3V0LWdyaWQ6MTUuNnB0Jz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIGRpcj1MVFI+PHNw YW4gY2xhc3M9RW1haWxTdHlsZTMzPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5DQpmYWNlPUFyaWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6DQpBcmlhbCc+VGhlIHJlc3BvbmRlciBzaG91bGQgbm90IHJldHJhbnNtaXQg dGhlIHJlc3BvbnNlIGFzIGEgcmVzdWx0IG9mIG5vdCByZWNlaXZpbmcNCmFjay4gPHNwYW4gc3R5 bGU9Im1zby1zcGFjZXJ1bjogeWVzIj7CoDwvc3Bhbj5JZiB0aGUgaW5pdGlhdG9yIG9mIHRoZSBy ZXF1ZXN0DQpkb2VzIG5vdCByZWNlaXZlIHRoZSByZXNwb25zZSwgaXQgd2lsbCByZXRyYW5zbWl0 IHRoZSByZXF1ZXN0LCBhbmQgdGhlDQpyZXNwb25kZXIgc2hvdWxkIHRoZW4gcmV0cmFuc21pdCB0 aGUgcmVzcG9uc2UuPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj7CoA0KPC9zcGFuPkFj ayBqdXN0IHRlbGxzIHRoZSByZXNwb25kZXIgdGhhdCBpdCBjYW4gZGVsZXRlIHRoZSByZXNwb25z ZSBiZWNhdXNlIGl0DQprbm93cyBpdCB3YXMgcmVjZWl2ZWQuIDxzcGFuIHN0eWxlPSJtc28tc3Bh Y2VydW46IHllcyI+wqA8L3NwYW4+SWYgbm8gYWNrIGlzDQpyZWNlaXZlZCwgdGhlIHJlc3BvbmRl ciBuZWVkcyB0byBrZWVwIGEgY29weSBvZiBpdCBmb3IgYSB3aGlsZSAoc2VlIHRoZQ0Kc3RhbmRh cmQgZm9yIHByZWNpc2UgZGVmaW5pdGlvbikgaW4gY2FzZSBpdCByZWNlaXZlcyBhIHJldHJhbnNt aXR0ZWQgcmVxdWVzdC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsIGRpcj1MVFI+PHNwYW4gY2xhc3M9RW1haWxTdHlsZTMzPjxmb250IHNp emU9MiBjb2xvcj1uYXZ5DQpmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O21zby1iaWRpLWZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6DQpBcmlhbCc+PCFbaWYgIXN1 cHBvcnRFbXB0eVBhcmFzXT4mbmJzcDs8IVtlbmRpZl0+PG86cD48L286cD48L3NwYW4+PC9mb250 Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBkaXI9TFRSPjwhLS1baWYgc3VwcG9y dEZpZWxkc10+PHNwYW4gY2xhc3M9RW1haWxTdHlsZTMzPjxmb250IA0Kc2l6ZT0yIGNvbG9yPW5h dnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDttc28tYmlkaS1mb250 LXNpemU6DQoxMC41cHQ7Zm9udC1mYW1pbHk6QXJpYWwnPjxzcGFuIHN0eWxlPSdtc28tZWxlbWVu dDpmaWVsZC1iZWdpbic+PC9zcGFuPjxzcGFuIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj7C oDwvc3Bhbj5BVVRPVEVYVExJU1QgXHMgJnF1b3Q7RS1tYWlsIFNpZ25hdHVyZSZxdW90OyA8c3Bh biANCnN0eWxlPSdtc28tZWxlbWVudDpmaWVsZC1zZXBhcmF0b3InPjwvc3Bhbj48L3NwYW4+PC9m b250Pjwvc3Bhbj48IVtlbmRpZl0tLT48Zm9udA0KY29sb3I9bmF2eT48c3BhbiBzdHlsZT0nY29s b3I6bmF2eSc+UmFwaGFlbCBUcnlzdGVyPC9zcGFuPjwvZm9udD48Zm9udA0KY29sb3I9bmF2eT48 c3BhbiBzdHlsZT0nY29sb3I6bmF2eTttc28tY29sb3ItYWx0OndpbmRvd3RleHQnPjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBkaXI9TFRSPjxmb250 IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4NCnN0eWxlPSdm b250LXNpemU6MTAuNXB0O2NvbG9yOm5hdnknPjwhW2lmICFzdXBwb3J0RW1wdHlQYXJhc10+Jm5i c3A7PCFbZW5kaWZdPjwvc3Bhbj48L2ZvbnQ+PGZvbnQNCmNvbG9yPW5hdnk+PHNwYW4gc3R5bGU9 J2NvbG9yOm5hdnk7bXNvLWNvbG9yLWFsdDp3aW5kb3d0ZXh0Jz48bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgZGlyPUxUUj48Zm9udCBzaXplPTIgY29s b3I9bmF2eSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEw LjVwdDtjb2xvcjpuYXZ5Jz4mcXVvdDtUaGluZ3Mgc2hvdWxkIGJlIG1hZGUgYXMgc2ltcGxlIGFz DQpwb3NzaWJsZSwgYnV0IG5vdCBhbnkgc2ltcGxlci4mcXVvdDs8c3BhbiBzdHlsZT0ibXNvLXNw YWNlcnVuOiB5ZXMiPsKgIDwvc3Bhbj4tDQpBbGJlcnQgRWluc3RlaW48L3NwYW4+PC9mb250Pjxm b250IGNvbG9yPW5hdnk+PHNwYW4gc3R5bGU9J2NvbG9yOm5hdnk7DQptc28tY29sb3ItYWx0Ondp bmRvd3RleHQnPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbCBkaXI9TFRSPjwhLS1baWYgc3VwcG9ydEZpZWxkc10+PHNwYW4gY2xhc3M9RW1haWxTdHls ZTMzPjxmb250IA0Kc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDttc28tYmlkaS1mb250LXNpemU6DQoxMC41cHQ7Zm9udC1mYW1pbHk6QXJp YWwnPjxzcGFuIHN0eWxlPSdtc28tZWxlbWVudDpmaWVsZC1lbmQnPjwvc3Bhbj48L3NwYW4+PC9m b250Pjwvc3Bhbj48IVtlbmRpZl0tLT48c3Bhbg0KY2xhc3M9RW1haWxTdHlsZTMzPjxmb250IHNp emU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBw dDttc28tYmlkaS1mb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkFyaWFsJz48IVtpZiAhc3Vw cG9ydEVtcHR5UGFyYXNdPiZuYnNwOzwhW2VuZGlmXT48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIGRpcj1MVFIgc3R5bGU9J21hcmdpbi1s ZWZ0OjM2LjBwdCc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsYWNrDQpmYWNlPVRhaG9tYT48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWE7Y29sb3I6YmxhY2snPi0t LS0tT3JpZ2luYWwNCk1lc3NhZ2UtLS0tLTxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdo dDpib2xkJz5Gcm9tOjwvc3Bhbj48L2I+IFRvbnkgWmhhbmcNClttYWlsdG86emhhbmd0YW9faHdA aHVhd2VpLmNvbV08YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U2VudDo8 L3NwYW4+PC9iPiBUaHVyc2RheSwgQXVndXN0IDI0LCAyMDA2DQo0OjIyIEFNPGJyPg0KPGI+PHNw YW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlRvOjwvc3Bhbj48L2I+IG1lZ2Fjb0BpZXRmLm9y Zzxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5TdWJqZWN0Ojwvc3Bhbj48 L2I+IFtNZWdhY29dIFJlc3BvbnNlIHNob3VsZA0KcmVzZW5kPzwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWwgZGlyPUxUUiBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYuMHB0Jz48 Zm9udCBzaXplPTINCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC41cHQnPjwhW2lmICFzdXBwb3J0RW1wdHlQYXJhc10+Jm5ic3A7PCFbZW5kaWZdPjxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBkaXI9TFRSIHN0 eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQ7bGluZS1oZWlnaHQ6MTIuMHB0Jz48Zm9udA0Kc2l6ZT0y IGNvbG9yPWJsYWNrIGZhY2U95a6L5L2TPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OuWui+S9kzsNCmNvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Jz5ISSBBbGw6PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsIGRpcj1MVFIgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdDtsaW5lLWhlaWdodDoxMi4wcHQn Pjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KIkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFj azttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwv Zm9udD48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U95a6L5L2TPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kzsNCmNvbG9yOmJsYWNrO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOJz4gSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQ8L3NwYW4+PC9mb250 Pjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KIkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFj azttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udA0K c2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U95a6L5L2TPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OuWui+S9kzsNCmNvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOJz4gVGhyZWUtd2F5IGhhbmRzaGFrZS4gSWYgYSByZXNwb25zZQ0KaGF2ZSBiZWVuIHNl bmQsIGJ1dCB0aGUgcmVzcG9uc2UgZW50aXR5IGRvIG5vdCByZWNlaXZlZCB0aGUgcmVzcG9uc2UN CmFja25vd2xlZGdlbWVudC4gVGhlbiwgSXMgaXQgbmVjZXNzYXJ5IG9yIHBvc3NpYmxlIG9yIHVu bmVjZXNzYXJ5IHRoYXQgdGhlDQpyZXNwb25zZSBzaG91bGQgYmUgaW5pdGlhdGl2ZSByZXNlbnQg YnkgcmVzcG9uZCBlbnRpdHkgaW4gVGhyZWUtd2F5IGhhbmRzaGFrZQ0KbW9kZT8gVGhhbmtzLjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBkaXI9TFRS IHN0eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQ7bGluZS1oZWlnaHQ6MTIuMHB0Jz48Zm9udA0Kc2l6 ZT0yIGNvbG9yPWJsYWNrIGZhY2U95a6L5L2TPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OuWui+S9kzsNCmNvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgZGlyPUxUUiBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYuMHB0O2xpbmUtaGVpZ2h0OjEyLjBw dCc+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPeWui+S9kz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZM7DQpjb2xvcjpibGFjazttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTic+QmVzdCByZWdhcmRzITxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBkaXI9TFRSIHN0eWxlPSdtYXJnaW4tbGVmdDozNi4w cHQnPjxmb250IHNpemU9MSBjb2xvcj1ibGFjaw0KZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsYWNrOw0KbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04nPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0xIGNvbG9yPWJs YWNrDQpmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6YmxhY2s7DQptc28tY29sb3ItYWx0OndpbmRvd3RleHQ7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04nPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0K DQo8SFI+PEZvbnQgZmFjZT1hcmlhbCBzaXplPTIgY29sb3I9YmxhY2s+PEk+DQpUaGlzIGUtbWFp bCBjb250YWlucyBjb25maWRlbnRpYWwsIHByaXZpbGVnZWQgb3IgcHJvcHJpZXRhcnkgDQppbmZv cm1hdGlvbiB0byBWb2NhbFRlYyBDb21tdW5pY2F0aW9ucy48QlI+DQpJZiB5b3UgcmVjZWl2ZWQg dGhpcyBtZXNzZWdlIGJ5IG1pc3Rha2UsIHBsZWFzZSBpbmZvcm0gdXMgDQphbmQgdGhlbiBkZWxl dGUgdGhlIG9yaWdpbmFsIGFuZCBhbGwgY29waWVzLjxCUj4NCjwvST48Qj4qKiogZVNhZmUgc2Nh bm5lZCB0aGlzIGVtYWlsIGZvciB2aXJ1c2VzLCB2YW5kYWxzLCANCmFuZCBtYWxpY2lvdXMgY29u dGVudC4gKioqPC9CPg0KPC9mb250PjxIUj4NCjwvYm9keT4NCg0KPC9odG1sPg0K ------_=_NextPart_001_01C6C751.9FDE5068-- --===============0533394745== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0533394745==-- From megaco-bounces@ietf.org Thu Aug 24 03:36:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG9kn-0002n7-Dk; Thu, 24 Aug 2006 03:35:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG9km-0002gW-92 for megaco@ietf.org; Thu, 24 Aug 2006 03:35:52 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG9kk-0004pq-4q for megaco@ietf.org; Thu, 24 Aug 2006 03:35:52 -0400 Received: from jaguar.hughesbpo.net (localhost [127.0.0.1]) by jaguar.hughesbpo.net (8.13.6/8.12.10) with ESMTP id k7O7bPed002779 for ; Thu, 24 Aug 2006 13:07:25 +0530 (IST) Received: from webmail.hss.hns.com (webmail.hss.hns.com [10.203.158.17]) by jaguar.hughesbpo.net (8.13.6/8.13.6) with ESMTP id k7O7bHES002648; Thu, 24 Aug 2006 13:07:25 +0530 (IST) Received: from Dlfmail1.hss.hns.com ([10.203.142.23]) by webmail.hss.hns.com (Lotus Domino Release 6.5.2) with ESMTP id 2006082413054410-38957 ; Thu, 24 Aug 2006 13:05:44 +0530 In-Reply-To: <000301c6c724$12522040$6291460a@china.huawei.com> To: Tony Zhang Subject: Re: [Megaco] Response should resend? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Sudhanshu Garg Date: Thu, 24 Aug 2006 11:25:28 +0530 X-MIMETrack: Serialize by Router on Dlfmail1/HSS(Release 6.5.2|June 01, 2004) at 08/24/2006 01:04:47 PM, Serialize complete at 08/24/2006 01:04:47 PM, Itemize by SMTP Server on WebMail/HSS(Release 6.5.2|June 01, 2004) at 08/24/2006 01:05:44 PM, Serialize by Router on WebMail/HSS(Release 6.5.2|June 01, 2004) at 08/24/2006 01:05:53 PM, Serialize complete at 08/24/2006 01:05:53 PM X-Spam-Score: 0.1 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1545676678==" Errors-To: megaco-bounces@ietf.org This is a multipart message in MIME format. --===============1545676678== Content-Type: multipart/alternative; boundary="=_alternative 00203AF3652571D4_=" This is a multipart message in MIME format. --=_alternative 00203AF3652571D4_= Content-Type: text/plain; charset="US-ASCII" Hi, There is no need to retransmit the response by itself as it is responsibility of requesting entity to provide suitable timeouts for all outstanding transactions. Reference: Section D.1.3 of H.248.1 Similar query was discussed earlier in the mailing list. May 2006: Baseroot v2 Use case query Regards, Sudhanshu. Technical Leader Flextronics Software Systems Phone: +91-124-4176301 extn 5109 Fax: +91-124-4300247 web: www.flextronicssoftware.com Tony Zhang 08/24/2006 07:51 AM To megaco@ietf.org cc Subject [Megaco] Response should resend? HI All: I have a question about Three-way handshake. If a response have been send, but the response entity do not received the response acknowledgement. Then, Is it necessary or possible or unnecessary that the response should be initiative resent by respond entity in Three-way handshake mode? Thanks. Best regards! _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco *********************** FSS-Restricted *********************** --=_alternative 00203AF3652571D4_= Content-Type: text/html; charset="US-ASCII"
Hi,

There is no need to retransmit the response by itself as
it is responsibility of requesting entity to provide
suitable timeouts for all outstanding transactions.
Reference: Section D.1.3 of H.248.1

Similar query was discussed earlier in the mailing list.
May 2006: Baseroot v2 Use case query

Regards,
Sudhanshu.
Technical Leader
Flextronics Software Systems
Phone:  +91-124-4176301 extn 5109
Fax: +91-124-4300247
web: www.flextronicssoftware.com


Tony Zhang <zhangtao_hw@huawei.com>

08/24/2006 07:51 AM

To
megaco@ietf.org
cc
Subject
[Megaco] Response should resend?





HI All:
    I have a question about  Three-way handshake. If a response have been send, but the response entity do not received the response acknowledgement. Then, Is it necessary or possible or unnecessary that the response should be initiative resent by respond entity in Three-way handshake mode? Thanks.
 
Best regards!
 _______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


***********************  FSS-Restricted   *********************** --=_alternative 00203AF3652571D4_=-- --===============1545676678== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1545676678==-- From megaco-bounces@ietf.org Fri Aug 25 05:39:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGY9U-0006lk-SZ; Fri, 25 Aug 2006 05:39:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGY9T-0006le-JZ for megaco@ietf.org; Fri, 25 Aug 2006 05:38:59 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGY9S-0008E5-Cw for megaco@ietf.org; Fri, 25 Aug 2006 05:38:59 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7P9cvg0026555 for ; Fri, 25 Aug 2006 12:38:57 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 12:38:57 +0300 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 12:38:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [Megaco] Encoding of ASN.1 SDP_equivalents (H.248.1 Annex C.11) for multiple a-lines Date: Fri, 25 Aug 2006 12:38:57 +0300 Message-ID: <3AF5D0CB9FA8D849ACB4CAF99C753BA7025CCC3A@esebe106.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Encoding of ASN.1 SDP_equivalents (H.248.1 Annex C.11) for multiple a-lines Thread-Index: AcbIKklHkXNRo3NLSDmW5T4+7c5XsQ== From: To: X-OriginalArrivalTime: 25 Aug 2006 09:38:56.0805 (UTC) FILETIME=[49260D50:01C6C82A] X-Spam-Score: 0.2 (/) X-Scan-Signature: a89bc6ca33b14646e47592488f7eaef6 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0371033403==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0371033403== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C82A.4910668D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C82A.4910668D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, 3GPP 29.332 specifies the usage of SDP_equivalents in H.248 interface for binary encoding. It specifies following in table 10.1: "Note For binary encoding, the SDP equivalents "SDP_V", "SDP_M", "SDP_C", "SDP_A", and SDP_B" in ITU-T Recommendation H.248.1 [9], Annex C.11, shall be used to encode the corresponding SDP lines. Other SDP equivalents may be used, for details see Annex A. The SDP equivalents shall be used in the order specified for the corresponding SDP lines in IETF RFC 2327 [17]. Rules for the usage of SDP in ITU-T Recommendation H.248.1 [9] shall also be applied to the SDP equivalents." ITU-T H.248.1 chapter 7.1.8. specifies "When binary encoding the protocol, the descriptor consists of groups of properties (tag-value pairs) as specified in Annex C. Each such group may contain the parameters of a session description." ITU-T H.248.8 specifies an error code if a property appears twice in a descriptor "4.2.34 Error code #: 456=20 Name: Property appears twice in this Descriptor Definition: The command, including the property, is not executed due to the parameter or property appearing twice in this descriptor. Error text in the error descriptor: The Property Name is included in the Error text in the error descriptor. Comment: - ITU-T H.248.1 Annex A specifies the usage of Property as follows: -- In PropertyParm, value is a SEQUENCE OF octet string. When sent=20 -- by an MGC the interpretation is as follows:=20 -- empty sequence means CHOOSE=20 -- one element sequence specifies value=20 -- If the sublist field is not selected, a longer sequence means =20 -- "choose one of the values" (i.e. value1 OR value2 OR ...)=20 -- If the sublist field is selected,=20 -- a sequence with more than one element encodes the value of a=20 -- list-valued property (i.e. value1 AND value2 AND ...). -- The relation field may only be selected if the value sequence=20 -- has length 1. It indicates that the MG has to choose a value=20 -- for the property. E.g., x > 3 (using the greaterThan=20 -- value for relation) instructs the MG to choose any value larger=20 -- than 3 for property x.=20 -- The range field may only be selected if the value sequence=20 -- has length 2. It indicates that the MG has to choose a value=20 -- in the range between the first octet in the value sequence and=20 -- the trailing octet in the value sequence, including the=20 -- boundary values.=20 -- When sent by the MG, only responses to an AuditCapability request=20 -- may contain multiple values, a range, or a relation field.=20 =20 PropertyParm ::=3D SEQUENCE =20 {=20 name PkgdName <\l > ,=20 value SEQUENCE OF OCTET STRING ,=20 extraInfo CHOICE =20 {=20 relation Relation <\l > ,=20 range BOOLEAN ,=20 sublist BOOLEAN =20 } OPTIONAL,=20 ...=20 }=20 Unfortunately these specification gives just a theoretical explanation about SDP equivalents usage for binary encoding regarding multiple SDP lines, there exists in general only text-encoding examples.=20 In following example binary encoding is depicted with help of ASN.1-syntax definitions and we'd like to have clarification=20 about detailed syntax how binary encoding should look like in case of using SDP_equivalents(H.248.1 Annex C). Basically the question is for ASN.1: What is the limit to decide when there is a question of one specific property.=20 Is the SDP_A tag a property or shall the MG dig out the value of SDP_A before it can determine/decide=20 that the question is about different parameters of a-line in SDP ? =20 So when ABNF SDP contains for example multiple a-lines, are they in ASN.1 encoded as separate values (a list) of one SDP_a=20 or shall we encode as many SDP_A properties as there are a-lines in ABNF SDP ? Following example illustrates the problem. In the example the used codecs are only examples of possible use case,=20 it is not relevant if this is codec modification or reservation, just the encoding principle is important. If the use case is for ABNF as follows Local { v=3D0 c=3DIN IP4 $ m=3Daudio $ RTP/AVP 96 97=20 a=3Drtpmap:96 iLBC/8000=20 a=3Dfmtp:96 mode=3D20=20 a=3Drtpmap:97 PCMU/8000 =20 a=3Dgpmd:97 vbd=3Dyes=20 } How should these a-lines look in ASN:1 ? 1.) LocalDescriptor{ ---cut--+ other mandatory parameters ---Cut-- PkgdName=3D0x000B00C /*SDP_A String Zero or more session attributes * / value=3D "rtpmap:96 iLBC/8000" ,=09 "fmtp: 96 mode=3D20", "rtpmap:97 PCMU/8000", =09 "gpmd: 97 vbd=3Dyes".=20 Or 2.) LocalDescriptor{ ---cut--+ other mandatory parameters ---Cut--- PkgdName=3D0x000B00C /*SDP_A String Zero or more session attributes * / value=3D "rtpmap:96 iLBC/8000" /*HEX*/ PkgdName=3D0x000B00C /*SDP_A String Zero or more session attributes * / value=3D "fmtp: 96 mode=3D20".=20 PkgdName=3D0x000B00C /*SDP_A String Zero or more session attributes * / value=3D "rtpmap:97 PCMU/8000" /*HEX*/ PkgdName=3D0x000B00C /*SDP_A String Zero or more session attributes * / value=3D "gpmd: 97 vbd=3Dyes" /*HEX*/=20 Or something else ? br manfred ------_=_NextPart_001_01C6C82A.4910668D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable [Megaco] Encoding of ASN.1 SDP_equivalents (H.248.1 Annex C.11) = for multiple a-lines

Hi,

3GPP 29.332 specifies = the usage of SDP_equivalents in H.248 interface for binary encoding. It = specifies following in table 10.1:

"Note   = For binary encoding, the SDP equivalents “SDP_V”, = “SDP_M”, “SDP_C”, “SDP_A”, and = SDP_B” in ITU-T Recommendation H.248.1 [9], Annex C.11, shall be = used to encode the corresponding SDP lines. Other SDP equivalents may be = used, for details see Annex A. The SDP equivalents shall be used in the = order specified for the corresponding SDP lines in IETF RFC 2327 [17]. = Rules for the usage of SDP in ITU-T Recommendation H.248.1 [9] shall = also be applied to the SDP equivalents."

ITU-T H.248.1 chapter 7.1.8. specifies
"When binary encoding the protocol, the = descriptor consists of groups of properties (tag-value pairs) as = specified in Annex C. Each such group may contain the parameters of a = session description."

ITU-T H.248.8 specifies an error code if a property = appears twice in a descriptor
"4.2.34 Error code #: 456

Name: Property appears twice in this Descriptor

Definition: The = command, including the property, is not executed due to the parameter or = property appearing twice in this descriptor.

Error text in the error descriptor: The Property Name is included in the Error text = in the error descriptor.

Comment: = –

ITU-T H.248.1 Annex A specifies the usage of Property as = follows:
   -- In PropertyParm, value is a SEQUENCE OF octet = string.  When sent
   -- by an MGC the interpretation is as = follows:
   -- empty sequence means CHOOSE =
   -- one element sequence specifies = value
   -- If the sublist field is not = selected, a longer sequence means 
   -- "choose one of the = values" (i.e. value1 OR value2 OR ...)
   -- If the sublist field is selected, =
   -- a sequence with more than one = element encodes the value of a
   -- list-valued property (i.e. value1 = AND value2 AND ...).
   -- The relation field may only be = selected if the value sequence
   -- has length 1.  It indicates = that the MG has to choose a value
   -- for the property. E.g., x > 3 = (using the greaterThan
   -- value for relation) instructs the = MG to choose any value larger
   -- than 3 for property x. =
   -- The range field may only be = selected if the value sequence
   -- has length 2.  It indicates = that the MG has to choose a value
   -- in the range between the first = octet in the value sequence and
   -- the trailing octet in the value = sequence, including the
   -- boundary values.
   -- When sent by the MG, only responses = to an AuditCapability request
   -- may contain multiple values, a = range, or a relation field. =
   
   PropertyParm ::=3D SEQUENCE
   {
        = name            = PkgdName,
        = value           = SEQUENCE OF OCTET = STRING,
        = extraInfo       CHOICE
           &n= bsp;    {
           &n= bsp;            = relation        Relation,
           &n= bsp;            = range           = BOOLEAN,
           &n= bsp;            = sublist         BOOLEAN
           &n= bsp;    = }            =             &= nbsp;         OPTIONAL, =
        ...
   }

Unfortunately these specification gives just a = theoretical explanation about SDP equivalents usage for binary = encoding
regarding multiple SDP lines, there exists in general = only text-encoding examples.
In following example binary encoding is depicted with = help of ASN.1-syntax definitions and we'd like to have clarification =

about detailed syntax how binary encoding should look = like in case of using SDP_equivalents(H.248.1 Annex C).

Basically the question is for ASN.1: What is the limit to = decide when there is a question of one specific property.
Is the SDP_A tag a property or shall the MG dig out the = value of SDP_A before it can determine/decide
that the question is about different parameters of a-line = in SDP ? 
So when ABNF SDP contains for example multiple a-lines, = are they in ASN.1 encoded as separate values (a list) of one SDP_a =

or shall we encode as many SDP_A properties as there are = a-lines in ABNF SDP ?

Following example illustrates the problem.
In the example the used codecs are only examples of = possible use case,
it is not relevant if this is codec modification or = reservation, just the encoding principle is important.
If the use case is for ABNF as follows

                = Local {

                v=3D0
                c=3DIN IP4 = $
                m=3Daudio $ = RTP/AVP 96 97
                a=3Drtpmap:96 iLBC/8000
                a=3Dfmtp:96 = mode=3D20
                a=3Drtpmap:97 PCMU/8000 
                a=3Dgpmd:97 = vbd=3Dyes

           = }
How should these a-lines look in ASN:1 ?
1.)

                LocalDescriptor{

                      ---cut--+ other mandatory parameters
                      ---Cut--
                      PkgdName=3D0x000B00C      /*SDP_A String = Zero or more session attributes * /
                            value=3D = "rtpmap:96 iLBC/8000" ,    =
                              =            =   "fmtp: 96 mode=3D20",
                                 =         "rtpmap:97 = PCMU/8000",

        =            =              =         =         =         =            = "gpmd: 97 = vbd=3Dyes".
Or 2.)

                LocalDescriptor{

                      ---cut--+ other mandatory parameters
                      ---Cut---

                  PkgdName=3D0x000B00C      /*SDP_A String = Zero or more session attributes * /
                        value=3D = "rtpmap:96 iLBC/8000" = /*HEX*/
                  PkgdName=3D0x000B00C      /*SDP_A String = Zero or more session attributes * /
                          value=3D "fmtp: 96 = mode=3D20".
                  PkgdName=3D0x000B00C      /*SDP_A String = Zero or more session attributes * /
                        value=3D = "rtpmap:97 PCMU/8000" = /*HEX*/
                  PkgdName=3D0x000B00C      /*SDP_A String = Zero or more session attributes * /

        =         =         =                    =    value=3D "gpmd: 97 vbd=3Dyes" /*HEX*/

Or something else ?

br manfred


------_=_NextPart_001_01C6C82A.4910668D-- --===============0371033403== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0371033403==-- From megaco-bounces@ietf.org Fri Aug 25 09:55:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGc96-000178-NJ; Fri, 25 Aug 2006 09:54:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGc95-000173-Kp for megaco@ietf.org; Fri, 25 Aug 2006 09:54:51 -0400 Received: from cluster1.bresnan.net ([69.145.248.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGc94-0008EK-AS for megaco@ietf.org; Fri, 25 Aug 2006 09:54:51 -0400 Received: from [72.174.194.202] (HELO [192.168.2.98]) by fe-2.cluster1.bresnan.net (CommuniGate Pro SMTP 5.0.9) with ESMTPS id 397513158; Fri, 25 Aug 2006 07:54:49 -0600 Subject: Re: [Megaco] Encoding of ASN.1 SDP_equivalents (H.248.1 Annex C.11) for multiple a-lines From: Terry Howe To: manfred.volz@nokia.com In-Reply-To: <3AF5D0CB9FA8D849ACB4CAF99C753BA7025CCC3A@esebe106.NOE.Nokia.com> References: <3AF5D0CB9FA8D849ACB4CAF99C753BA7025CCC3A@esebe106.NOE.Nokia.com> Content-Type: text/plain Organization: Jeeptech Publishing Date: Fri, 25 Aug 2006 07:54:42 -0600 Message-Id: <1156514082.2375.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: terry@jeeptech.com List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org I was under the impression that option 2 was correct. Of course there are going to be duplicate tags in the PropertyParm. That error message should only be used in the case where there is a duplicate value that is illegal such as two versions. It has been a long while since I looked at SDP in ASN.1 though. On Fri, 2006-08-25 at 12:38 +0300, manfred.volz@nokia.com wrote: > Or 2.) > > LocalDescriptor{ > > ---cut--+ other mandatory parameters > ---Cut--- > > > PkgdName=0x000B00C /*SDP_A String Zero or more session attributes * / > > value= > "rtpmap:96 iLBC/8000" /*HEX*/ > PkgdName=0x000B00C /*SDP_A String Zero or more session attributes * / > > value= > "fmtp: > 96 > mode=20". > PkgdName=0x000B00C /*SDP_A String Zero or more session attributes * / > > value= > "rtpmap:97 PCMU/8000" /*HEX*/ > PkgdName=0x000B00C /*SDP_A String Zero or more session attributes * / > > > value= "gpmd: 97 > vbd=yes" /*HEX*/ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Aug 25 12:08:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGeEg-0006uP-UI; Fri, 25 Aug 2006 12:08:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGeEg-0006uJ-6Z for Megaco@ietf.org; Fri, 25 Aug 2006 12:08:46 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGcwc-0002zl-8e for Megaco@ietf.org; Fri, 25 Aug 2006 10:46:02 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGcU8-0005ee-8T for Megaco@ietf.org; Fri, 25 Aug 2006 10:16:38 -0400 Received: by ug-out-1314.google.com with SMTP id m2so913422uge for ; Fri, 25 Aug 2006 07:16:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=WInZWB4xRTPHoy/JTRVIswO81pp/PVVroj89QXmaMwEVY/g9eRwgfh1Nh5gtqi0REnmyroAh9+3NwEZnt15u/bqtzhfbDI0Cub3jrpey9wjmjMhLV3ORETbEFOchoYlAxI73pPJCZA5rIPbv94nrgXrzHxPgWrJG7bOxRpPWkXY= Received: by 10.67.89.5 with SMTP id r5mr1882711ugl; Fri, 25 Aug 2006 07:16:34 -0700 (PDT) Received: by 10.66.250.2 with HTTP; Fri, 25 Aug 2006 07:16:34 -0700 (PDT) Message-ID: <1a9ac220608250716r4917e157p5b38ca227c54b226@mail.gmail.com> Date: Fri, 25 Aug 2006 11:16:34 -0300 From: "Nicolas Emiliani" To: Megaco@ietf.org MIME-Version: 1.0 X-Spam-Score: -0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [Megaco] ADD problem ERR 441 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0347874166==" Errors-To: megaco-bounces@ietf.org --===============0347874166== Content-Type: multipart/alternative; boundary="----=_Part_152625_11206537.1156515394757" ------=_Part_152625_11206537.1156515394757 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi.... I'm trying to do an add on a Ione AccessGateway with no luck, This is teh message : MEGACO/1 [192.168.0.187]:2944 Transaction=4{ Context=${Add=AGW215/1{Media{LocalControl{Mode=inactive}}}, Add=${Media{LocalControl{Mode=inactive},Local{ v=0 c=IN IP4 $ m=audio $ RTP/AVP 8 97 a=rtpmap:8 pcma/8000 a=rtpmap:97 telephone-event 0-15 }}}}} It's a pretty simple transaction but it is replying this : err=441 "missing RemoteDecriptor" I'm kind of lost, since this is an outgoing call I don't know the remote end, and this exact same package works with an Audioces trunkgateway. I tried adding the Stream clause but it didn't work either. Does anyone know what's going on? Thanks! ------=_Part_152625_11206537.1156515394757 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi.... I'm trying to do an add on a Ione AccessGateway with no luck, This is teh message :

 MEGACO/1 [192.168.0.187]:2944
    Transaction=4{
    Context=${Add=AGW215/1{Media{LocalControl{Mode=inactive}}},
    Add=${Media{LocalControl{Mode=inactive},Local{
    v=0
    c=IN IP4 $
    m=audio $ RTP/AVP 8 97
    a=rtpmap:8 pcma/8000
    a=rtpmap:97 telephone-event 0-15
    }}}}}


It's a pretty simple transaction but it is replying this :

err=441 "missing RemoteDecriptor"

I'm kind of lost, since this is an outgoing call I don't know the remote end, and this exact same package works with an Audioces trunkgateway.
I tried adding the Stream clause but it didn't work either.

Does anyone know what's going on?

Thanks!
------=_Part_152625_11206537.1156515394757-- --===============0347874166== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0347874166==-- From megaco-bounces@ietf.org Fri Aug 25 14:34:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGgVe-0008Ng-Of; Fri, 25 Aug 2006 14:34:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGgVd-0008NW-ET for Megaco@ietf.org; Fri, 25 Aug 2006 14:34:25 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGgVc-000185-43 for Megaco@ietf.org; Fri, 25 Aug 2006 14:34:25 -0400 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7PIYL611142 for ; Fri, 25 Aug 2006 14:34:21 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Megaco] ADD problem ERR 441 Date: Fri, 25 Aug 2006 14:34:18 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A3ABB58@zrtphxm2.corp.nortel.com> In-Reply-To: <1a9ac220608250716r4917e157p5b38ca227c54b226@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] ADD problem ERR 441 Thread-Index: AcbIYRfBnG+OqFvXRUG7EaTMsnPcbwAE6+KA From: "Kevin Boyle" To: "Nicolas Emiliani" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org It appears that the MG is demanding a Remote Descriptor in order to perform the add of the ephemeral termination. This is something you should take up with the manufacturer. Generally speaking, a Remote Descriptor shouldn't be necessary until the MGC attempts to set the termination to send only or send/receive. Kevin ________________________________ From: Nicolas Emiliani [mailto:or3st3s@gmail.com] Sent: Friday, August 25, 2006 10:17 AM To: Megaco@ietf.org Subject: [Megaco] ADD problem ERR 441 Hi.... I'm trying to do an add on a Ione AccessGateway with no luck, This is teh message : MEGACO/1 [192.168.0.187]:2944 Transaction=4{ Context=${Add=AGW215/1{Media{LocalControl{Mode=inactive}}}, Add=${Media{LocalControl{Mode=inactive},Local{ v=0 c=IN IP4 $ m=audio $ RTP/AVP 8 97 a=rtpmap:8 pcma/8000 a=rtpmap:97 telephone-event 0-15 }}}}} It's a pretty simple transaction but it is replying this : err=441 "missing RemoteDecriptor" I'm kind of lost, since this is an outgoing call I don't know the remote end, and this exact same package works with an Audioces trunkgateway. I tried adding the Stream clause but it didn't work either. Does anyone know what's going on? Thanks! _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Aug 28 04:12:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHcDd-0004FT-Ug; Mon, 28 Aug 2006 04:11:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHcDc-0004Af-Ie for Megaco@ietf.org; Mon, 28 Aug 2006 04:11:40 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHcDY-00020u-LT for Megaco@ietf.org; Mon, 28 Aug 2006 04:11:40 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4P00DTK8VPBJ@szxga02-in.huawei.com> for Megaco@ietf.org; Mon, 28 Aug 2006 16:28:38 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4P009O38VO6W@szxga02-in.huawei.com> for Megaco@ietf.org; Mon, 28 Aug 2006 16:28:37 +0800 (CST) Received: from z26452a ([10.70.145.98]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4P0044Q8M49X@szxml04-in.huawei.com> for Megaco@ietf.org; Mon, 28 Aug 2006 16:22:55 +0800 (CST) Date: Mon, 28 Aug 2006 16:10:37 +0800 From: Tony Zhang To: Megaco@ietf.org Message-id: <000301c6ca79$720bfe40$6291460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcbKeXHtQZBy+O56R36dvEtTte0SpQ== X-Spam-Score: 0.2 (/) X-Scan-Signature: c370643024a0bdfd1da2398fa8672689 Cc: Subject: [Megaco] H248 V3 segment question X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1125124696==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1125124696== Content-type: multipart/alternative; boundary="Boundary_(ID_BjqV1p4LEUv5KCdYShGQuA)" This is a multi-part message in MIME format. --Boundary_(ID_BjqV1p4LEUv5KCdYShGQuA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi: I have two questions about H248 V3 segment to ask. 1. If the segment receiver has received the first segment, then is it = necessary that the receiver should be start or restart a timer,if it = does,what is the length of the timer? 2. The receiver reply with Error Code 459 ("Segments not = received=E2=80=9D) like: !/3 [12.34.56.79]:2944 = SM=3D1{ER=3D459{"2,3"}},why do not reply like this: !/3 [12.34.56.79]:2944 P=3D1{ER=3D459{"2,3"}} ? Regards! Tony --Boundary_(ID_BjqV1p4LEUv5KCdYShGQuA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi:

I have two questions about H248 V3 segment to = ask.

1. If the segment receiver has = received the first segment, then is=C2=A0 it necessary that the receiver should be = start or restart a timer,if it does,what is the length of the = timer?

2. The receiver reply with Error Code = 459 ("Segments not received=E2=80=9D) like: !/3 [12.34.56.79]:2944 SM=3D1{ER=3D459{"2,3"}},why do not reply like = this:

=C2=A0=C2=A0=C2=A0 !/3 [12.34.56.79]:2944 P=3D1{ER=3D459{"2,3"}} ?<= /span>

Regards!

Tony=

--Boundary_(ID_BjqV1p4LEUv5KCdYShGQuA)-- --===============1125124696== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1125124696==-- From megaco-bounces@ietf.org Thu Aug 31 10:20:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GInPA-0001pE-CQ; Thu, 31 Aug 2006 10:20:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GInPA-0001p9-3I for Megaco@ietf.org; Thu, 31 Aug 2006 10:20:28 -0400 Received: from ilsmtp01.ecitele.com ([147.234.1.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GInP8-0001a2-Cz for Megaco@ietf.org; Thu, 31 Aug 2006 10:20:28 -0400 To: Megaco@ietf.org X-Mailer: Lotus Notes Release 6.5.3 September 14, 2004 Message-ID: From: Seraya.Miletzki@ecitele.com Date: Thu, 31 Aug 2006 17:20:24 +0300 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.3FP1 | December 22, 2004) at 08/31/2006 17:29:01 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Megaco] Error during Add Command X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hi all We see here the following : MGC sends ADD request to the MG : MEGACO/1 [xx.xx.xx.xx]:2944 T=369419463{C=${A=aaln/65{M{O{MO=IN,RV=OFF,RG=OFF}},E=370727168{tonedet/std{tl=*},al/*},SG{}},A=${M{O{MO=RC,RV=OFF,RG=OFF},L{v=0 c=IN IP4 $ m=audio $ RTP/AVP 8 a=ptime:20 }}}}} The MG does not support the tonedet package : What is the right behavior at this case : a. Send an error message without creating a context and not process the ADD request. b. Process the ADD request and add the termination to a context, with an error notification regarding the Unsupported Package. Thanks In Advance Seraya _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Aug 31 11:43:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIohC-0007AP-WE; Thu, 31 Aug 2006 11:43:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIohB-0007AH-1a for Megaco@ietf.org; Thu, 31 Aug 2006 11:43:09 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIoh9-0002tM-OH for Megaco@ietf.org; Thu, 31 Aug 2006 11:43:09 -0400 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7VFh5B23381 for ; Thu, 31 Aug 2006 11:43:05 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Megaco] Error during Add Command Date: Thu, 31 Aug 2006 11:42:47 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A52EA55@zrtphxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Error during Add Command Thread-Index: AcbNCQ6ILQxdNUs/TYmwf7T6tFxX3gACvDFg From: "Kevin Boyle" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org The command failed, therefore the context did not come into existence and the termination is still in NULL. Kevin -----Original Message----- From: Seraya.Miletzki@ecitele.com [mailto:Seraya.Miletzki@ecitele.com] Sent: Thursday, August 31, 2006 10:20 AM To: Megaco@ietf.org Subject: [Megaco] Error during Add Command Hi all We see here the following : MGC sends ADD request to the MG : MEGACO/1 [xx.xx.xx.xx]:2944 T=369419463{C=${A=aaln/65{M{O{MO=IN,RV=OFF,RG=OFF}},E=370727168{tonedet/ std{tl=*},al/*},SG{}},A=${M{O{MO=RC,RV=OFF,RG=OFF},L{v=0 c=IN IP4 $ m=audio $ RTP/AVP 8 a=ptime:20 }}}}} The MG does not support the tonedet package : What is the right behavior at this case : a. Send an error message without creating a context and not process the ADD request. b. Process the ADD request and add the termination to a context, with an error notification regarding the Unsupported Package. Thanks In Advance Seraya _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Aug 31 12:16:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIpDH-00033g-7k; Thu, 31 Aug 2006 12:16:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIpDF-0002zY-Ek for Megaco@ietf.org; Thu, 31 Aug 2006 12:16:18 -0400 Received: from py-out-1112.google.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIpDE-0006PK-4I for Megaco@ietf.org; Thu, 31 Aug 2006 12:16:17 -0400 Received: by py-out-1112.google.com with SMTP id e30so632877pya for ; Thu, 31 Aug 2006 09:16:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ua88nEGNFTEvm3+Ekb+cbs2SONSToG0LDwnlfhmq3DjvREJbGCjHMi79iVjjpvfpYTEMzEcDAqOFJERdKRrDFg8lXM+HbLqd2Dl9CbQMxQ/+RblLuXC1MHWWpTYuk1vxHywQNru6m1yfl9PCM5pcqjlopchjzl8lVv3k2J+MGHE= Received: by 10.35.83.6 with SMTP id k6mr1013950pyl; Thu, 31 Aug 2006 09:16:15 -0700 (PDT) Received: by 10.35.9.19 with HTTP; Thu, 31 Aug 2006 09:16:15 -0700 (PDT) Message-ID: Date: Thu, 31 Aug 2006 13:16:15 -0300 From: Wglastonio To: Seraya.Miletzki@ecitele.com Subject: Re: [Megaco] Error during Add Command In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA40A52EA55@zrtphxm2.corp.nortel.com> MIME-Version: 1.0 References: <34B3EAA5B3066A42914D28C5ECF5FEA40A52EA55@zrtphxm2.corp.nortel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1224171858==" Errors-To: megaco-bounces@ietf.org --===============1224171858== Content-Type: multipart/alternative; boundary="----=_Part_54413_27004193.1157040975510" ------=_Part_54413_27004193.1157040975510 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, Chapter 8 (Transactions) describes: "At the first failing command in a transaction, processing of the remaining commands in that transaction stops." Reg, Wg. 2006/8/31, Kevin Boyle : > > The command failed, therefore the context did not come into existence > and the termination is still in NULL. > > Kevin > > -----Original Message----- > From: Seraya.Miletzki@ecitele.com [mailto:Seraya.Miletzki@ecitele.com] > Sent: Thursday, August 31, 2006 10:20 AM > To: Megaco@ietf.org > Subject: [Megaco] Error during Add Command > > Hi all > > We see here the following : > > MGC sends ADD request to the MG : > > MEGACO/1 [xx.xx.xx.xx]:2944 > T=369419463{C=${A=aaln/65{M{O{MO=IN,RV=OFF,RG=OFF}},E=370727168{tonedet/ > std{tl=*},al/*},SG{}},A=${M{O{MO=RC,RV=OFF,RG=OFF},L{v=0 > c=IN IP4 $ > m=audio $ RTP/AVP 8 > a=ptime:20 > }}}}} > > The MG does not support the tonedet package : > What is the right behavior at this case : > > a. Send an error message without creating a context and not process the > ADD request. > b. Process the ADD request and add the termination to a context, with an > error notification regarding the Unsupported Package. > > > Thanks In Advance > > Seraya > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > ------=_Part_54413_27004193.1157040975510 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello,
Chapter 8 (Transactions) describes:
"At the first failing command in a transaction, processing of the remaining commands in that transaction stops."
 
Reg,
 
Wg.

 
2006/8/31, Kevin Boyle <kboyle@nortel.com>:
The command failed, therefore the context did not come into existence
and the termination is still in NULL.

Kevin

-----Original Message-----
From: Seraya.Miletzki@ecitele.com [mailto:Seraya.Miletzki@ecitele.com]
Sent: Thursday, August 31, 2006 10:20 AM
To: Megaco@ietf.org
Subject: [Megaco] Error during Add Command

Hi all

We see here the following :

MGC sends ADD request to the MG :

MEGACO/1 [xx.xx.xx.xx]:2944
T=369419463{C=${A=aaln/65{M{O{MO=IN,RV=OFF,RG=OFF}},E=370727168{tonedet/
std{tl=*},al/*},SG{}},A=${M{O{MO=RC,RV=OFF,RG=OFF},L{v=0
   c=IN IP4 $
   m=audio $ RTP/AVP 8
   a=ptime:20
   }}}}}

The MG does not support the tonedet package :
What is the right behavior at this case :

a.  Send an error message without creating a context and not process the
ADD request.
b. Process the ADD request and add the termination to a context, with an
error notification regarding the Unsupported Package.


Thanks In Advance

Seraya



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



------=_Part_54413_27004193.1157040975510-- --===============1224171858== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1224171858==-- From megaco-bounces@ietf.org Thu Aug 31 13:23:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIqGR-0007YZ-BN; Thu, 31 Aug 2006 13:23:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIqGQ-0007WP-5h for megaco@ietf.org; Thu, 31 Aug 2006 13:23:38 -0400 Received: from mail.tdsoft.com ([212.143.64.34] helo=vocaltec.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GIqGN-0003ne-Fk for megaco@ietf.org; Thu, 31 Aug 2006 13:23:38 -0400 Received: from mailserver.vocaltec.co.il ([172.16.1.203]) by eSafe SMTP Relay 1157001365; Thu, 31 Aug 2006 20:23:02 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 31 Aug 2006 20:24:06 +0200 Message-ID: <431F3BDE11BF2F42A22CBEFA36BD88A461D1EF@mailserver.vocaltec.local> In-Reply-To: <9E388C880C1ED411AFE1009027E7872506F32E37@sapphire.veraznet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Error code 435 Thread-Index: AcT4ruHR45PUMkdsSOWVB3Gh3NqCOnUeZL+A From: "Raphael Tryster" To: "Madhubabu Brahmanapally" , X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Subject: [Megaco] Who chooses circuit between TGW and SS7? X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2002657515==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============2002657515== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6CD2A.A49CA1FA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6CD2A.A49CA1FA Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I refer to draft-ietf-megaco-callflows-02.txt. In the section on a call = between SS7 trunk in TGW and RGW, the MGC receives in the IAM message the= identity of the circuit that the SS7 switch has chosen to be used for th= e call, translates this into a termination, and tells the TGW to use that= termination. I have no problem with this. =20 For a call in the opposite direction, the draft says that the MGC asks th= e TGW to choose a circuit. I would understand if the MGC then used the c= hosen circuit in the messages it send to SS7 to set up the call. However= , the draft says that these SS7 messages are exchanged BEFORE adding the = physical termination. How can this work? There doesn't seem to be anyth= ing ensuring that SS7 and TGW will use the same circuit. =20 Raphael Tryster *************************************************************************= ********************* This e-mail contains confidential, privileged or proprietary information = to VocalTec Communications. If you received this messege by mistake, please inform us and then delete= the original and all copies. *** eSafe scanned this email for viruses, vandals, and malicious content.= *** *************************************************************************= ********************* ------_=_NextPart_001_01C6CD2A.A49CA1FA Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Error code 435
I=20 refer to draft-ietf-megaco-callflows-02.txt.  In the section on a ca= ll=20 between SS7 trunk in TGW and RGW, the MGC receives in the IAM message the= =20 identity of the circuit that the SS7 switch has chosen to be used for the= call,=20 translates this into a termination, and tells the TGW to use that=20 termination.  I have no problem with this.
 
For a=20 call in the opposite direction, the draft says that the MGC asks the TGW = to=20 choose a circuit.  I would understand if the MGC then used the chose= n=20 circuit in the messages it send to SS7 to set up the call.  However,= the=20 draft says that these SS7 messages are exchanged BEFORE adding the physic= al=20 termination.  How can this work?  There doesn't seem to be anyt= hing=20 ensuring that SS7 and TGW will use the same circuit.
 
Raphael Tryster
This e-mail contains confidential, privileged or proprietary=20 information to VocalTec Communications.
If you received this messege by mistake, please inform us=20 and then delete the original and all copies.
*** eSafe scanned this email for viruses, vandals,=20 and malicious content. ***
------_=_NextPart_001_01C6CD2A.A49CA1FA-- --===============2002657515== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============2002657515==-- From megaco-bounces@ietf.org Thu Aug 31 14:52:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIrdm-0003ns-Cp; Thu, 31 Aug 2006 14:51:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIrdl-0003nk-44 for megaco@ietf.org; Thu, 31 Aug 2006 14:51:49 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIqk6-0006yO-BF for megaco@ietf.org; Thu, 31 Aug 2006 13:54:18 -0400 Received: from global.mvnhost.com ([66.45.251.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIqZb-0004q5-HL for megaco@ietf.org; Thu, 31 Aug 2006 13:43:29 -0400 Received: from cpanel by global.mvnhost.com with local (Exim 4.52) id 1GIqZV-0003MD-1d for megaco@ietf.org; Thu, 31 Aug 2006 13:43:21 -0400 Received: from 67.40.58.132 ([67.40.58.132]) by www.jeeptech.com (Horde MIME library) with HTTP; Thu, 31 Aug 2006 11:43:20 -0600 Message-ID: <20060831114320.jcxjqejt23kkkk4c@www.jeeptech.com> Date: Thu, 31 Aug 2006 11:43:20 -0600 From: Terry L Howe To: megaco@ietf.org Subject: Re: [Megaco] Who chooses circuit between TGW and SS7? References: <431F3BDE11BF2F42A22CBEFA36BD88A461D1EF@mailserver.vocaltec.local> In-Reply-To: <431F3BDE11BF2F42A22CBEFA36BD88A461D1EF@mailserver.vocaltec.local> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.1) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - global.mvnhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32001 500] / [47 12] X-AntiAbuse: Sender Address Domain - jeeptech.com X-Source: /usr/local/cpanel/3rdparty/bin/php X-Source-Args: /usr/local/cpanel/3rdparty/bin/php /usr/local/cpanel/base/horde/imp/compose.php X-Source-Dir: :/base/horde/imp X-Spam-Score: -2.6 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org The TGW is bearer only, SS7 should determine the CIC, it is signaling. Quoting Raphael Tryster : > I refer to draft-ietf-megaco-callflows-02.txt. In the section on a =20 > call between SS7 trunk in TGW and RGW, the MGC receives in the IAM =20 > message the identity of the circuit that the SS7 switch has chosen =20 > to be used for the call, translates this into a termination, and =20 > tells the TGW to use that termination. I have no problem with this. > > For a call in the opposite direction, the draft says that the MGC =20 > asks the TGW to choose a circuit. I would understand if the MGC =20 > then used the chosen circuit in the messages it send to SS7 to set =20 > up the call. However, the draft says that these SS7 messages are =20 > exchanged BEFORE adding the physical termination. How can this =20 > work? There doesn't seem to be anything ensuring that SS7 and TGW =20 > will use the same circuit. > > Raphael Tryster > **************************************************************************= ******************** > This e-mail contains confidential, privileged or proprietary =20 > information to VocalTec Communications. > If you received this messege by mistake, please inform us and then =20 > delete the original and all copies. > *** eSafe scanned this email for viruses, vandals, and malicious content. = *** > **************************************************************************= ******************** --=20 Terry L Howe terry@jeeptech.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Aug 31 15:04:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIrqK-0003WJ-10; Thu, 31 Aug 2006 15:04:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIrqI-0003WE-Gn for megaco@ietf.org; Thu, 31 Aug 2006 15:04:46 -0400 Received: from mail.tdsoft.com ([212.143.64.34] helo=vocaltec.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GIrqG-0003hD-Tz for megaco@ietf.org; Thu, 31 Aug 2006 15:04:46 -0400 Received: from mailserver.vocaltec.co.il ([172.16.1.203]) by eSafe SMTP Relay 1157001365; Thu, 31 Aug 2006 22:04:14 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] Who chooses circuit between TGW and SS7? Date: Thu, 31 Aug 2006 22:05:18 +0200 Message-ID: <431F3BDE11BF2F42A22CBEFA36BD88A461D1F0@mailserver.vocaltec.local> In-Reply-To: <20060831114320.jcxjqejt23kkkk4c@www.jeeptech.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Who chooses circuit between TGW and SS7? Thread-Index: AcbNN1jr816dLJfWSa2flW5hnM9+9wAAV2ZA From: "Raphael Tryster" To: "Terry L Howe" , X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Does that mean the call flows document is wrong? =20 Raphael Tryster -----Original Message----- From: Terry L Howe [mailto:terry@jeeptech.com] Sent: Thursday, August 31, 2006 7:43 PM To: megaco@ietf.org Subject: Re: [Megaco] Who chooses circuit between TGW and SS7? The TGW is bearer only, SS7 should determine the CIC, it is signaling. Quoting Raphael Tryster : > I refer to draft-ietf-megaco-callflows-02.txt. In the section on a =20 > call between SS7 trunk in TGW and RGW, the MGC receives in the IAM =20 > message the identity of the circuit that the SS7 switch has chosen =20 > to be used for the call, translates this into a termination, and =20 > tells the TGW to use that termination. I have no problem with this. > > For a call in the opposite direction, the draft says that the MGC =20 > asks the TGW to choose a circuit. I would understand if the MGC =20 > then used the chosen circuit in the messages it send to SS7 to set =20 > up the call. However, the draft says that these SS7 messages are =20 > exchanged BEFORE adding the physical termination. How can this =20 > work? There doesn't seem to be anything ensuring that SS7 and TGW =20 > will use the same circuit. > > Raphael Tryster > ***********************************************************************= *********************** > This e-mail contains confidential, privileged or proprietary =20 > information to VocalTec Communications. > If you received this messege by mistake, please inform us and then =20 > delete the original and all copies. > *** eSafe scanned this email for viruses, vandals, and malicious conten= t. *** > ***********************************************************************= *********************** --=20 Terry L Howe terry@jeeptech.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco *************************************************************************= ********************* This e-mail contains confidential, privileged or proprietary information = to VocalTec Communications. If you received this messege by mistake, please inform us and then delete= the original and all copies. *** eSafe scanned this email for viruses, vandals, and malicious content.= *** *************************************************************************= ********************* _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Aug 31 16:41:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GItLc-0003sx-1G; Thu, 31 Aug 2006 16:41:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GItIh-0002X6-Hs for megaco@ietf.org; Thu, 31 Aug 2006 16:38:11 -0400 Received: from global.mvnhost.com ([66.45.251.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GItB6-0008SP-VX for megaco@ietf.org; Thu, 31 Aug 2006 16:30:22 -0400 Received: from cpanel by global.mvnhost.com with local (Exim 4.52) id 1GItB4-00047p-Fi; Thu, 31 Aug 2006 16:30:18 -0400 Received: from 67.40.58.132 ([67.40.58.132]) by www.jeeptech.com (Horde MIME library) with HTTP; Thu, 31 Aug 2006 14:30:18 -0600 Message-ID: <20060831143018.fjkgyothd3go8ckc@www.jeeptech.com> Date: Thu, 31 Aug 2006 14:30:18 -0600 From: Terry L Howe To: Raphael Tryster Subject: RE: [Megaco] Who chooses circuit between TGW and SS7? References: <431F3BDE11BF2F42A22CBEFA36BD88A461D1F0@mailserver.vocaltec.local> In-Reply-To: <431F3BDE11BF2F42A22CBEFA36BD88A461D1F0@mailserver.vocaltec.local> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.1) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - global.mvnhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32001 500] / [47 12] X-AntiAbuse: Sender Address Domain - jeeptech.com X-Source: /usr/local/cpanel/3rdparty/bin/php X-Source-Args: /usr/local/cpanel/3rdparty/bin/php /usr/local/cpanel/base/horde/imp/compose.php X-Source-Dir: :/base/horde/imp X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org I guess it gets down to a design decision. In theory, you could have a TGW make routing decisions, but it doesn't seem like a good place to make that decision to me. I would think someone else would make that decision and the TGW would just blindly set up connections and keep some DSPs busy. The implementations I've worked on have used more centralized routing. Quoting Raphael Tryster : > Does that mean the call flows document is wrong? > > Raphael Tryster > > -----Original Message----- > From: Terry L Howe [mailto:terry@jeeptech.com] > Sent: Thursday, August 31, 2006 7:43 PM > To: megaco@ietf.org > Subject: Re: [Megaco] Who chooses circuit between TGW and SS7? > > > > > The TGW is bearer only, SS7 should determine the CIC, it is signaling. > > > Quoting Raphael Tryster : > >> I refer to draft-ietf-megaco-callflows-02.txt. In the section on a >> call between SS7 trunk in TGW and RGW, the MGC receives in the IAM >> message the identity of the circuit that the SS7 switch has chosen >> to be used for the call, translates this into a termination, and >> tells the TGW to use that termination. I have no problem with this. >> >> For a call in the opposite direction, the draft says that the MGC >> asks the TGW to choose a circuit. I would understand if the MGC >> then used the chosen circuit in the messages it send to SS7 to set >> up the call. However, the draft says that these SS7 messages are >> exchanged BEFORE adding the physical termination. How can this >> work? There doesn't seem to be anything ensuring that SS7 and TGW >> will use the same circuit. >> >> Raphael Tryster >> *************************************************************************= ********************* >> This e-mail contains confidential, privileged or proprietary >> information to VocalTec Communications. >> If you received this messege by mistake, please inform us and then >> delete the original and all copies. >> *** eSafe scanned this email for viruses, vandals, and malicious =20 >> content. *** >> *************************************************************************= ********************* > > > > -- > Terry L Howe > terry@jeeptech.com > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > **************************************************************************= ******************** > This e-mail contains confidential, privileged or proprietary =20 > information to VocalTec Communications. > If you received this messege by mistake, please inform us and then =20 > delete the original and all copies. > *** eSafe scanned this email for viruses, vandals, and malicious content. = *** > **************************************************************************= ******************** > > --=20 Terry L Howe terry@jeeptech.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco