Re: [MMUSIC] Associating packets with m-lines in a bundle

[Paul Kyzivat <[e-mail]>]

On 5/23/13 6:07 PM, Dale R. Worley wrote:
>> From: Paul Kyzivat <[e-mail]>
>>
>> IMO the following should obviously be a truism. I want to know if all agree.
>>
>> If an O/A exchange negotiates a bundle with multiple m-lines,
>> then attributes in those m-lines and the associated media sections must
>> provide sufficient information to associate each incoming packet on the
>> 5-tuple to exactly *one* of those m-lines.
>
> I agree.  I think there are non-legacy situations where this need may
> be relaxed, but all interoperation in legacy situations seems to
> require discerning the appropriate m= line so information in the SDP
> section can be used to identify the particular application processing
> stream.

??? There aren't any legacy interoperation situations for bundle.

>> [...] receiving packets that don't match any of the m-lines. I
>> think we ought to address that, by defining some syntax to specify what
>> to do with packets that don't match any m-line. This might be to specify
>> one m-line as the default, or that packets that don't match be discarded.
>
> I think that discarding them is the only workable approach.  There's
> no reason to assume that sending them to a default m= line would allow
> the upper level of demultiplexing to succeed.

My thought was that the receiver could signal a "default m-line". This 
would need to be done for each classification criterion. E.g.,

a=ssrc:* ...

would identify the m-line that should be used for otherwise unspecified 
ssrc values.

a=new-header-extension:*

would identify the m-line to use for packets carrying no header 
extension or an undeclared value.

Any packet that still can't be classified after including such wildcards 
would be discarded.

I don't think such wildcarding makes any sense for PT.

	Thanks,
	Paul