Subject: RE: [Megaco] Question about RTP payloadtype

From: "Raphael Tryster" <[email-masked]>
Date: Thu, 6 Sep 2007 14:24:55 +0300

This is a continuation of a thread that I started a few days ago, but
the exchange below from 5 years ago is somewhat relevant, as it
establishes that the rtppltype parameter of rtp/pltrans does not refer
to Rx/Tx.  My question is then, what is the meaning of rtppltype being
of type sublist of enumeration?  Syntactically, I assume this means
something like

ObservedEvents = 1111 { 20070906T141539 : rtp/pltrans { rtppltype =
[g723, g729] } }

But what does it mean semantically?  How could it happen that two
payload type transitions are reported in the same notification?

If all but the last payload type in the list is being reported with a
delay, what is the mechanism by which this delayed reporting is
engineered?  Is there a way that the MGC could request buffering of such
events, and then have them all reported at once by requesting that
ObservedEvents be included in the reply to Subtract?

Raphael Tryster

________________________________

From: Terry L Anderson [mailto:[email-masked]] 
Sent: Tuesday, October 29, 2002 8:55 PM
To: Christian Groves
Cc: Seunghan Choi; [email-masked]
Subject: Re: [Megaco] Question about RTP payloadtype

Agreed.  We would need to bump the version of the package.  Perhaps we
should add a note to rtp v1 and add a parameter to rtp v2

Christian Groves wrote:

G'Day,
 
The assumption behind E.12 was that the payload was symmetrical. We
could add a
note stating this but I believe the additional of an extra parameter is
beyond
an IG item. There no way to add an extra parameter to an event and
maintain
backward compatibility, it would have to be a new event.
 
Regards,  Christian
 
That is a very good issue. There is no parameter in the current event
notice to indicate which of the two payloads changed. While many use
symmetric payload types this is certainly not a requirement. I suppose
we should consider adding a parameter of enumeration type with values of
send, recv, sendRecv to include with the notice.
 
Kevin Boyle is our new Implementors Guide editor (as of the end of the
SG16 meeting today, I am handing over the editorship rather than do that
as well as rapporteur). Kevin can propose a fix for discussion on the
list.
 
Seunghan Choi wrote:

	Hi, All.
	 
	Is there the case that RTPpayload type(Rx CodecType) in
localDescriptor and RTPpayload type(Tx CodecType) in remoteDescriptor is
different?
	If there is that case, Which does the rtppltype mean, Rx
CodecType or Tx CodecType, in E.12 Payload Transition?
	 
	Thanks.

  

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

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Thu, 6 Sep 2007 15:25:44 +0200

rtp/pltrans is an event, thus for the Rx flow only ("the semantic is not
explicitly extended on the Tx flow as well, as e.g. done in H.248.40").
Right?
 
If my understanding is correct, the the semantic means RTP payload type
changes just of the remote RTP endpoint.
 
Guess your rtppltype list is correct.
 
-Albrecht

	From: Raphael Tryster [mailto:[email-masked]] 
	Sent: Donnerstag, 6. September 2007 13:25
	To: Christian Groves
	Cc: [email-masked]
	Subject: RE: [Megaco] Question about RTP payloadtype

	This is a continuation of a thread that I started a few days
ago, but the exchange below from 5 years ago is somewhat relevant, as it
establishes that the rtppltype parameter of rtp/pltrans does not refer
to Rx/Tx.  My question is then, what is the meaning of rtppltype being
of type sublist of enumeration?  Syntactically, I assume this means
something like

	ObservedEvents = 1111 { 20070906T141539 : rtp/pltrans {
rtppltype = [g723, g729] } }

	But what does it mean semantically?  How could it happen that
two payload type transitions are reported in the same notification?

	If all but the last payload type in the list is being reported
with a delay, what is the mechanism by which this delayed reporting is
engineered?  Is there a way that the MGC could request buffering of such
events, and then have them all reported at once by requesting that
ObservedEvents be included in the reply to Subtract?

	Raphael Tryster

	Agreed.  We would need to bump the version of the package.
Perhaps we should add a note to rtp v1 and add a parameter to rtp v2
	
	Christian Groves wrote:

	G'Day,
	 
	The assumption behind E.12 was that the payload was symmetrical.
We could add a
	note stating this but I believe the additional of an extra
parameter is beyond
	an IG item. There no way to add an extra parameter to an event
and maintain
	backward compatibility, it would have to be a new event.
	 
	Regards,  Christian
	 
	That is a very good issue. There is no parameter in the current
event
	notice to indicate which of the two payloads changed. While many
use
	symmetric payload types this is certainly not a requirement. I
suppose
	we should consider adding a parameter of enumeration type with
values of
	send, recv, sendRecv to include with the notice.
	 
	Kevin Boyle is our new Implementors Guide editor (as of the end
of the
	SG16 meeting today, I am handing over the editorship rather than
do that
	as well as rapporteur). Kevin can propose a fix for discussion
on the list.
	 
	Seunghan Choi wrote:

		Hi, All.

		Thanks.

---

From: "Raphael Tryster" <[email-masked]>
Date: Thu, 6 Sep 2007 16:39:31 +0300

Albrecht,

What you wrote clarifies the discussion of 5 years ago, but I am still
puzzled why a list and not a single value.  Clearly, the RTP payload
cannot change to multiple different values at the same time.  That
suggests that changes that occurred at different times are being
reported together, and I am wondering how this would be done.

Raphael Tryster 

From: Schwarz Albrecht [mailto:[email-masked]] 
Sent: Thursday, September 06, 2007 4:26 PM
To: Raphael Tryster; Christian Groves
Cc: [email-masked]
Subject: RE: [Megaco] Question about RTP payloadtype

-Albrecht

	Raphael Tryster

	
	Christian Groves wrote:

	G'Day,

	Regards,  Christian

	 
	Seunghan Choi wrote:

		Hi, All.

		Thanks.

---

From: "Stephen Mell (CV/ETL)" <[email-masked]>
Date: Thu, 6 Sep 2007 17:38:28 +0200

Raphael,
 
Perhaps this multiple payload type would be used when transiting to a
compression codec which supplemeted by non-periodic packets with a
different payload type - for example RFC2833 Out-Of-Band RTP events or
VAD packets for the purposes of comfort noise generation, these will
always use a different payload type to the periodic compression codec.
 
By the time that the Rx media handling engine has detected the change in
codec (received at least N periodic packets of the new compressed codec)
and wishes to report it, there is a slim chance that some of the
non-periodic (supplementary) packets have also been received as well, so
the MG may report Received periodic and non-periodic codec types in the
pltrans event
 
Does that sound feasible?
 
Steve 

From: Raphael Tryster [mailto:[email-masked]] 
Sent: 06 September 2007 14:40
To: Schwarz Albrecht; Christian Groves
Cc: [email-masked]
Subject: RE: [Megaco] Question about RTP payloadtype

Albrecht,

Raphael Tryster 

-Albrecht

	Raphael Tryster

	
	Christian Groves wrote:

	G'Day,

	Regards,  Christian

	 
	Seunghan Choi wrote:

		Hi, All.

		Thanks.

---

From: "Raphael Tryster" <[email-masked]>
Date: Thu, 6 Sep 2007 19:18:50 +0300

Steve,

It doesn't sound plausible to me, because:

1.       If things like VAD or RFC2833 were intended to be included in
reports of a periodic payload transition, then it stands to reason that
they should also be reported when there is no periodic payload
transition.  That could produce a barrage of notifications, and I doubt
that is what the designers of rtp/pltrans had in mind.

2.       If you ask me to deliver an envelope to someone outside the
office, then while I am getting ready to leave the office you can add
things that you remember at the last minute.  That's because I am human
and not a computer (some people dispute that).  Computer programs
generally have "left the office" as soon as they get a job to do, and
would have to be complicated considerably to provide the kind of
functionality you suggest.

So, unless one of the authors informs us otherwise, I'm betting they had
something else in mind.

Raphael Tryster

From: Stephen Mell (CV/ETL) [mailto:[email-masked]] 
Sent: Thursday, September 06, 2007 6:38 PM
To: Raphael Tryster
Cc: Schwarz Albrecht; Christian Groves; [email-masked]
Subject: RE: [Megaco] Question about RTP payloadtype

Raphael,

Steve 

Albrecht,

Raphael Tryster 

-Albrecht

	Raphael Tryster

	
	Christian Groves wrote:

	G'Day,

	Regards,  Christian

	 
	Seunghan Choi wrote:

		Hi, All.

		Thanks.

---

From: Christian Groves <[email-masked]>
Date: Fri, 07 Sep 2007 12:38:03 +1000

Hello Raphael,

I believe that having the rtp/pltrans as a list of was to account for 
the case where an event was set and the MG detected a change in codec in 
both the send and receive directions. Events sit at a level higher than 
the local/remote descriptors so in theory it covers both. The list of 
allowed the notification of both directions to be signalled, e.g. able 
to notify when a change in codec on the received stream, able to notify 
when a MG autonomously decides to change the codec sent. I suspect that 
there wasn't more thought on specific use cases when it was added.

The thread you pointed to highlights the issue but it seems that the 
note proposed back then didn't make it into an implementor's guide 
proposal. If we now add something to the IG then we need to agree on:
a) what a single value in the list means
b) what 2 values in the list means
c) can there be more than 2?

Some initial thoughts:
On a) Does a single value mean a codec change in both the send/receive 
direction (symmetrical change) or only the receive direction?
On b) I think we could easily say that the first value is the local 
value, the second is the remote
On c) I can't see a case for three so we may be able to limit the list 
size to 2.

I tried to find where the text originated to see if this could provide 
some more information. It seems it came from the period between the 
November 1999 Washington IETF meeting and the Feb 2000 ITU. However I 
can't find any email/contribution actually proposing it.

Regards, Christian

PS: Raphael, you need to update your address book I haven't worked 
Ericsson for some time now :-).

Raphael Tryster wrote:
>
> Steve,
>
> It doesn’t sound plausible to me, because:
>
> reports of a periodic payload transition, then it stands to reason 
> that they should also be reported when there is no periodic payload 
> 2. If you ask me to deliver an envelope to someone outside the office, 
> then while I am getting ready to leave the office you can add things 
> that you remember at the last minute. That’s because I am human and 
> not a computer (some people dispute that). Computer programs generally 
> have “left the office” as soon as they get a job to do, and would have 
> to be complicated considerably to provide the kind of functionality 
> you suggest.
>
> So, unless one of the authors informs us otherwise, I’m betting they 
> had something else in mind.
>
> Raphael Tryster
>
> ------------------------------------------------------------------------
>
> *From:* Stephen Mell (CV/ETL) [mailto:[email-masked]]
> *Sent:* Thursday, September 06, 2007 6:38 PM
> *To:* Raphael Tryster
> *Cc:* Schwarz Albrecht; Christian Groves; [email-masked]
> *Subject:* RE: [Megaco] Question about RTP payloadtype
>
> Raphael,
>
> By the time that the Rx media handling engine has detected the change 
> in codec (received at least N periodic packets of the new compressed 
> codec) and wishes to report it, there is a slim chance that some of 
> the non-periodic (supplementary) packets have also been received as 
> well, so the MG may report Received periodic and non-periodic codec 
> types in the pltrans event
>
> ------------------------------------------------------------------------
>
> *From:* Raphael Tryster [mailto:[email-masked]]
> *Sent:* 06 September 2007 14:40
> *To:* Schwarz Albrecht; Christian Groves
> *Cc:* [email-masked]
> *Subject:* RE: [Megaco] Question about RTP payloadtype
>
> Albrecht,
>
> ------------------------------------------------------------------------
>
> *From:* Schwarz Albrecht [mailto:[email-masked]]
> *Sent:* Thursday, September 06, 2007 4:26 PM
> *To:* Raphael Tryster; Christian Groves
> *Cc:* [email-masked]
> *Subject:* RE: [Megaco] Question about RTP payloadtype
>
> rtp/pltrans is an event, thus for the Rx flow only ("the semantic is 
> not explicitly extended on the Tx flow as well, as e.g. done in 
> H.248.40"). Right?
>
> If my understanding is correct, the the semantic means RTP payload 
> type changes just of the remote RTP endpoint.
>
>     ------------------------------------------------------------------------
>
>     *From:* Raphael Tryster [mailto:[email-masked]]
>     *Sent:* Donnerstag, 6. September 2007 13:25
>     *To:* Christian Groves
>     *Cc:* [email-masked]
>     *Subject:* RE: [Megaco] Question about RTP payloadtype
>
>     This is a continuation of a thread that I started a few days ago,
>     but the exchange below from 5 years ago is somewhat relevant, as
>     it establishes that the rtppltype parameter of rtp/pltrans does
>     not refer to Rx/Tx. My question is then, what is the meaning of
>     rtppltype being of type sublist of enumeration? Syntactically, I
>     assume this means something like
>
>     ObservedEvents = 1111 { 20070906T141539 : rtp/pltrans { rtppltype
>     = [g723, g729] } }
>
>     with a delay, what is the mechanism by which this delayed
>     reporting is engineered? Is there a way that the MGC could request
>     buffering of such events, and then have them all reported at once
>     by requesting that ObservedEvents be included in the reply to
>     Subtract?
>
>     Raphael Tryster
>
>     ------------------------------------------------------------------------
>
>     *From:* Terry L Anderson [mailto:[email-masked]]
>     *Sent:* Tuesday, October 29, 2002 8:55 PM
>     *To:* Christian Groves
>     *Cc:* Seunghan Choi; [email-masked]
>     *Subject:* Re: [Megaco] Question about RTP payloadtype
>
>     Agreed. We would need to bump the version of the package. Perhaps
>     we should add a note to rtp v1 and add a parameter to rtp v2
>
>     Christian Groves wrote:
>
>     G'Day,
>
>      
>
>     The assumption behind E.12 was that the payload was symmetrical. We could add a
>
>     note stating this but I believe the additional of an extra parameter is beyond
>
>     an IG item. There no way to add an extra parameter to an event and maintain
>
>     as well as rapporteur). Kevin can propose a fix for discussion on the list.
>
>      
>
>     Seunghan Choi wrote:
>
>      
>
>       
>
>>     Hi, All.
>>      
>>     Is there the case that RTPpayload type(Rx CodecType) in localDescriptor and RTPpayload type(Tx CodecType) in remoteDescriptor is different?
>>     If there is that case, Which does the rtppltype mean, Rx CodecType or Tx CodecType, in E.12 Payload Transition?
>>      
>>     Thanks.
>>      
>>         
>      
>
>      
>
>      
>
>       
>
> ------------------------------------------------------------------------
>

---

From: "Stephen Mell (CV/ETL)" <[email-masked]>
Date: Tue, 11 Sep 2007 15:27:53 +0200

Hi Christian,

Exploring your initial ideas a bit further:

If mode is sendonly or recvonly then a single value might be interpreted
with respect to the media mode that is currently in force, as tx pltrans
and rx pltrans respectively. This could be difficult to interpret if the
event is generated during a mode change, so Im not sure that idea is too
great.

If mode is sendrecv and only the transmit codec changes (perhaps the
original bidirectional connection was asymmetrical and the Rx codec was
already uncompressed in a VoiceBandData switch scenario), then the list
semantics are problematic, as it is not possible to represent a change
in Tx only in this way (as it is the second element in the list). Maybe
for these purposes a sentinel value can be employed to explicilty
signify that no RX codec change has taken place:

E.g.  rtp/pltrans = [ None, G711 ]   - Rx no change, Tx changed to 8

I also think it would there are advantages if an MGC were able to
unambiguously report a change in Rx codec, without an implied change in
Tx codec in that Observed Event, as this could serve as an indication
for situations where automated VBD switches between gateways have failed
to work properly. 

Having said that its probably more important to maintain backward
compatibility with existing implementations. I would guess that many
implementations only ever report one value for rtp/pltrans and that
value is the New Rx CODEC, and this would be true regardless of whether
the Tx codec has changed or not. Given the existing vagueness of the
published package, these implementations seem reasonable to me. For
backward compatibility reasons, it might be wise to state that reporting
of a change in Tx Codec is optional. In the case where the Tx codec at
the end of the list is not present than it would not be possible to tell
if the Tx codec had changed or not. If the MG puts the sentinel value as
the second value in the codec list, then it would be possible to infer
that the Tx codec has not changed.

In summary, a suggested scheme using sentinel values to explicility
signify NoChange and at the same time (hopefully) achieving backward
compatibility:-

rtp/pltrans = G711  - Rx changed to G711, no information about Tx change
can 
                      be inferred by the MGC (for backward
compatibility)
rtp/pltrans = [ None, G711 ] - Rx No change, Tx changed to g711
rtp/pltrans = [ G711, None ] - Rx changed to g711, Tx No Change
rtp/pltrans = [ G711, G711 ] - Rx changed to g711, Tx changed to g711
rtp/pltrans = [ None, None ] - TxRx no change - MG should not report
this!

Interpretation of above is always independent of the media mode.

Steve 

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: 07 September 2007 03:38
To: Raphael Tryster
Cc: [email-masked]; Schwarz Albrecht
Subject: Re: [Megaco] Question about RTP payloadtype

Hello Raphael,

Some initial thoughts:
On a) Does a single value mean a codec change in both the send/receive
direction (symmetrical change) or only the receive direction?
On b) I think we could easily say that the first value is the local
value, the second is the remote On c) I can't see a case for three so we
may be able to limit the list size to 2.

Regards, Christian

> that you remember at the last minute. That's because I am human and 

> have "left the office" as soon as they get a job to do, and would have

> So, unless one of the authors informs us otherwise, I'm betting they 

>     Kevin Boyle is our new Implementors Guide editor (as of the end of

> the

---

From: "Raphael Tryster" <[email-masked]>
Date: Tue, 11 Sep 2007 18:15:09 +0300

I am wondering if this goes against the spirit of what a list is.  If
you can say that the first element in the list means this and the second
element means that and you can't have more than two, then the
appropriate representation of this functionality is two parameters and
not a list.  Are there any other cases in Megaco where a list is used in
this way?

I understand there is a backward compatibility issue, but it appears the
only thing we need to be backward compatible with is a single value
meaning Rx change.  If, instead of a list, we add a second parameter
meaning Tx change, would this break more implementations than keeping
the list with the semantics now being suggested?

Raphael Tryster

-----Original Message-----
From: Stephen Mell (CV/ETL) [mailto:[email-masked]] 
Sent: Tuesday, September 11, 2007 4:28 PM
To: Christian Groves
Cc: Raphael Tryster; [email-masked]; [email-masked]
Subject: RE: [Megaco] Question about RTP payloadtype

Hi Christian,

Steve 

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: 07 September 2007 03:38
To: Raphael Tryster
Cc: [email-masked]; Schwarz Albrecht
Subject: Re: [Megaco] Question about RTP payloadtype

Hello Raphael,

Some initial thoughts:

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Wed, 12 Sep 2007 12:56:56 +1000

Hello Raphael,

In itself I don't think specifying what a position means in a list is 
goes against the spirit of a list. There are other examples where list 
positions relate etc. However I would agree that a separate parameter 
would typically be a better way on achieving this for this 2 list 
position case.

I think Steve's proposal has some merit with regards to the logic on how 
to indicate rx and tx codec payload change though this proposal assumes 
that tx payload change was covered.

However I did some more digging through and found that I was to culprit 
behind the original text. The text that I proposed in 1999 hasn't 
changed. I can't remember why a list was chosen other than it was added 
after a discussion on codec negotiation which made use of codec lists. 
Given that there hasn't been many questions on this event and people 
seem to agree that a single codec means a received payload change I'd be 
quite happy to aaply to KISS principle and simply add a note to the effect:
"A single value represents a received payload change. Typically multiple 
payload changes would be notified separately. Where multiple values are 
returned they also represent received payload changes. The use cases for 
multiple values is FFS."

If someone wants a separate event for tx payload change then they can 
bring a contribution/ propose to the this to add it.

It seems that we've come full circle back to your first question Raphael.

Regards, Christian

Raphael Tryster wrote:
>>     as well as rapporteur). Kevin can propose a fix for discussion on
>>     
> the list.
>   
>>      
>>
>>     Seunghan Choi wrote:
>>
>>      
>>
>>       
>>
>>     
>>>     Hi, All.
>>>