Megaco MediaDescriptor sending multiStream instead of oneStream

[Hakan Mattsson]

On Tue, 1 Oct 2002, Peter-Henry Mander wrote:

Pete> I've got another query, and as you've been a great help already I'm 
Pete> asking you directly. I'm sending out a AmmRequest with the following 
Pete> format:
Pete> 
Pete> 	      #'AmmRequest'{
Pete> 		      terminationID = [TermId],
Pete> 		      descriptors = [
Pete> 			      {	mediaDescriptor,
Pete> 				      #'MediaDescriptor'{streams = {oneStream, StreamParms}}}]
Pete> 	      };
Pete> 
Pete> Note the oneStream streams field. What I receive at the other end is:
Pete> 
Pete> {'MediaDescriptor',asn1_NOVALUE,
Pete> 			 {multiStream,[{'StreamDescriptor',
Pete> 					   1,
Pete> 					   {'StreamParms',
Pete> 					       {'LocalControlDescriptor',
Pete> 						   asn1_NOVALUE,
Pete> 						   asn1_NOVALUE,
Pete> 						   asn1_NOVALUE, ...etc...
Pete> 
Pete> And the megaco message looks like this:
Pete> 
Pete> Transaction = 26 {
Pete> 	      Context = $ {
Pete> 		      Add = $ {
Pete> 			      Media {
Pete> 				      Stream = 1 {
Pete> 					      LocalControl { ...etc...

Our encoder and decoder is not symmetric in this case.

Your message is encoded as:

	Transaction = 26 {
		      Context = $ {
			      Add = $ {
				      Media {
					      LocalControl { ...etc...

but interpreted by the decoder as if it was:

	Transaction = 26 {
		      Context = $ {
			      Add = $ {
				      Media {
					      Stream = 1 {
						      LocalControl { ...etc...

which is semantically the same thing.

Pete> I suppose the Stream = 1 {...} block indicates multiStream.
Pete> It looks as if the encoder is ignoring my oneStream and sending multiStream
Pete> in it's place. Is there something I missed and ought to be doing?

You have not missed anything.

Once upon the time I thought that it would be convenient for the user
if the decoder abstracted away the syntactic sugar for the default
stream id (oneStream). But now I realize that it is pretty confusing.

If you download and gunzip the attached file into the megaco/src/text
directory and recompiles megaco/src/megaco_text_parser.erl I think
that the decoder to behave like you expected.

/Håkan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: megaco_text_parser.hrl.gz
Type: application/octet-stream
Size: 6764 bytes
Desc: megaco_text_parser.hrl.gz
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20021002/12d4303f/attachment.obj>