Subject: RE: [MMUSIC] Re: Multiple 'm' lines with the same port number

From: [email-masked]
Date: Thu, 8 Jan 2004 12:30:44 +0200

I would hate to see exceptions like these when building a generic SDP parser with built it checks for compliancy.
Why can't MSRP just follow that rule?

Regards,
Hisham

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Paul E. Jones
> Sent: 07.January.2004 23:15
> To: Paul Kyzivat; Flemming Andreasen
> Cc: Kumar, Rajesh; Kevin Boyle; Stephen Casner; Colin Perkins;
> [email-masked]; Mostafa, Mohamed; Abdelhamid, Hisham;
> [email-masked]
> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number
> 
> 
> Paul,
> 
> While that sounds most unfortunate (I'd love to see an 
> example if you have
> one), I think it would be exempt from this rule, because the 
> port is just a
> dummy value.
> 
> Paul
> 
> ----- Original Message ----- 
> From: "Paul Kyzivat" <[email-masked]>
> To: "Flemming Andreasen" <[email-masked]>
> Cc: "Kumar, Rajesh" <[email-masked]>; "Kevin Boyle"
> <[email-masked]>; "Stephen Casner" <[email-masked]>; "Colin
> Perkins" <[email-masked]>; <[email-masked]>; "Mostafa, Mohamed"
> <[email-masked]>; "Abdelhamid, Hisham" <[email-masked]>;
> <[email-masked]>; <[email-masked]>
> Sent: Wednesday, January 07, 2004 4:12 PM
> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number
> 
> 
> > I recently encountered an interesting case relevant to this 
> while making
> > up an example for MSRP.
> >
> > In MSRP the port number is not used, except for the 
> distinction between
> > a zero and non-zero value. There is a requirement that some random
> > non-zero value be inserted and then ignored. If there are 
> multiple MSRP
> > media sessions in the same SDP body, must they have differing port
> numbers?
> >
> > Paul
> >
> > Flemming Andreasen wrote:
> > >
> > > "Kumar, Rajesh" wrote:
> > >
> > >
> > >>AVT members,
> > >>
> > >>There was some confusion on this issue in the recent TIA 
> TR.30.1 meeting
> > >>in Orlando, Florida.
> > >>
> > >>Could someone officially confirm or deny whether multiple 
> "m=" lines
> > >>with the SAME media type (e.g. "audio") and protocol 
> (e.g. RTP/AVP)
> > >>cannot be assigned the same port number?
> > >
> > >
> > > The consensus of this discussion is that is that they 
> cannot (assuming
> they
> > > use the same IP address).
> > >
> > > -- Flemming
> > >
> > >
> > >
> > >>If they can be assigned the
> > >>same port number, then it is possible to selectively 
> associate RFC 2733
> > >>FEC with some payload types such as those that carry 
> voice band data.
> > >>Otherwise, there is a hole in SDP that does not permit selective,
> > >>payload-specific declaration of FEC. I am aware of the 
> fact that in RFC
> > >>2733 the use of and level of FEC is a transmitter 
> prerogative and that a
> > >>transmitter may choose to selectively utilize FEC based 
> on payload type
> > >>transmitted.
> > >>
> > >>Thanks,
> > >>
> > >>Rajesh
> > >>
> > >>
> > >>>-----Original Message-----
> > >>>From: Flemming Andreasen [mailto:[email-masked]]
> > >>>Sent: Friday, December 12, 2003 4:21 AM
> > >>>To: Kevin Boyle
> > >>>Cc: Stephen Casner; Kumar, Rajesh; Colin Perkins; 
> [email-masked];
> > >>
> > >>Mostafa, Mohamed;
> > >>
> > >>>Abdelhamid, Hisham; [email-masked]; [email-masked]
> > >>>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the 
> same port number
> > >>>
> > >>>
> > >>>
> > >>>Kevin Boyle wrote:
> > >>>
> > >>>
> > >>>>
> > >>>>All,
> > >>>>
> > >>>>Looking back at this email stream, one question remains 
> outstanding
> > >>>
> > >>in
> > >>
> > >>>>my mind:
> > >>>>
> > >>>>What if the two m= lines have the SAME media type?  For 
> instance:
> > >>>>
> > >>>>m=audio 49232 RTP/AVP 18
> > >>>>m=image 49233 UDPTL t38
> > >>>>m=audio 49232 RTP/AVP 100
> > >>>>a=rtpmap:100 PCMU/8000
> > >>>>a=gpmd:100 vbd=yes
> > >>>>
> > >>>>For some of the SDP-based protocols, the order of appearance is
> > >>>
> > >>vital
> > >>
> > >>>>because it announces preference.
> > >>>
> > >>>Only for the media formats within a given "m=" line. 
> Multiple "m="
> > >>
> > >>lines
> > >>
> > >>>indicates a set of simultaneous media streams; not alternatives.
> > >>>
> > >>>
> > >>>
> > >>>>So, this shows preference for T.38 fax relay over PCMU 
> VBD for fax,
> > >>>>while utilizing G.729 for voice.  As far as I can tell, this
> > >>>
> > >>construct
> > >>
> > >>>>is allowed, since both m lines using the same port number use a
> > >>>
> > >>media
> > >>
> > >>>>type of audio.
> > >>>>
> > >>>>Is my understanding correct?
> > >>>>
> > >>>
> > >>>Not quite. Each "m=" line corresponds to a separate media stream.
> > >>
> > >>Also,
> > >>
> > >>>the consensus of this discussion has been that you are 
> *not* allowed
> > >>
> > >>to
> > >>
> > >>>use the same port for different media lines, regardless 
> of whether
> > >>
> > >>they
> > >>
> > >>>share the same top-level MIME type or not.
> > >>>
> > >>>-- Flemming
> > >>>
> > >>>
> > >>>>Thanks,
> > >>>>
> > >>>>Kevin
> > >>>>
> > >>>>-----Original Message-----
> > >>>>From: Stephen Casner [mailto:[email-masked]]
> > >>>>Sent: Friday, April 25, 2003 2:57 PM
> > >>>>To: Rajesh Kumar
> > >>>>Cc: Colin Perkins; [email-masked]; flemming Andreasen;
> > >>>>[email-masked]; [email-masked]; [email-masked];
> > >>>>[email-masked]
> > >>>>
> > >>>>Subject: [MMUSIC] Re: Multiple 'm' lines with the same 
> port number
> > >>>>
> > >>>>Rajesh,
> > >>>>
> > >>>>
> > >>>>>Is the use of multiple 'm=' lines with the same port 
> number within
> > >>>>
> > >>>>an
> > >>>>
> > >>>>>SDP descriptor permitted?
> > >>>>
> > >>>>Presuming that the multiple m= lines are all RTP/AVP, 
> then doing so
> > >>>>causes all of the payload formats listed on the m= 
> lines to become
> > >>>>part of a single RTP session (unless they are 
> distinguished by some
> > >>>>other aspect of addressing).  Section 5.2 of the RTP 
> spec addresses
> > >>>>NOT multiplexing different media in the same RTP session.
> > >>>>
> > >>>>
> > >>>>>In SDP, as it is defined, all the media formats on an 'm=' line
> > >>>>
> > >>are
> > >>
> > >>>>of
> > >>>>
> > >>>>>the same media type (e.g. audio, image, text etc.).
> > >>>>>
> > >>>>>Now consider the case in which two RTP media formats can use a
> > >>>>>destination port but are registered under different MIME types.
> > >>>>
> > >>For
> > >>
> > >>>>>example, text/t140 and audio/PCMU. In this case, there is no
> > >>>>
> > >>>>recourse
> > >>>>
> > >>>>>except to use multiple media lines with the same port 
> number. For
> > >>>>
> > >>>>example:
> > >>>>
> > >>>>The "can use a destination port" is the tricky part.  We may not
> > >>>>agree.
> > >>>>
> > >>>>
> > >>>>>m=audio 49232 RTP/AVP 0
> > >>>>>m=text 49232 RTP/AVP 100
> > >>>>>a=rtpmap:100 t140
> > >>>>>
> > >>>>>My thought is that although this is unsual, it is not 
> proscribed
> > >>>>
> > >>by
> > >>
> > >>>>>SDP syntax in RFC 2327 or in its latest internet draft.
> > >>>>
> > >>>>I believe this is proscribed by section 5.2 of the RTP 
> spec because
> > >>>>these two media should not be multiplexed in one RTP session.
> > >>>>
> > >>>>My bet is that the real example you are thinking about is fax or
> > >>>
> > >>modem
> > >>
> > >>>>over IP.  We've been there before.
> > >>>>
> > >>>>                                                        -- Steve
> > >>>>
> > >>>>_______________________________________________
> > >>>>mmusic mailing list
> > >>>>[email-masked]
> > >>>>https://www1.ietf.org/mailman/listinfo/mmusic
> > >>>
> > >
> > >
> > > _______________________________________________
> > > mmusic mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/mmusic
> > >
> >
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Jan 2004 09:17:50 -0500

Hisham,

I have an open mind about this right now. It seems to be a matter of 
picking your favorite poison, since neither alternative is ideal:
- ensure that the ports used are unique even though they are ignored
- change SDP - something that is not very popular.

So far, aside from me there are two votes, one on each side. From the 
point of view of SIMPLE it is of course logistically simpler to leave 
SDP alone.

	Paul

P.S. It seems that simple wasn't on the mailing list, so I have added it.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 16 Jan 2004 11:28:41 -0600

Sorry for the late reply--for some reason this just showed up in my 
inbox. (Or I just noticed it, anyway.)

I don't see it as a problem to have MSRP mention that the ports must be 
distinct. We currently have a standard dummy value, rather than a random 
value. With this restriction, I think the answer is to say the sender 
can choose any legal non-zero value, and if multiple MSRP m-lines exist, 
they must have different port values. Is this sufficient? I don't see 
any reason to care about how a particular implementation goes about 
generating them.

Paul Kyzivat wrote:

>> I would hate to see exceptions like these when building a generic SDP 
>> parser with built it checks for compliancy.
>>> While that sounds most unfortunate (I'd love to see an example if you 
>>> have
>>> one), I think it would be exempt from this rule, because the port is 
>>> just a
>>> dummy value.
>>>
>>> Paul
>>>
>>> ----- Original Message ----- From: "Paul Kyzivat" <[email-masked]>
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Jan 2004 13:54:04 -0500

Ben,

I am inclined to agree that this is the most expedient way forward and 
not worth doing anything more.

It offends my sense of elegance to require a value that is intended to 
be ignored, and offends it futher to insist that multiple instances must 
be distinct to be valid even though ignored. But still it is the lesser 
evil.

	Paul

Ben Campbell wrote:
>>>> While that sounds most unfortunate (I'd love to see an example if 
>>>> you have