Subject: [Simple] MSRP: SDP usage concern

From: Ben Campbell <[email-masked]>
Date: Tue, 7 Dec 2004 17:20:47 -0600

I sent the attached to the SIMPLE list last week. I am reposting it to  
both the SIMPLE and MMUSIC lists, as the discussion is of interest to  
both groups. If you already responded to this on the SIMPLE list or in  
private, it would be helpful if you can re-post your response to this  
thread, so everyone sees the whole discussion.

Thanks!

Ben.

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

In the DC meeting, we discussed that MSRP's SDP usage should be  
reviewed in MMUSIC, or at least by people who are more expert in SDP.   
Colin Perkins and Joerg Ott looked at this, and suggested a change.  
(Many thanks to them for taking the time, and I hope they will jump in  
and correct me if I mischaracterize anything.)

The upshot of the proposal is that the fact that MSRP ignores the  
address in the sdp c-line, and the port and proto fields in the m-line.  
Instead, MSRP gets all of this from the first URL in the path a-line  
attribute. This deviates from the traditional usage in SDP, and causes  
confusion.

The proposed change is that the destination URL be broken into the  
appropriate parts and encoded into the c-line and m-line. For example  
(leaving out lines that don't change)

  c=IN IP4 alice.example.com
  m=message 9 msrp *
  a=path:msrp://a.example.com:7394/2s93i;tcp

would become:

  c=IN IP4 a.example.com
  m=message 7394 msrp/tcp *
  a=session:2s93i

The change would only be made for the destination URL. URLs for any  
relays would be expressed the same way they are now.

The advantage of this approach is that it more closely follows the  
spirit of SDP. This will be easier to understand for people who already  
know SDP. Existing SDP code could be reused more effectively.

The disadvantage of the proposed change is, it means the way an MSRP  
client determines the destination URL would be different depending on  
whether the URL represented the final destination or a relay. Instead  
of the current approach of simply copying the path attribute value into  
the To-Path header in MSRP messages,  a client would copy the path  
header value if exists, reconstitute the destination URL from the m and  
c lines, and append the destination URL to the path header value.

So, what do people think? (I note that we actually did something  
similar to this before we added the "path" attribute. )

Thanks!

Ben.

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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 10 Dec 2004 15:41:12 -0600

I really need to get closure on this, so I'd appreciate people agreeing  
or disagreeing.

I have had off-list correspondence indicating both positions. In  
summary:

In favor of the change, I had a comment to the effect that changing SDP  
semantics to ignore the C line and the port field on the M line really  
changes it to something that is no longer SDP, and that such deviations  
are in general bad for interop.

In favor of leaving things as currently specified, I had two comments  
that decomposing URLs into the C and M lines is ugly, and that having a  
different mechanism to communicate endpoint addresses vs relay  
addresses is really ugly.

So, do people agree with one or the other position? Something  
completely different? (Hopefully the people who sent off-list  
correspondence will reply on-list if they think I mischaracterized  
either position. Actually, I hope they will repost on-list even if they  
like my summaries)

I have so far avoided interjecting my personal opinion so that I could  
do a fair summary. But, I actually tend to agree with the  
leave-things-as-specified position.

While I am sensitive to the issue of deviating from the spirit of SDP,  
I don't really buy the interoperability argument. The currently defined  
usage _does_ put "msrp" in the M line--so only consumers that  
understand what that means will be able to act on it. I assume that any  
endpoint that understands what "msrp" means will also understand how to  
use the "path" attribute.

The place that interoperability might suffer is if any non-endpoint  
needs to interpret things--which is generally not a goal. I guess can  
also see debug or monitoring tools who don't know about MSRP getting  
things wrong.

My biggest technical objection is that using a different mechanism for  
determining where to connect depending on whether you are connecting  
peer to peer or through a relay, increases the chances of implementors  
getting things wrong. And I cannot personally think of a way to handle  
relay addresses that is more in the spirit of SDP than what we  
currently have.

But in any case, I will be happy to document consensus, even if it  
disagrees with my position. But we need to close on it asap.

Thanks!

Ben.

On Dec 7, 2004, at 5:20 PM, Ben Campbell wrote:

> ----------------------------------------------------------------------- 
> -----------------------------------------
>
>
> address in the sdp c-line, and the port and proto fields in the  
> m-line. Instead, MSRP gets all of this from the first URL in the path  
> a-line attribute. This deviates from the traditional usage in SDP, and  
> causes confusion.
>
> spirit of SDP. This will be easier to understand for people who  
> already know SDP. Existing SDP code could be reused more effectively.
>
> of the current approach of simply copying the path attribute value  
> into the To-Path header in MSRP messages,  a client would copy the  
> path header value if exists, reconstitute the destination URL from the  
> m and c lines, and append the destination URL to the path header  
> value.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Dec 2004 17:31:07 -0500

Ben,

I agree with what you say below, and have no more to add now.

	Paul

Ben Campbell wrote:
> I have had off-list correspondence indicating both positions. In  summary:
> 
>> I sent the attached to the SIMPLE list last week. I am reposting it 
>> to  both the SIMPLE and MMUSIC lists, as the discussion is of interest 
>> to  both groups. If you already responded to this on the SIMPLE list 
>> or in  private, it would be helpful if you can re-post your response 
>> to this  thread, so everyone sees the whole discussion.
>>
>> Thanks!
>>
>> Ben.
>>
>> reviewed in MMUSIC, or at least by people who are more expert in 
>> SDP.   Colin Perkins and Joerg Ott looked at this, and suggested a 
>> change.  (Many thanks to them for taking the time, and I hope they 
>> will jump in  and correct me if I mischaracterize anything.)
>>
>> a-line attribute. This deviates from the traditional usage in SDP, 
>> and  causes confusion.
>>
>> path header value if exists, reconstitute the destination URL from 
>> the  m and c lines, and append the destination URL to the path header  
>> value.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 12 Dec 2004 01:30:58 -0500

Colin Perkins wrote:
> 
> Decomposing the URL into the "c=" and "m=" lines is very ugly. 
> Unfortunately, that ugliness is required if you want to use SDP. This is 
> why the SDPng work was started, to try to move to something less 
> horrible...

You state that as if it was a hard and fast written law. Is it?

It was one thing to decompose these parts of the communication address 
one time for RTP. But there was no URL for that. Now times have moved 
on, and URLs are common and useful, and they don't fit so well into this 
paradigm. Something has to adapt, but why aren't we free to have an open 
mind about where the adaptation is applied?

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Sun, 12 Dec 2004 12:59:25 +0200

I also agree with Ben here. I don't see interoperability problems, since 
MSRP implementations will need to add extra support for SDP.

I also think SDP is requiring a general mechanism to be able to indicate 
a URI as a connection address, rather than the traditional IP address + 
port number... but that is another story.

Let's keep the SDP usage in MSRP as it is now.

- Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 12 Dec 2004 14:54:17 -0500

Joerg Ott wrote:
> I agree with Colin on the ugliness issue of decomposing URLs into
> c= and m= lines.  But this is the way SDP has worked and works today.
> 
> The present discussion we are having here is about changing SDP to
> for address/URL handling in one particular case.  This does not
> strike me as something MSRP should be concerned with.
> 
> I would like to make one thing clear: we are either using existing tools
> in another document or we are building new ones.  There is nothing much
> in between.
> 
> Changing c=/m= semantics means changing SDP.  Just because the syntax
> still looks the same does not mean that it is still the same protocol.
> Any entity or generic protocol engine used to dealing with SDP m=/c=
> would no longer do the right thing.

Can you explain what sort of generic processing of SDP that would break 
as a result of this change, but would not break as a result of adding 
MSRP in a syntax you have in mind?

There is really only a minimal amount of generic processing that can be 
done for SDP as it stands. That doesn't include actual management of 
sockets, since that is all dependent on "transport". I have worked with 
an SDP "stack", and it isn't harmed in any way by the usage proposed in 
MSRP.

The work that will be needed to support MSRP will only be made more 
complex by tearing info out of a URL and pasting it into the c- and m- 
lines.

> We see this kind of approach quite often -- by far too often -- over
> the past years (just think the many "uses" of SIP defined elsewhere,
> usually resulting in something "a little but not entirely unlike" SIP).
> 
> What I would like avoid is having special treatment of SDP depending
> on what the media type is (or other attributes signify).

Then why not just restrict SDP to use with RTP transports? That covers 
what it seems to have been designed for. Half the stuff defined in SDP 
is only applicable in that case. It has also been a real stretch to 
apply SDP to the offer/answer needs of SIP. Maybe that was an abuse too.

> Therefore, I strongly agree with Colin's conclusion: take SDP as is
> or leave it altogether and pursue a different path.

Right! Given that the only alternative in sight is SDPng, and apparently 
nobody as any belief that it will be adopted in our lifetimes.

	Paul

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 13 Dec 2004 10:10:06 +0100

(not as chair, but as an MSRP protocol contributor)

The objection to using the SDP c and m lines is not purely a cosmetic 
objection. We are not saying that SDP the way it is defined today is 
ugly so we want to rearrange it to look better.

We have a fundamental objection: having 2 ways to construct a next hop 
URI that depends on the entity that is the next hop is not acceptable. 
Endpoints should not be required  to have 2 engines implemented. Unless 
we are given an alternative that allows endpoint implementers to 
implement one piece of code for constructing an next hop MSRP URI, I'm 
afraid we have no choice but to keep what we have today in MSRP as is.

You telling us to go find another protocol if we don't like SDP the way 
it is today is hardly contructive. SDPng is not an option and we call 
know it.

Let me add that comedia also violates what you claim to be a 
fundamental piece of the protocol that if broken will cause the SDP 
protocol not to be SDP any longer. An argument that I don't buy. We 
have violated things before:

    - t= line does not mean anything in SIP and is set to 0 0 (which in 
SDP means that the session is permanent and unbounded).
    - s= line carries session name. It is set to - when used with SIP.

Also, quoting the SDP draft:

"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."

We are changing the semantics. As far as I understand from the quoted 
paragraph above, we are not violating anything, even-though it is not 
recommended.

I have a question to SDP stack implementers that plan to implement 
MSRP: Does the current way MSRP specifies the use of SDP (ignore the c 
line address and the m line port and instead use the attribute a=path) 
cause problems to you and requires you to do some hacking in your SDP 
stack? If so, is that acceptable or do you prefer for your MSRP 
implementation to implement two ways of contructing an MSRP URL 
depending on the what the next hop is?

Regards,
Hisham

On Dec 12, 2004, at 12:58 PM, Joerg Ott wrote:

> Joerg
>> On 10 Dec 2004, at 21:41, Ben Campbell wrote:
>>> I really need to get closure on this, so I'd appreciate people 
>>> agreeing or disagreeing.
>>>
>>> In favor of the change, I had a comment to the effect that changing 
>>> SDP semantics to ignore the C line and the port field on the M line 
>>> really changes it to something that is no longer SDP, and that such 
>>> deviations are in general bad for interop.
>>>
>>> In favor of leaving things as currently specified, I had two 
>>> comments that decomposing URLs into the C and M lines is ugly, and 
>>> that having a different mechanism to communicate endpoint addresses 
>>> vs relay addresses is really ugly.
>>>
>>> So, do people agree with one or the other position?
>> Unfortunately, that ugliness is required if you want to use SDP. This 
>> is why the SDPng work was started, to try to move to something less 
>> horrible...
>> Colin
>> 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: Colin Perkins <[email-masked]>
Date: Sat, 11 Dec 2004 12:30:12 +0000

On 10 Dec 2004, at 21:41, Ben Campbell wrote:
> that decomposing URLs into the C and M lines is ugly, and that having 
> a different mechanism to communicate endpoint addresses vs relay 

Colin

---

From: Joerg Ott <[email-masked]>
Date: Sun, 12 Dec 2004 12:58:21 +0100

Joerg

---

From: Ben Campbell <[email-masked]>
Date: Fri, 17 Dec 2004 16:17:58 -0600

> or leave it altogether and pursue a different path.

I am sensitive to the philosophical desire to keep things pure, but on 
the pragmatic side this seems to me to be a false dichotomy. We extend 
protocols all the time, for good or ill. Can you describe specific 
interoperability problems that would be introduced by the MSRP usage as 
currently described?

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?

---

From: Ben Campbell <[email-masked]>
Date: Fri, 17 Dec 2004 16:19:31 -0600

On Dec 13, 2004, at 3:10 AM, Hisham Khartabil wrote:

> Endpoints should not be required  to have 2 engines implemented. 
> Unless we are given an alternative that allows endpoint implementers 
> to implement one piece of code for constructing an next hop MSRP URI, 
> I'm afraid we have no choice but to keep what we have today in MSRP as 
> is.
>

I think Hisham expressed my concern much more precisely than I 
previously expressed it. This is exactly what I was trying to say.

> You telling us to go find another protocol if we don't like SDP the 
> way it is today is hardly contructive. SDPng is not an option and we 
> call know it.
>
>>> Unfortunately, that ugliness is required if you want to use SDP. 
>>> This is why the SDPng work was started, to try to move to something 
>>> less horrible...
>>> Colin

---

From: "Peter Ridler" <[email-masked]>
Date: Sat, 18 Dec 2004 10:16:12 -0500

I also agree with Colin and Joerg.

I will also have two SDP parse engines (one for RTP and another for MSRP).
This will complicate the code.  Computers do not care about ugly formatting
--- overall performance should be the concern (I think all text formatted
protocols are a waste of network bandwidth and memory resources -- but I'm
stuck with them). 

We should follow the standards as best we can.  If the standard does not
meet your requirements then define/use another.

Another text based protocol is draft-ietf-sipping-toip-00.txt  This fits the
SIP/SDP model nicely.

Peter

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Joerg Ott
> Sent: Sunday, December 12, 2004 6:58 AM
> To: Colin Perkins
> Cc: Simple WG; [email-masked]
> Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern
> 
> I agree with Colin on the ugliness issue of decomposing URLs 
> into c= and m= lines.  But this is the way SDP has worked and 
> works today.
> 
> The present discussion we are having here is about changing 
> SDP to for address/URL handling in one particular case.  This 
> does not strike me as something MSRP should be concerned with.
> 
> I would like to make one thing clear: we are either using 
> existing tools in another document or we are building new 
> ones.  There is nothing much in between.
> 
> Changing c=/m= semantics means changing SDP.  Just because 
> the syntax still looks the same does not mean that it is 
> still the same protocol.
> Any entity or generic protocol engine used to dealing with 
> SDP m=/c= would no longer do the right thing.
> 
> We see this kind of approach quite often -- by far too often 
> -- over the past years (just think the many "uses" of SIP 
> defined elsewhere, usually resulting in something "a little 
> but not entirely unlike" SIP).
> 
> What I would like avoid is having special treatment of SDP 
> depending on what the media type is (or other attributes signify).
> 
> Therefore, I strongly agree with Colin's conclusion: take SDP 
> as is or leave it altogether and pursue a different path.
> 
> Joerg
> 
> 
> Colin Perkins wrote:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 18 Dec 2004 13:12:15 -0500

> I will also have two SDP parse engines (one for RTP and another for MSRP).

Do you currently support anything but RTP?
How much do you expect to share between the two in the best case?

I don't think you are really talking about the parser - that isn't what 
is different. I think you are talking about implementing the connection 
semantics represented by the SDP. No matter what you do, these are 
different for RTP and MSRP.

The SDP parser that I have worked with is quite capable of handling this 
either way. It is only involved with the *syntax* of SDP.

Note that the syntax of SDP is already quite a mallable thing. Much of 
the important syntax is hidden in a-lines. MSRP has its own a-lines, and 
these need to be parsed in any case.

> meet your requirements then define/use another.

Can you suggest what you have in mind?

Its not like this is an independent decision for MSRP. MSRP is intended 
to be negotiated via SIP. And it isn't a matter of mutual exclusion - 
negotiate MSRP with sip and something other than SDP, negotiate RPT with 
sip and SDP - I expect to be negotiating *both* MSRP and RPT with the 
same sip offer/answer exchange.

It seems you must have SDPng in mind. So you are suggesting we can't 
finish MSRP until the migration to SDPng is complete?

> Another text based protocol is draft-ietf-sipping-toip-00.txt  This fits the

It fits because it runs over RTP. It doesn't meet our requirements.

It feels like you are trying to make the SDP tail wag the SIP dog.

	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 19 Dec 2004 14:38:22 -0800

I think that the MSRP folks have not clearly explained what we want to do in
SDP. We want to set up a path of multiple addresses, not just a single
address for one far end. That the protocol uses TCP or that it transports
text instead of audio I don't think should cause it to be much different.

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 26 Dec 2004 11:13:08 -0700

What will your two SDP parse engines do differently?

---

From: Adam Roach <[email-masked]>
Date: Mon, 27 Dec 2004 17:06:03 -0600

> depending on the what the next hop is?

Having implemented an SDP parser before, I can comfortably assert that 
the design I employed would require no modification at all to 
accommodate the usage proposed in MSRP.

Users of the SDP parser would need to know to look in the a= lines for 
address information -- but this requires no stack changes.

/a