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

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Jan 2004 16:12:30 -0500

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 7 Jan 2004 16:14:32 -0500

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

---

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

Comments inline.

	Paul

P.S. I have added simple to the list, and removed most of the individual 
names, since my last posting was sent to the chair for screening.

Paul E. Jones wrote:
> Paul,
> 
> 
>>>While that sounds most unfortunate
>>
>>What is most unfortunate?
>>- that MSRP ignores the port number from the m-line
>>- that different dummy port numbers might have to be used
>>- ???
> 
> 
> That there is a different dummy port number inserted.  Why not require that
> they be consistent or just remove the port number from URL and rely on the
> SDP port number when SDP is used?  Is the URL used outside of SDP?  From
> what I've gathered, the URL is temporary and only used for session
> identification.
> 
> However, doing that does open the question that started this discussion...
> would it be a problem for multiple m= lines to have the same port number.
> It might be that you have two message sessions between to devices that
> advertised the same TCP port, but are uniquely identified by the session
> URL.  Then we potentially have an SDP violation, I guess.

That is a very likely scenario.

>>The reason it is ignored is that an a-line containing a URL is used, and
>>specifies all the addressing needed. The alternative was assembling a
>>URL from pieces of the m-line, c-line, and an a-line. There really is no
>>nice answer. The SDP syntax works tolerably for RTP and UDP but presents
>>problems for more complex transports.
> 
> 
> So, I can agree with not necessarily wanting to assemble a URL from various
> pieces of data here and there.  I don't want to propose that you necessarily
> change the URL, but keep the port number consistent.

As you point out above, keeping the port number consistent between the 
url and the m-line could lead to a violation. And the concept of having 
to put the same information in two places isn't especially appealing anyway.

> I'm definitely aware of the issues with SDP "growing" to accomodate things
> other than RTP and such.  However, I don't have a good feel for whether
> people are truly interested in making a big changed to something like SDPng
> or just evolving SDP.  It seems like evolving SDP is winning favor, though
> I'd like to hear opinions on that.  In the case that we do evolve SDP for a
> number of years, we should try to do it in as consistent a manner as
> possible.

Certainly nobody is going to wait for SDPng to be adopted before 
introducing something line MSRP. There has to be a way to use it with SDP.

> Now, as for this port number issue.  As the document is now written, the
> ports are unique and there is no violation to speak of... just confused me
> when I saw it.  I'd personally rather insert an exception into SDP to allow
> TCP session to have the same port number than to create bogus port numbers.
> A change in the SDP text along those lines would not break the spirit of the
> present text and should not break anything.

I guess this would be up to MMUSIC to deal with. As I mentioned in my 
reply to Hisham, it is probably the case that the path of least 
resistance for MSRP is to live with the uniqueness requirement.

In any case, the two approaches don't conflict. MSRP can simply state 
that while the port numbers are ignored they must still conform to the 
SDP standard. Then if SDP changes to permit duplicate ports in this case 
then we are all set.

>> > (I'd love to see an example if you have one),
>>
>>I've attached a message from the SIMPLE list. Note that the SDP is not
>>intended to be complete - just the key parts needed to make the point.
> 
> 
> Thanks.  I also just looked at draft-ietf-simple-message-sessions-02.txt
> briefly.  I'm certainly not an expert on this subject matter, but I've
> learned a little :)
> 
> 
>> > I think it would be exempt from this rule, because the port is just a
>>>dummy value.
>>
>>That would be nice. It may be necessary to clarify that somewhere.
> 
> You might have already hashed all of these issues through already and I do
> apologize if that is the case.  (But, when I get explicitly copied on
> something, I tend to pay more attention than when mailing list dialog goes
> passing by.)
> 
> I would like to hear your comments on what I've suggested and asked above.
> 
> Thanks,
> Paul
> 
> 
>>Paul
>>
>>
>>>Paul
>>>
>>>>media sessions in the same SDP body, must they have differing port
>>>
>>>numbers?
>>>
>>>
>>>>Paul
>>>>
>>>>>>There was some confusion on this issue in the recent TIA TR.30.1
>>>>>
> meeting
> 
>>>>>>in Orlando, Florida.
>>>>>>
>>>>>The consensus of this discussion is that is that they cannot (assuming
>>>>
>>>they
>>>
>>>
>>>>>>same port number, then it is possible to selectively associate RFC
>>>>>
> 2733
> 
>>>>>>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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port
>>>>>>
> number
> 
>>>>>>>
>>>>>>>
>>>>>>>Kevin Boyle wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>All,
>>>>>>>>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 8 Jan 2004 01:08:13 -0500

Paul,

Thanks,
Paul

meeting
2733
RFC
a
type
number

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Jan 2004 16:58:53 -0500

inline...

	Paul

>>>>>>over IP.  We've been there before.

Subject: Re: [Simple] MSRP: Some thoughts on session updates
From: Paul Kyzivat <[email-masked]>
To: Chris Boulton <[email-masked]>
Cc: Ben Campbell <[email-masked]>, [email-masked], [email-masked]
Date: Tue, 06 Jan 2004 16:02:50 -0500
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org>

Chris Boulton wrote:
> 
> [Chris Boulton] I think we can all recognize that this is a global
> problem rather than msrp specific.  I like Paul's idea of having an
> attribute e.g. 'a=reconnect' to indicate the continuation of a session.
> Just one question, the version number in the offer will have changed,
> due to payload change, so how would the msrp client associate a
> reconnect with an existing session, if multiple exist?
> 
> e.g. Client A and B currently have 2 connection, one for messaging, one
> for file transfer - client B is hosting.  Client A detects failure in
> one of the connections (Client B has not detected failure) and issues a
> new offer via an 'update'.  Client B receives the offer and realizes
> it's a reconnect.  How does client B know which of the two connections
> we are attempting to reconnect?

The attribute is associated with a particular media session. It can be 
inserted into the one for the session that is to be reconnected. It is 
inserted twice if both are to be reconnected.

         Alice->Bob (SIP): INVITE sip:[email-masked]

         c=IN IP4 fillername
         m=message 9999 msrp/tcp *
         a=accept-types:text/plain
         a=direction:both
         a=session:msrp://alicepc.atlanta.com:7777/iau39
         a=version:1

         Bob->Alice (SIP): 200 OK

         c=IN IP4 ignorefield
         m=message 9999 msrp/tcp *
         a=accept-types:text/plain
         a=direction:active
         a=version:1

Alice then adds another session for file transfer:

         Alice->Bob (SIP): INVITE sip:[email-masked]

         c=IN IP4 fillername
         m=message 9999 msrp/tcp *
         a=accept-types:text/plain
         a=direction:both
         a=version:1
         m=message 9998 msrp/tcp *
         a=accept-types:application/pdf
         a=direction:passive
         a=sendonly
         a=session:msrp://alicepc.atlanta.com:7777/iau40
         a=version:1

         Bob->Alice (SIP): 200 OK

         c=IN IP4 ignorefield
         m=message 9999 msrp/tcp *
         a=accept-types:text/plain
         a=direction:active
         a=version:1
         m=message 9998 msrp/tcp *
         a=accept-types:application/pdf
         a=direction:active
         a=recvonly
         a=version:1

Bob later discovers something wrong with the file transfer:

         Bob->Alice (SIP): (re)INVITE sip:[email-masked]

         c=IN IP4 ignorefield
         m=message 9999 msrp/tcp *
         a=accept-types:text/plain
         a=direction:active
         a=version:1
         m=message 9999 msrp/tcp *
         a=accept-types:application/pdf
         a=direction:active
         a=recvonly
         a=version:2

Alice sees that the version for the first session is unchanged and so 
does nothing with it. But the version for the 2nd session is changed, so 
she starts listening again for a new connection, and responds:

         Alice->Bob (SIP): 200 OK

         c=IN IP4 fillername
         m=message 9999 msrp/tcp *
         a=accept-types:text/plain
         a=direction:passive
         a=version:1
         m=message 9999 msrp/tcp *
         a=accept-types:application/pdf
         a=direction:passive
         a=sendonly
         a=session:msrp://alicepc.atlanta.com:7777/iau41
         a=version:2

A subsequent offer/answer that didn't want to change anything could use 
these same sdp bodies.

	Paul

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