Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern

From: Ben Campbell <[email-masked]>
Date: Mon, 3 Jan 2005 10:55:43 -0600

I sent the following proposed compromise out before the holidays. If 
anyone commented on it, I have not seen the comments. The general idea 
is that MSRP aware endpoints would use the path attribute, but a non 
MSRP aware device could still determine the destination address and 
port from the m and c lines. thoughts?

> How about this as a potential compromise:
>
> We keep the path attribute as is, but _also_ copy the information for 
> the endpoint into the m and c lines. This would seem to me to be 
> consistent with the usage in the current ICE draft, in which ICE aware 
> endpoints use the candidate attributes to determine the address and 
> port, but the default address and port are copied into the m and c 
> line for backwards compatibility? Considering that the ICE need for 
> backwards compatibility seems much more clear than the MSRP need for 
> the same?

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

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 3 Jan 2005 18:11:09 +0100

I don't see the need. The information in the c and m line will be 
ignored anyway by the receiver, so why waste CPU cycles?

Also, backwards compatible with what?

Anyway, I don't feel too strongly about this. If it makes the SDP 
people happy, then we can add it.

Regards,
Hisham

On Jan 3, 2005, at 5:55 PM, Ben Campbell wrote:

>> consistent with the usage in the current ICE draft, in which ICE 
>> aware endpoints use the candidate attributes to determine the address 
>> and port, but the default address and port are copied into the m and 
>> c line for backwards compatibility? Considering that the ICE need for

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Jan 2005 12:33:27 -0500

Ben,

I think there is a potential problem with this solution, and in fact 
with any solution that uses the m- and c- lines for address and port:

it is possible that there could be two (or more) MSRP media streams in 
the same offer/answer. Because of the multiplexing capabilities of MSRP, 
there could be multiple streams that share the same address and port.

In the case of RTP streams, every stream must have a unique 
address/port. Technically I believe the rules about this are transport 
dependent, so that there could be separate rules for MSRP, permitting 
this. However, I am concerned that those arguing that we must use m- and 
c- for address and port will also object to duplicates, even with the 
msrp transport.

Conversely, if we are permitted to define the rules differently for 
msrp, I don't see why we can't define the rules so we don't use m- and 
c- for address and port.

	Paul

Ben Campbell wrote:
> MSRP aware device could still determine the destination address and port 
> from the m and c lines. thoughts?
> 
> ------------------------------------------------------------------------
>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 3 Jan 2005 18:03:52 +0000

> ignored anyway by the receiver, so why waste CPU cycles?

Because SDP requires the "c=" and "m=" lines to indicate where the 
media is sent, and because there could be a middlebox or other device 
processing the SDP that needs that information.

> Also, backwards compatible with what?

Other devices that parse SDP, some of which may be outside your control.

Colin

---

From: Colin Perkins <[email-masked]>
Date: Mon, 3 Jan 2005 18:06:10 +0000

> port from the m and c lines. thoughts?

Not ideal, but better than ignoring the addresses in the "c=" and "m=" 
lines.

Colin

---

From: Ben Campbell <[email-masked]>
Date: Mon, 3 Jan 2005 12:50:45 -0600

It sounds to me that you have just described a real technical issue  
where using the m and c lines _cannot_ work in the general case unless  
we break other SDP rules anyway.

On Jan 3, 2005, at 11:33 AM, Paul Kyzivat wrote:

> the same offer/answer. Because of the multiplexing capabilities of  
> MSRP, there could be multiple streams that share the same address and  
> port.
>
> this. However, I am concerned that those arguing that we must use m-  
> and c- for address and port will also object to duplicates, even with  
> the msrp transport.
>
>> anyone commented on it, I have not seen the comments. The general  
>> idea is that MSRP aware endpoints would use the path attribute, but a  
>> non MSRP aware device could still determine the destination address  
>> and port from the m and c lines. thoughts?
>>> We keep the path attribute as is, but _also_ copy the information  
>>> for the endpoint into the m and c lines. This would seem to me to be  
>>> aware endpoints use the candidate attributes to determine the  
>>> address and port, but the default address and port are copied into  
>>> the m and c line for backwards compatibility? Considering that the  
>>> ICE need for backwards compatibility seems much more clear than the  
>>> MSRP need for the same?

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Jan 2005 23:06:38 -0500

Colin Perkins wrote:
> Because SDP requires the "c=" and "m=" lines to indicate where the media 
> is sent, and because there could be a middlebox or other device 

For a middlebox to work with this, it must understand the *semantics*, 
not just the syntax. Even if we were to use the m- and c- lines as 
requested, a middlebox without specific knowledge of msrp will not know 
what to do: is the tcp, udp, rtp, or what?

And in the case of msrp, the msrp relay *is* the middlebox, and the sdp 
syntax has been designed specifically to accomodate it.

> Other devices that parse SDP, some of which may be outside your control.

I still don't buy this. There is no issue of *parsing* the SDP. Nothing 
we have done is inconsistent with SDP parsing.

I think the issue you are alluding to must be more to "implementing" SDP 
to a greater extent than just parsing it. But in all cases the semantics 
are a function of the particular transport. Its not clear to me that are 
any standard semantics.

Colin - I would like to hear exactly what you think can be implemented 
generically across all transports, including unknown ones.

	Paul

---

From: Joerg Ott <[email-masked]>
Date: Tue, 04 Jan 2005 18:36:42 +0100

The essence of what I hear (or read) Paul saying is:

 From SDP, we need the "m=<media-type>" part to delimit streams
and to identify something as MSRP.  There may be a few common
attributes and further fields but do not count on them because
the rest is up to the interpretation per media protocol.

This viewpoint doesn't really convince me at this point.
We have numerous rules and extensions for SDP (preconditions,
labels, etc.), and I haven't yet gone through the exercise
to find out whether such a "usage" of SDP would actually
work with all of these.  (This does not mean that I would
like this approach even if we can make this work.)

But leaving alone the "ugliness" issue for the moment, I
would like to discuss two issues so that we can take a
meaningful decision and move on:

1.  Need for Relays

MSRP motivates relays primarily by NAT/firewall traversal.
But, of course, it would be much nicer if two endpoints
could talk to each other directly (rather than via an
intermediary).  Then, we would not really need multiplexing
(unless maybe two gateways talk -- which is conceptually
different) and a single m=/c= line would be sufficient
(and might simply reuse comedia and be done with it).

Hence, what we are arguing over is a (potentially endlessly
lasting) interim solution until we get the connectivity right.
If there was a way to do something like ICE here as well,
we would be done with it.

So, how much hassle are we willing to take up to make the
interim solution work.  This should add to the basic version
instead of having the basic version designed as a special
case of the interim.

2.  Generality

Assuming that there is a need for a stepwise connection via
some relay (and that this will never go away), I suspect that
MSRP will not be only application protocol that is going to
need it.  T.38 via TCP may be another example and so may a
shared PowerPoint presetation or VNC application.

Then, I would like to have a general solution developed that
is _not_ specific to MSRP and is documented as such.  We would
need to design something like draft-*-comedia-muxed-via-relays
rather than having one specific solution now and coming up
with another one every week.

This appears to call for some explicitly spelled out requirements
rather than a detailed discussion about a partial technical
solution.

Joerg

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Jan 2005 13:51:38 -0500

> the rest is up to the interpretation per media protocol.

Its not the m=media-type part (m=application) that is significant here. 
It is the transport protocol in the m-line that is most significant. 
(m=application 9 msrp *).

And it really isn't just about msrp, although that is clearly what is 
motivating the discussion. SDP *claims* to be flexible to different 
transport protocols, and makes a considerable part of the semantics 
conditional on that. But in large part it seems like lip service, 
because the document is heavily biased towards RTP.

Only in the context of the transport protocol is it possible to know 
what to do with the address and port. A middlebox looking at SDP cannot 
do anything useful to influence the communication in any way without 
understanding the protocol identifier and the semantics attached to it. 
For instance, no matter what else we do, a middlebox that doesn't 
understand "msrp" as a transport protocol identifier will not be able to 
open a pinhole thru a firewall - it won't know whether it is looking at 
a TCP address/port, a UDP address/port, or something else. There in 
nothing in the protocol identifier that would permit it to guess that.

And those components that *do* understand the protocol identifier need 
to understand *all* the associated semantics, and the attributes that 
convey it. Once you assume they do, then it doesn't matter that the c= 
line or the port on the m= line is irrelevant.

> like this approach even if we can make this work.)

Have you gone thru the exercise to see if they all work for comedia?

At a superficial level I see no reason why they wouldn't. Certainly it 
should be no issue for label, and the generic mechanism for 
preconditions should also be unaffected.

The establishment of QoS itself clearly is dependent on the kind of 
transport that is in use. I think there may indeed be some problems with 
any connection oriented transport, such as defined by comedia. This is 
highly intertwined with the semantics of the transport, and only 
incidentally with the specifics of the sdp notation used to specify the 
connection establishment parameters.

> MSRP motivates relays primarily by NAT/firewall traversal.

This is one of the reasons. But there is a general understanding that 
enterprises may require a policy engine in the media path for IM for 
other reasons as well.

Also, unlike voice, it is common to have several concurrent IM sessions 
open. Some endpoints wish to multiplex the sessions over a single 
connection. Because competing protocols do this it is desirable to 
retain this as a possibility.

> intermediary). 

We have worked hard to retain this as the preferred path when possible 
and permitted by policy. However,

 > Then, we would not really need multiplexing
> different)

I don't see why this is conceptually different.
Are you suggesting we invent a different solution for this case?

 > and a single m=/c= line would be sufficient

We have been down that path - its probably been two years now, when that 
was the assumed solution, until we found a multitude of reasons why it 
wouldn't work.

Remember, this is at least our 3rd (depending on how you count) attempt 
to produce a solution that meets our needs. If you didn't walk the path 
with us, then please don't discount all the work we did before arriving 
at the solution we have.

> we would be done with it.

I think it would be easy to argue that this is better than ICE, and is 
an option specifically because we have no backward compatibility issues 
to deal with.

There are enough reasons for relays, besides NATs and FWs, that I don't 
imagine they will go away any time soon. In any case, I expect to be 
dead before NATs and FWs are gone.

> instead of having the basic version designed as a special

If you want to take up the general case, fine. But we don't have the 
time. MSRP is long overdue. If it is *ever* to be adopted we need to get 
it out *soon*.

> with another one every week.

I don't think we know how to do that, and I doubt there is a quorum to 
work on that problem. The main issue is that to multiplex, you need to 
have addressing associated with the chunks that are being multiplexed. 
We could do that in MSRP because we defined the protocol. How would you 
do that for an unspecified transport protocol?

> rather than a detailed discussion about a partial technical

We have a sufficient solution for our needs. It would be helpful to have 
suggestions on how to *improve* this, rather than suggestions for how we 
could delay msrp for another couple of years.

Also, I thought there was a goal to minimize work on SDP. Is it really 
worth investing in a general mechanism that likely won't be used again?

I have been looking thru sdp-new-23 carefully for specifics that relate 
to the problems being discussed. I will post another message shortly 
with the results of that. Perhaps I can propose something that will be 
considered more in keeping with the "philosophy" of sdp.

	Paul

>> requested, a middlebox without specific knowledge of msrp will not 
>> know what to do: is the tcp, udp, rtp, or what?
>>
>> And in the case of msrp, the msrp relay *is* the middlebox, and the 
>> sdp syntax has been designed specifically to accomodate it.
>>
>> I still don't buy this. There is no issue of *parsing* the SDP. 
>> Nothing we have done is inconsistent with SDP parsing.
>>
>> I think the issue you are alluding to must be more to "implementing" 
>> SDP to a greater extent than just parsing it. But in all cases the 
>> semantics are a function of the particular transport. Its not clear to 
>> me that are any standard semantics.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Jan 2005 15:18:23 -0500

I have been looking carefully at sdp-new-23 for further enlightenment on 
this discussion. The following are interesting:

------------

Section 4.1:

   "For unicast IP sessions, the following are conveyed:

    o  The remote address for media

    o  The remote transport port for media

    The semantics of this address and port depend on the media and
    transport protocol defined.  By default, this SHOULD be the remote
    address and remote port to which data is sent.  Some media types MAY
    redefine this behaviour, but this is NOT RECOMMENDED."

The above is already somewhat suspect for TCP (e.g. comedia), because 
the address and port are not those to which data is sent, but instead is 
the remote address with which a connection is (sometimes) established. 
It seems to me that the above shows a strong bias towards UDP and RTP, 
and must be taken with a large grain of salt for transports that are 
dissimilar from those.

I think there may be some question as to whether it is even proper to 
describe an MSRP session as a "unicast IP session", since it may be 
multiplexed with other MSRP sessions on a single TCP connection.

----------------

Section 5.7 (c=):

   "The first sub-field ("<nettype>") is the network type, which is a
    text string giving the type of network.  Initially "IN" is defined to
    have the meaning "Internet", but other values MAY be registered in
    the future (see Section 8).

    The second sub-field ("<addrtype>") is the address type.  This allows
    SDP to be used for sessions that are not IP based.  This memo only
    defines IP4 and IP6, but other values MAY be registered in the future
    (see Section 8).

    The third sub-field ("<connection-address>") is the connection
    address.  OPTIONAL sub-fields MAY be added after the connection
    address depending on the value of the <addrtype> field."

The above textual description is not entirely in line with the syntax. 
In particular, while the above says additional subfields may follow the 
connection address depending on the value of <addrtype>, the syntax 
makes no provision for this.

   "When the <addrtype> is IP4 and IP6, the connection address is defined
    as follows:

    o  If the session is multicast, the connection address will be an IP
       multicast group address.  If the session is not multicast, then
       the connection address contains the unicast IP address of the
       expected data source or data relay or data sink as determined by
       additional attribute fields.  It is not expected that unicast
       addresses will be given in a session description that is
       communicated by a multicast announcement, though this is not
       prohibited."

The above seems to assume that the data source, relay, or sink can be 
identified by the connection address (presumably in conjunction with the 
port), and that attributes simply specify whether it is a source, relay, 
or sink. The possibility doesn't seem to have been considered that there 
might be multiple sinks at the same address/port that must be identified.

There is however the possibility of defining a new net type or address 
type that would fit our needs, permitting a complete identification to 
be included in the c-line. Assuming the problem with additional 
subfields were corrected, a possible accomodation might be to 
reformulate the "path" attribute as a c-line with a new addrtype, such as:

     c=IN MSRP-PATH <msrp-url> <msrp-url> ...

where "MSRP-PATH" is a new addrtype, the first msrp-url is the 
<connection-address> (a newly defined form of <extn-addr>), and the 
remaining urls in the path are "additional subfields".

This would arguably be more in the spirit of SDP, but for compatibility 
purposes I don't find it nearly as friendly as what is currently defined.

-----------------

Section 5.13 (a=):

   "Attribute interpretation depends on the media tool being invoked.
    Thus receivers of session descriptions should be configurable in
    their interpretation of session descriptions in general and of
    attributes in particular."

The above provides a great deal of lattitude. But there is little 
clarity about what how "media tools" should behave with things they have 
not been configured for. (There is the general requirement that a-lines 
not understood must be ignored. I don't believe there is any similar 
requirement re transport protocol identifiers in the m-line.

Rather than worrying about the particular usage of the c-line and port 
with the msrp protocol, I think it would be more worthwhile to specify 
processing when encountering a protocol that is not understood.

-----------------

Section 5.14 (m=):

   "<port> is the transport port to which the media stream is sent.  The
       meaning of the transport port depends on the network being used as
       specified in the relevant "c=" field, and on the transport
       protocol defined in the <proto> sub-field of the media field.
       Other ports used by the media application (such as the RTCP port
       [18]) MAY be derived algorithmically from the base media port or
       MAY be specified in a separate attribute (for example "a=rtcp:" as
       defined in [21])."

So the meaning of the port depends on the transport protocol. Since we 
are defining a new transport protocol, we get to define the meaning of 
the port with that protocol.

      "The combination of ports specified in "m=" lines and IP addresses
       specified in "c=" lines MUST comply with the following rules for
       RTP-based media streams (other protocols SHOULD define similar
       rules):"

So the provided rules do not apply in our case, and we should define 
appropriate ones that do apply to our usage.

(However there are also other rules in the offer/answer protocol that 
also affect this, and that may not have been made conditional on 
transport protocol.)

      "Two media sessions with the same transport address indicate
       alternatives for the same media stream, i.e.  all profiles, media
       types, and payload types provided in any of the "m=" lines are
       valid."

The way the text is formatted (following the rules mentioned above), 
this does not appear to be scoped by the transport protocol, and so 
would seem to be intended to apply regardless of transport protocol.

If this indeed applies for new transport protocols (such as msrp), then 
it constrains how we use the connection-address and port. If we were to 
follow the suggestion to insert the IP address from the first path entry 
  in the c-line, and the insert the port into the m-line, then two msrp 
sessions with the same next hop would be treated as alternatives, which 
is not correct. This is not a problem as we currently have things 
specified, because we require unique ports be used, even though they are 
ignored.

=======================================================================

To fix the problem that the syntax doesn't support the text in allowing 
additional subfields following connection-address depending on addrtype, 
I would propose the following change to the syntax:

old:
       extn-addr =      non-ws-string

new:
       extn-addr =      non-ws-string *(SP non-ws-string)

Then, using that, I propose the following SDP extensions to support 
msrp. (It is my impression that these can be in the msrp draft rather 
than in sdp-new):

old:
       unicast-address = IP4-address / IP6-address / FQDN / extn-addr

new:
       unicast-address = IP4-address / IP6-address / FQDN
                       / msrp-path ; valid for addrtype of "msrp-path"
                       / extn-addr

        Also, define "MSRP-PATH" as a new <addrtype>.
        (Not part of syntax.)

Then the c-line replaces the path attribute. For example:

- as currently proposed:
     v=0
     o=alice 2890844526 2890844527 IN IP4 alice.example.com
     s=
     c=IN IP4 alice.example.com
     m=message 9 msrp *
     a=accept-types:text/plain
     a=path:msrp://a.example.com:7394/2s93i;tcp

- with info replicated in c- and m-:
     v=0
     o=alice 2890844526 2890844527 IN IP4 alice.example.com
     s=
     c=IN IP4 a.example.com
     m=message 7394 msrp *
     a=accept-types:text/plain
     a=path:msrp://a.example.com:7394/2s93i;tcp

- with new c- format:
     v=0
     o=alice 2890844526 2890844527 IN IP4 alice.example.com
     s=
     m=message 9 msrp *
     c=IN MSRP-PATH msrp://a.example.com:7394/2s93i;tcp
     a=accept-types:text/plain

Another example with relays and multiple sessions:

- as currently proposed:
     v=0
     o=alice 2890844526 2890844527 IN IP4 alice.example.com
     s=
     c=IN IP4 alice.example.com
     m=message 9 msrp *
     a=accept-types:text/plain
     a=path:msrp://relay.example.com:9000/hjdhfha;tcp  \
      msrp://a.example.com:7394/2s93i;tcp
     m=message 10 msrp *
     a=accept-types:text/plain
     a=path:msrp://relay.example.com:9000/hjdhfha;tcp  \
      msrp://b.example.com:1234/fuige;tcp

     (Note the use of different port numbers. This makes the
      media streams independent of one another even though the
      address is otherwise the same. It can be used because the
      port is ignored.)

- with info replicated in c- and m-:
     v=0
     o=alice 2890844526 2890844527 IN IP4 alice.example.com
     s=
     m=message 9000 msrp *
     c=IN IP4 relay.example.com
     a=accept-types:text/plain
     a=path:msrp://relay.example.com:9000/hjdhfha;tcp  \
      msrp://a.example.com:7394/2s93i;tcp
     m=message 9000 msrp *
     c=IN IP4 relay.example.com
     a=accept-types:text/plain
     a=path:msrp://relay.example.com:9000/hjdhfha;tcp  \
      msrp://b.example.com:1234/fuige;tcp

     (Note that this doesn't work right! We have two media
      sessions with the same transport address, but which
      are not alternatives.)

- with new c- format:
     v=0
     o=alice 2890844526 2890844527 IN IP4 alice.example.com
     s=
     m=message 9 msrp *
     c=IN MSRP-PATH msrp://relay.example.com:9000/hjdhfha;tcp  \
      msrp://a.example.com:7394/2s93i;tcp
     a=accept-types:text/plain
     m=message 9 msrp *
     c=IN MSRP-PATH msrp://relay.example.com:9000/hjdhfha;tcp  \
      msrp://b.example.com:1234/fuige;tcp
     a=accept-types:text/plain

     (Note that here I am assuming we can use port 9 all the time,
      because the media sessions have different values for the
      c-line.)

Is this better than what is currently proposed in 
draft-ietf-simple-message-sessions-09? Debatable.

Does it come closer to the spirit of SDP? Also debatable.

	Paul

---

From: prarch <[email-masked]>
Date: Tue, 04 Jan 2005 21:36:22 -0500

A new start up company located in New York, NY in VoIP/Telephony software 
space is looking for software architects and developers.

  1.. Network Management Software product architects
  2.. SNMP/MIB architects and developers
  3.. Voice application product architects
  4.. Voice protocol architects and developers
  5.. Application GUI architects and developers
  6.. Technical marketing and product engineering
  7.. Sales engineers

Please send your resume to [email-masked]

----- Original Message ----- 
From: "Paul Kyzivat" <[email-masked]>
To: "Colin Perkins" <[email-masked]>
Cc: "Joerg Ott" <[email-masked]>; "Adam Roach" <[email-masked]>; 
<[email-masked]>; "Simple WG" <[email-masked]>
Sent: Monday, January 03, 2005 11:06 PM
Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern

> For a middlebox to work with this, it must understand the *semantics*, not 
> just the syntax. Even if we were to use the m- and c- lines as requested, 
> a middlebox without specific knowledge of msrp will not know what to do: 
> is the tcp, udp, rtp, or what?
>
> I still don't buy this. There is no issue of *parsing* the SDP. Nothing we 
> have done is inconsistent with SDP parsing.
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 04 Jan 2005 19:35:09 -0500

> 1.  Need for Relays
 
I view the primary need for relays was around logging and policy control.
Things like filtering for viruses. People have allowed IM to do things like
email and expect to be able to apply similar policy and control to it.
Luckily I'm not aware of any reported virus sent over T.38 yet but there are
virus that can propagate over IM.

Systems apply policy to the signaling of all the media - things like who can
talk to who. However they don't apply policy to the semantic content of
audio or video because the state of the art does not allow for automatic
interpretation of it well enough to apply policy. However, text based media
such as IM and email people do want to apply policy to the content.
Brokerage firms filter on key words that can be sent from certain types of
users to others. Many people check for viruses.

If this is used only for NAT traversal, the exit mechanism is the same as
STUN where devices that were not behind a NAT just do not use a relay. The
behave wg is having pretty good luck forming peer to peer TCP connections
between endpoints that are both behind NATs so it's even hopeful that relays
would not always be needed even if there still were NATs.

The motivation text in the document may need some update - there were many
long threads on the need for relays and I'm not sure that the document
captured all that. Once the WG all agreed they were needed, we were pretty
worn down on documenting all the detail of how we came to that decision.

---

From: prarch <[email-masked]>
Date: Tue, 04 Jan 2005 21:37:37 -0500

---

From: Ben Campbell <[email-masked]>
Date: Thu, 6 Jan 2005 12:21:30 -0600

On Jan 4, 2005, at 2:18 PM, Paul Kyzivat wrote:

[...]

[Lots of text removed concerning moving the MSRP path from an a-line 
into the c-line]

> Does it come closer to the spirit of SDP? Also debatable.

It also seems like it would also have a higher chance of breaking 
existing parsers than the a-line attribute approach.

[...]