Subject: [MMUSIC] Question on sdp-new

From: "Elwell, John" <[email-masked]>
Date: Thu, 13 Oct 2005 12:10:39 +0100

Would the following SDP be legal?

   v=...
   o=...
   s=...
   c=...
   t=...
   m=audio 62986 RTP/SAVP 0 4 18
   a=rtpmap:0 PCMU/8000
   a=rtpmap:4 G723/8000
   a=rtpmap:18 G729/8000
   a=key-mgmt:.....
   m=audio 62986 RTP/AVP 0 4 18
   a=rtpmap:0 PCMU/8000
   a=rtpmap:4 G723/8000
   a=rtpmap:18 G729/8000

Note that the two media have the same port and thus the same transport
address. In 6.15 of sdp-new there is a list of conditions in which two media
may use the same transport address. It is not clear to me whether condition
3 is violated: "If two media sessions have the same transport address, they
SHOULD operate under the same RTP profile.  The sessions MAY use two
different RTP profiles only if those profiles are specifically designed to
be compatible."

Do the different transports (RTP/SAVP and RTP/AVP) constitute different RTP
profiles? If so, can we regard the two protocols as "designed to be
compatible"? Note that in a SIP context, if an SDP offer contains the code
above, the offerer would need to be prepared to receive either SRTP or RTP
on the same port until the SDP answer arrives, perhaps using the
authentication tag to distinguish SRTP from RTP.

This form of SDP seems to be useful where the offerer is prepared to accept
either SRTP or RTP (perhaps indicating to the user whether the resulting
audio is secure). By using the same transport address the answerer should
treat the two media as alternatives and presumably should reject one of
them. By using two different transport addresses the media would be treated
separately and the answerer might accept both, which might not be what is
wanted.

Some clarification on this in the next version might be useful (I note that
some comments have been raised so presumably a next version will be produced
at some stage).

The problem of distinguishing between RTP and SRTP on the same port (or even
between different SRTP streams on the same port that use different keys as a
result of using different key management methods) could possibly be worked
around by assigning different payload type numbers, e.g.:

   v=...
   o=...
   s=...
   c=...
   t=...
   m=audio 62986 RTP/SAVP 0 4 18
   a=rtpmap:0 PCMU/8000
   a=rtpmap:4 G723/8000
   a=rtpmap:18 G729/8000
   a=key-mgmt:.....
   m=audio 62986 RTP/AVP 97 98 99
   a=rtpmap:97 PCMU/8000
   a=rtpmap:98 G723/8000
   a=rtpmap:99 G729/8000

However, I am not sure whether this would violate the conditions for using
the same transport address. Also I am not sure of the legality of using
dynamic payload numbers for encodings for which static payload numbers exist
or whether this would be supported by products in the field.

John

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

---

From: Colin Perkins <[email-masked]>
Date: Thu, 13 Oct 2005 12:29:26 +0100

On 13 Oct 2005, at 12:10, Elwell, John wrote:
> Note that the two media have the same port and thus the same  
> transport address. In 6.15 of sdp-new there is a list of conditions  
> in which two
               ^^^^ 5.14?

> media may use the same transport address. It is not clear to me  
> whether condition 3 is violated: "If two media sessions have the  
> same transport address, they SHOULD operate under the same RTP  
> profile.  The sessions MAY use two different RTP profiles only if  
> those profiles are specifically designed to be compatible."
>
> Do the different transports (RTP/SAVP and RTP/AVP) constitute  
> different RTP profiles?

Yes. See http://www.iana.org/assignments/rtp-parameters under the  
"RTP Profile Names" section.

> If so, can we regard the two protocols as "designed to be compatible"?

Not in this case, since RTP/AVP clients will not understand RTP/ 
SAVP.  The "designed to be compatible" is intended for inter-working  
of profiles such as RTP/AVP and RTP/AVPF, where a client  
understanding one can interoperate with clients understanding the  
other profile.

> Note that in a SIP context, if an SDP offer contains the code  
> above, the offerer would need to be prepared to receive either SRTP  
> or RTP on the same port until the SDP answer arrives, perhaps using  
> the authentication tag to distinguish SRTP from RTP.
>
> This form of SDP seems to be useful where the offerer is prepared  
> to accept either SRTP or RTP (perhaps indicating to the user  
> whether the resulting audio is secure). By using the same transport  
> address the answerer should treat the two media as alternatives and  
> presumably should reject one of them. By using two different  
> transport addresses the media would be treated separately and the  
> answerer might accept both, which might not be what is wanted.
>
> Some clarification on this in the next version might be useful (I  
> note that some comments have been raised so presumably a next  
> version will be produced at some stage).

There are no plans to update sdp-new at this time.

> The problem of distinguishing between RTP and SRTP on the same port  
> (or even between different SRTP streams on the same port that use  
> different keys as a result of using different key management  
> methods) could possibly be worked around by assigning different  
> payload type numbers, e.g.:
>
>    v=...
>    o=...
>    s=...
>    c=...
>    t=...
> However, I am not sure whether this would violate the conditions  
> for using the same transport address.

The RTP profiles are still not compatible, so you don't solve the  
problem.

> Also I am not sure of the legality of using dynamic payload numbers  
> for encodings for which static payload numbers exist or whether  
> this would be supported by products in the field.

This is valid.

Colin

---

From: Mark Baugher <[email-masked]>
Date: Thu, 13 Oct 2005 06:00:12 -0700

We should consider whether we want to standardize SRTP inter-operation 
with legacy RTP systems.  I recall reading a draft from Cullen Jennings 
that addressed this problem in SIP signaling using a 
multipart/alternative MIME encoding of a SIP message.  This reduces the 
problem to the legacy RTP systems that also don't recognize 
mulitipart-alternative SIP messages.  Cullen should correct me if my 
summary is wrong.

Mark
On Oct 13, 2005, at 4:10 AM, Elwell, John wrote:

> different RTP
> (or even

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Oct 2005 10:57:36 -0700

> understanding one can interoperate with clients understanding the  

What do you mean by 'interoperate'?  My read of -avt-rtcp-feedback-11 is
that both sides of an offer/answer would need to understand the RTP/AVPF
profile.  Overall I'm very worried about this profile explosion especially
when we introduce non-UDP transports for RTP.

-d

---

From: Colin Perkins <[email-masked]>
Date: Thu, 13 Oct 2005 19:08:28 +0100

On 13 Oct 2005, at 18:57, Dan Wing wrote:
> profile.

See section 5 of draft-ietf-avt-rtcp-feedback-11.txt

> Overall I'm very worried about this profile explosion especially

Agreed. This is certainly a problem (although much of the difficultly  
comes due to the limitations of SDP, rather than the proliferation of  
RTP profiles as such).

Colin

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Oct 2005 11:47:23 -0700

>> that both sides of an offer/answer would need to understand 
>> the RTP/AVPF profile.
> 

Yes, I read that before responding.  But I'm still failing to grasp how an
AVPF-unaware endpoint would do anything but reject an m= line containing
AVPF.  Specifically, if my offer says:

  ...
  m=audio 49170 RTP/AVPF 0
  ...

and the answerer only understands RTP/AVP, the answer will contain only "m="
for that media line (that is, that media line is rejected).  I'll have to
send another offer with RTP/AVP, under the assumption the reason it was
rejected was AVPF.  This gets really messy

It's the same problem of sending RTP/SAVP -- the answer won't understand
"SAVP" and will reject that media line.

> Agreed. This is certainly a problem (although much of the 
> difficultly comes due to the limitations of SDP, rather than 
> the proliferation of RTP profiles as such).

We need a heart-to-heart on how to solve that -- SDPnew or other mechanisms,
such as multipart MIME or clearly defining semantics of port overlaying in
SDPold (which started this thread).  

SDPnew will require multipart/alternative unless we want to incur 2x the
call processing overhead (and associated call setup delays) with introducing
SDPnew.

-d

---

From: Randell Jesup <[email-masked]>
Date: 13 Oct 2005 21:51:24 -0400

"Dan Wing" <[email-masked]> writes:
>for that media line (that is, that media line is rejected). 

        Actually "m=audio 0 RTP/AVPF" is the correct way, but yes,
you're correct - it should be rejected.  If they had wanted
AVP-understanding UAs to accept AVPF calls, it should have been an a=
line or some other mechanism.

        The only way an AVP and an AVPF will be talking (in those modes) is
if one of them "cheats" or is just plain so broken then don't check the
profile - so in a large way, section 5 is irrelevant (modulo cheating by
the answerer).

>I'll have to send another offer with RTP/AVP, under the assumption the
>reason it was rejected was AVPF.  This gets really messy
>

        Combine the two (yielding AVP, AVPF, SAVP and SAVPF), and you can be
negotiating INVITEs and re-INVITEs until the cows come home.  Let's pray
there aren't any more...  Well, there's TCP transport, and...  
Sigh.

>call processing overhead (and associated call setup delays) with introducing

        Yes!!!!!

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Oct 2005 13:17:06 +0200

Hi,

I think Joerg, Colin and Me have discussed that a solution to the issue 
you describe below is to provide a grouping of media lines mechanism to 
indicate that the two offered profiles with the same port is actually 
alternatives and one of these need to be selected.

This issue will soon become available also in the SRTP side where SAVP 
and SAVPF will be interoperable in the same session.

However this solution still has the issue that we need to express 
several m= lines with the same port.

Cheers

Magnus

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Oct 2005 08:57:15 -0400

Randell Jesup wrote:

> negotiating INVITEs and re-INVITEs until the cows come home.  

In general this isn't a viable alternative. In sip a request may be sent 
out and forked to multiple candidate recipients, with differing 
capabilities. If you don't simultaneously offer all your options to all 
the candidates you may end up communicating with a sub-optimal candidate.

The example that has been given before is when one candidate is a phone 
and a secondary candidate is a voicemail system. The voicemail system 
may be very rich in capabilities, while the phone is not. If the first 
m-line you try is unacceptable to the phone, the call will be handled by 
the VM system and you won't have a chance to try another possibility 
that the phone could handle.

Another approach would be for the phone to answer the unacceptable 
offer, refusing all the media but accepting the call. Then it could 
reinvite with another possibility. But that is no better, because at the 
time it has to accept it cannot predict if it will be successful. Unless 
it will be successful it should not alert and answer.

I think the only way that might allow successive tries to work would be 
to do so in conjunction with preconditions. There could be a new 
precondition (acceptable-media?) included with an offer. Continued 
rounds of offer/answer could be tried, without alerting, until some 
combination of media was found to be acceptable to both ends. But the 
use of preconditions hasn't proved to be very popular, so I think it 
would be preferable to find a way to provide all the options up front.

	Paul

---

From: Colin Perkins <[email-masked]>
Date: Fri, 14 Oct 2005 15:33:49 +0100

> "SAVP" and will reject that media line.

Sure, but since RTP/AVP and RTP/AVPF are compatible, you can offer  
both with the same port, and have the receiver choose which to accept  
(per sdp-new-25 section 5.14). Not ideal, but I think it solves this  
case.

Colin

---

From: Randell Jesup <[email-masked]>
Date: 14 Oct 2005 11:37:16 -0400

Paul Kyzivat <[email-masked]> writes:
>capabilities. If you don't simultaneously offer all your options to all the
>candidates you may end up communicating with a sub-optimal candidate.
>
>The example that has been given before is when one candidate is a phone and
>a secondary candidate is a voicemail system. The voicemail system may be
>very rich in capabilities, while the phone is not. If the first m-line you
>try is unacceptable to the phone, the call will be handled by the VM system
>and you won't have a chance to try another possibility that the phone could
>handle.

        That problem is pretty orthogonal to this one I think - you're
introducing a number of race conditions and side-issues.

>Another approach would be for the phone to answer the unacceptable offer,
>refusing all the media but accepting the call. Then it could reinvite with
>another possibility. But that is no better, because at the time it has to
>accept it cannot predict if it will be successful. Unless it will be
>successful it should not alert and answer.

        Like I said, lots of re-invites.  And you lose all forking
abilities.  And what if you need to do this negotiation with two endpoints
of a fork?  And serious added delay to call setup time.  Etc.  Not a
workable solution.

>I think the only way that might allow successive tries to work would be to
>do so in conjunction with preconditions. There could be a new precondition
>(acceptable-media?) included with an offer. Continued rounds of
>offer/answer could be tried, without alerting, until some combination of
>media was found to be acceptable to both ends. But the use of preconditions
>hasn't proved to be very popular, so I think it would be preferable to find
>a way to provide all the options up front.

        Procondition has the problems with forking, etc and call setup
times as well.  Perhaps less of them, but I don't think so.

        Some form of grouping (see the grouping spec) or alternatives
(via multipart or indirectly via port numbers) is needed.  I dislike the
port-number approach because you lose the information about relationships
beyond strict alternatives for a single media line.  For example, something
like "I'll do video in H263 at 368K with 8K audio, or I'll do H.264 at 128K
with several audio codecs up to 128K" can't easily be expressed because
of the linkage between different media alternatives.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Oct 2005 12:44:41 -0400

Randell,

You are the second person I have heard from who didn't get the point I 
was trying to make. So I must not have made it very well.

I was discussing the suggested possibility of more invites (or offers 
and answers without invites) merely to show that they aren't a good 
solution for the problem.

IMO the only good solutions are ones that provide all the alternatives 
at once. The multipart/alternative approach is one of these. Various 
notations in a single SDP offer are potentially another, though it seems 
there is no currently legal way to say the right thing.

	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 19 Oct 2005 15:07:28 -0400

We've had the discussion around whether to allow port (i.e. transport 
address) reuse between multiple media lines a few times in the past 
(e.g. the thread "Multiple 'm' lines with the same port number" in 
2003/04), and various concerns were expressed around that. To recap, the 
major concerns were:

1. Backwards compatibility issues with RFC 2327 implementations which 
did not specify this .

2. Potential for multiplexing misuse when using different types of media 
streams on the same transport (e.g. audio and video)

3. Consistency with RFC 3264 offer/answer procedures. For example 3264 
states
<quote>
    If multiple media streams of the same type are present in an offer,
   it means that the offerer wishes to send (and/or receive) multiple
   streams of that type at the same time. 
</quote>
Other 3264 concerns have to do with matching of media streams in an 
updated offer/answer exchage (3264, Section 8).

4. Generally getting into a gray area of what this means. For example, 
can we now negotiate media streams with asymmetric codecs (one "m=" 
marked "sendonly", another marked "recvonly") ? How do we deal with all 
the other potential parameters that may differ between the two "m=" 
lines (fmtp parameters, RTCP bandwidth, etc.) ?

I guess I missed the text that was added to sdp-new (in the -21 version) 
on this which currently (-25) reads:
<quote>
      1.  If two media sessions have the same transport address (i.e.
          identical IP address and port numbers), the associated payload
          types (e.g. given in the "a=rtpmap:" attribute) MUST NOT be in
          conflict, i.e. the same payload type MUST NOT be mapped to
          different media types.

      2.  If two media sessions have the same transport address, they
          MUST use compatible media (e.g. both audio or both video).

      3.  If two media sessions have the same transport address, they
          SHOULD operate under the same RTP profile.  The sessions MAY
          use two different RTP profiles only if those profiles are
          specifically designed to be compatible.

      4.  If two media sessions have the same RTP transport address,
          they MUST also use the same RTCP address and vice versa.

      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.
</quote>

Taking a look at the concerns above, the added text does little to 
address any but the second one (and even there, it's not entirely clear 
what "compatible media" actually means, e.g. is T38 fax relay compatible 
with G.711 audio ?) In summary, I have serious concerns with the current 
text on this in sdp-new-25 and belive it should either be removed or 
reworked significantly.

I do however support the general idea of trying to solve the problems 
that lead to the above text, but explicit signaling mechanisms (e.g. 
using grouping of media lines as Magnus suggested) and more extensive 
treatment of the issues above is needed for this IMO. If there is group 
and chair interest in this, I'd be happy to help out.

-- Flemming

---

From: Randell Jesup <[email-masked]>
Date: 20 Oct 2005 10:32:44 -0400

>4. Generally getting into a gray area of what this means. For example, can
>   we now negotiate media streams with asymmetric codecs (one "m=" marked
>   "sendonly", another marked "recvonly") ? How do we deal with all the
>   other potential parameters that may differ between the two "m=" lines
>   (fmtp parameters, RTCP bandwidth, etc.) ?

        Certainly there's a need to handle alternatives - starting with
profiles (AVP/AVPF and SAVP/SAVPF).  Offer-answer doesn't really allow for
asymmetric negotiation - for example, different codec profiles/resolutions/
etc in different directions (on the same payloads/ports).

        In theory if both sides are willing to accept all variants they
can be put on different payloads of the same m= line:

m=video 1234 RTP/AVP 100 101 102
a=rtpmap:100 xyz/90000
a=rtpmap:101 xyz/90000
a=rtpmap:102 xyz/90000
a=fmtp:100 resolution=320x240
a=fmtp:101 resolution=640x480
a=fmtp:102 resolution=1920x1080

And then, if the other side responds without rejecting any payloads, either
side can send any resolution (or switch!).  However, it's impossible
without some type of alternation mechanism to have one side say "I can
receive only 320x240" while still sending 640x480.  Partly this is a result
of the specific specs for different RTP payloads, but it's a common
problem.

        Multiple m= lines with the same port could allow selection, but I
imagine you'd be required to reject the other m= lines for the same port -
right?  This is almost mandatory, unless there's no overlap of payloads
(see below). If so, it doesn't solve the above problem.

        The other case I think you're mentioning is:

m=audio 1234 RTP/AVP 0 8
a=recvonly
m=audio 1234 RTP/AVP 0
a=sendonly

        Or something like that.  In this case, he'll receive 0 and 8, but
can only send 0.  This might be a way to solve the case above IF you're
allowed to accept two m= lines for the same port if one is sendonly and one
is recvonly.  (What about "inactive" though?)

        Even the various "grouping" mechanisms proposed may not solve this
well currently - though they can if you can live with opening more ports
(though this also breaks symmetric RTP and will cause NAT/firewall issues).
(i.e. use m= sendonly and m= recvonly lines with different port values,
assuming the other side is smart enough to know it can accept
both.... which currently is not bloody likely).

>I guess I missed the text that was added to sdp-new (in the -21 version) on
>this which currently (-25) reads:
>
><quote>

        Ok.  Matches some of my comments above, though in theory you could
share payloads if one was recvonly and one was sendonly, but you don't
have to.

>      types, and payload types provided in any of the "m=" lines are

        It's a little unclear what this means.  I assume you can't combine
things across the media lines (the a=keymgt for the first m= can't be used
in a payload for the second m=, etc).

        The specs in sdp-new would appear to allow for a response to do
this:

Offer:
m=video 1234 RTP/AVP 100
a=rtpmap:100 xyz/90000
a=fmtp:100 resolution=320x240
m=video 1234 RTP/AVP 101
a=rtpmap:101 xyz/90000
a=fmtp:101 resolution=640x480

Answer:
m=video 1234 RTP/AVP 100
a=rtpmap:100 xyz/90000
a=fmtp:100 resolution=320x240
a=recvonly
m=video 1234 RTP/AVP 101
a=rtpmap:101 xyz/90000
a=fmtp:101 resolution=640x480
a=sendonly

        Which in *theory* would allow what I talked about above.  However,
I imagine expecting clients to actually handle this (correctly!) might be
too much to ask, perhaps.  And it's a somewhat ugly solution.  It also
leads (as do a number of solutions to grouping issues) to an explosion of
m= lines, yielding HUGE SIP messages.  You can forget SIP over UDP...

        While it's not the case for the above case, variants that use m=
lines with different ports cause performance/resource issues for clients
that need to do things like ICE and TURN.

        Ugh.

-- 
Randell Jesup, Worldgate
[email-masked]

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 20 Oct 2005 10:47:55 -0400

Randell Jesup wrote:

>right? 
Unclear - offer/answer at least doesn't say anything to that effect.

> This is almost mandatory, unless there's no overlap of payloads
Right.

>(though this also breaks symmetric RTP and will cause NAT/firewall issues).
Actually, it would work just fine from a symmetric RTP and NAT/FW point 
of view (it's simply two unidirectional RTP sessions).

-- Flemming

---

From: Randell Jesup <[email-masked]>
Date: 20 Oct 2005 17:30:59 -0400

Flemming Andreasen <[email-masked]> writes:
>Actually, it would work just fine from a symmetric RTP and NAT/FW point of
>view (it's simply two unidirectional RTP sessions).

        Yes, but a main point of symmetric RTP (that helps with firewalls)
is that the outgoing traffic props open the firewall port to allow incoming
traffic.  With two one-way streams you don't really have "symmetric RTP".

http://www.voip-info.org/wiki/index.php?page=RTP+Symmetric
Plus Rosen's presentation to ietf in 2001.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 20 Oct 2005 17:56:02 -0400

Randell Jesup wrote:

>traffic.
There's a bit more to it than that since you need to actually signal the 
NATed address in your SDP to begin with (use ICE). In any case, I think 
we're on the same page here.

-- Flemming

>  With two one-way streams you don't really have "symmetric RTP".
>