Subject: Re: [Megaco] V3 question - ServiceChangeIncompleteFlag as extension parameter

From: Dan Stettiner <[email-masked]>
Date: Sun, 6 May 2007 05:37:18 -0700 (PDT)

Hi All,

   Thank you for your answers.

   As you wrote 7.2.1.8 ov V3 defins 
                       X-SC = 1* (NAME EQUAL paramValue [COMMA])

   it is still not clear what is "paramvalue"  ,  I don't find such
definition 
   could it be a mistake and actually was supposed to be "parmvalue" ?

   I also wonder about what Christian suggested , saying the parameter
should be X-SC=SIC=ON
  Does this mean that a meesage as this one is legal? 

MEGACO/1 [10.4.4.176]:2944
T=32545{

   C = - {
               SC=ROOT{SV{ MT=RS,AD = 2944,V=3,PF=TGW/1,   RE="901 MG Cold
Boot",  X-SC=SIC=ON

}}}

 As far as I found version 1 parser will fail on the parameter with 2 EQUAL
signs

     best regards

Dani

Christian Groves-2 wrote:
> 
> Yes it could be cleaned up to ensure the comma is included. Something 
> for the IG and/or H.248.1v4.
> 
> Christian
> 
> Tom-PT Taylor wrote:
>> That ABNF doesn't look right. Making the comma optional means that if 
>> it omitted, you have the paramValue potentially concatenated with a 
>> succeeding NAME.
>>
>> Christian Groves wrote:
>>> Hello Dani,
>>>
>>> You need to look at 7.2.8.1.8 ExtensionParameter for the encoding. 
>>> e.g. The structure of the value is defined
>>> by the following ABNF: X-SC = 1* (NAME EQUAL paramValue [COMMA])
>>>
>>> The above structure replaced the "parmValue" component of the H.248.1 
>>> Annex B ABNF (
>>> extension = extensionParameter parmValue).
>>>
>>> So the exact encoded form would be:
>>> X-SC=SIC=ON
>>>
>>> Regards, Christian
>>>
>>> Dani Stettiner wrote:
>>>> Hi All ,
>>>>
>>>> Section “*7.2.8.1.10 ServiceChangeIncompleteFlag” *says (among other 
>>>> things)
>>>>
>>>> “When this flag is sent in an initial ServiceChange (H.248.1 Version 1)
>>>>
>>>> Command using the ServiceChange extension parameter "X-SC" the 
>>>> following is used:
>>>>
>>>> *Name*: SIC
>>>>
>>>> *Type*: Boolean
>>>>
>>>> *Possible values*: ON: Flag included
>>>>
>>>> NOTE – The value OFF is not required as subsequent commands will be 
>>>> H.248.1 Version 3 encoded.”
>>>>
>>>> What is the exact form of this parameter (in ABNF) when given as 
>>>> extension in the first message?
>>>>
>>>> Would it be *X-SCSIC=ON?*
>>>>
>>>> MEGACO/1 [10.4.4.176]:2944
>>>>
>>>> T=32545{
>>>>
>>>> C = - {
>>>>
>>>> SC=ROOT{SV{ MT=RS,AD = 2944,V=3,PF=TGW/1, RE="901 MG Cold Boot",
>>>>
>>>> * X-SCSIC=ON*
>>>>
>>>> }}}
>>>>
>>>> thanks
>>>>
>>>> //Dan Stettiner///
>>>> ///Software Engineer, R&D//
>>>> //H.248/MEGACO ///
>>>>
>>>> /Audiocodes
>>>> Email: [email-masked] 
>>>> <mailto:[email-masked]>
>>>> Tel. +972-3-9764415
>>>> www.audiocodes.com 
>>>> <http://www.audiocodes.com/ohttp:/www.audiocodes.com/>
>>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>> _______________________________________________
>>>> Megaco mailing list
>>>> [email-masked]
>>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>>   
>>>
>>>
>>> _______________________________________________
>>> Megaco mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>
>>
>>
>>
>>
> 
> 
> 
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
> 
> 

-- 
View this message in context: http://www.nabble.com/V3-question---ServiceChangeIncompleteFlag-as-extension-parameter-tf3600899.html#a10345098
Sent from the IETF - Megaco mailing list archive at Nabble.com.

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

---

From: "Raphael Tryster" <[email-masked]>
Date: Sun, 6 May 2007 16:50:47 +0200

>From H.248.1 section 7.1.8:

A Stream Descriptor specifies a single bidirectional media stream and so
a single session description must not include more than one media
description ("m = " line). A Stream Descriptor may contain additional
session descriptions as alternatives. Each media stream for a
termination
must appear in distinct Stream Descriptors.

Premise:

The above paragraph refers to 4 entities, which I understand as follows
-

A "Stream Descriptor" is described in Megaco syntax in the form 
Stream = x {...}.

A "session description" is a group of lines of SDP beginning with v=0,
and not containing any other v= lines.
  
A "media description" is a group of lines of SDP beginning with m=...,
and not containing any other m= lines.

A "media stream" cannot be the same as a media description.  The text
says that there cannot be more than one media stream in a stream
descriptor, but it implies that there can be more than one media
description in a stream descriptor, using multiple session descriptions.

Conclusion:

A single media stream may include more than one media description.  This
was not always obvious, as in a discussion in 2002, Tom Taylor
speculated whether an audio stream that transitions to image type on
detecting a fax should be defined as separate audio and image streams.
Apparently, the consensus was not to do this, but to group alternative
media types in the same stream.  By contrast, simultaneous audio and
video would need separate stream descriptors.

Essence:

I am wondering about the essential and invariant properties of a stream.
Per the fax example above, it doesn't make sense to refer to a stream as
an audio or image or video stream, because this can change dynamically.
So can the transport port, or perhaps even the IP address.  A stream
doesn't have to have SDP on its first appearance, as in the examples in
H.248.1, where Stream 1 is initially assigned values only for gain and
echo cancellation.  Can this be taken as a hint that it will be an audio
stream?  Or is it more correct to think of a stream definition as a
blank sheet on which anything can be written and erased, and there is
nothing invariant?  To take an extreme and rather silly example, could
an MGC initially set up stream 1 to be audio and stream 2 to be video,
and then switch them in mid-call?  These are admittedly somewhat
philosophical questions, but I am asking them here because Jean-Paul
Sartre is dead and they do have an impact on optimum software
implementation.
 
Raphael Tryster

"Mrs Essence flushed hers down the loo".

---

From: Christian Groves <[email-masked]>
Date: Mon, 07 May 2007 12:39:04 +1000

Hello Dan,

The "paramvalue" is a typo and should be parmvalue. Something for the IG.

"SIC=ON" is a valid value according the VALUE construct although you 
have to use the quoted string form. e.g. " " so strictly I should have 
written X-SC="SIC=ON". So the V1 parser was correct choking on 
non-quotedstring form but shouldn't choke on the quoted string form.

Regards, christian

---

From: Christian Groves <[email-masked]>
Date: Mon, 07 May 2007 13:11:30 +1000

Hello Raphael,

Isn't there some guy in the US that has a TV program where he talks to 
the dead? He'd probably be more of a help cause I'm no Satre...

I don't know how to answer this so i'll just describe my thoughts on 
streams. A H.248 stream is an abstract construct to describe the flow of 
data related to a single media. This is why we can have several 
media/session descriptions in a stream but only one of these is active 
at any particular time. So in theory it is a blank sheet. However in 
practice the stream behaviour is driven by the MGC, so it may be more 
correct to look at its behaviour.

In your example of gain and echo. The MGC would set this based on some 
call control stimulus. These may indicate audio and a MG could take its 
chances to reserve audio resources. The chances may be good because it 
would be strange to suddenly change this stream id to video. Chances 
would be better if the MGC indicated audio or the appropriate capability 
when it added the termination. On the extreme example, I think it would 
be silly behaviour for the MGC however theoretically it is possible.

As you may have seen from the last meeting we've started a work item to 
look at resource reservation (no baseline draft yet). This was triggered 
by a contribution that requested a codepoint to indicate that a 
termination represented a conference participant who was only ever going 
to be a listening termination. This would allow the MG to optimise 
resources. The question that came up was how could the MGC be 100% sure 
this was the case? What would happen if the MGC tried to change this 
later in the life of the termination? As H.248 is a master slave 
relationship what would the MG do?

So I don't know if this has given any answers, I think this resource 
topic has some more discussion left in it.

Regards, Christian