John,
Without wishing to comment on the specifics of RFC 4612...
On 14 Aug 2006, at 09:13, John C Klensin wrote:
--On Monday, 14 August, 2006 03:41 -0400 "Paul E. Jones"
<paulej@xxxxxxxxxxxxxx> wrote:
Brian,
The problem with using "image" is that it would mean that a
gateway would have to do one of:
1) Close the audio session and open an image session
2) Open a second "image" session during mid-call
3) Open both an audio session and image session at the outset
For a lot of reasons, none of those options are preferred. In
the latter case, gateways just waste memory and CPU resources
servicing sockets that are never used. In the first two
cases, there is a lot of extra signaling on the wire. (For
SIP networks, and especially IMS-based SIP networks, this is
horrible due to the widespread use of UDP, slow timer
...
Paul,
I think there may be a fundamental misunderstanding, or at least
difference in understanding, about top-level media types implied
in the above. From a process standpoint, if you are just
finding out about it now, something has, IMO, failed (see my
other note). But, putting that aside...
The "text/" top-level type, and only the "text/" top-level type
has the property that one can reasonably expect to be able to
display the contents to the user without understanding the
subtype. Whether that is realistic or not, and how narrowly
that requirement should (or must) be interpreted to make
something "text/" has been widely debated in the past.
But, for all other media types, one cannot interpret them
without both the top-level type and the subtype. As far as
transmission issues are concerned, the type-subtype distinction
is largely irrelevant: there is not, meaningfully, an "audio
session" or an "image session" as far as the media type is
concerned.
This is not correct when it comes to RTP sessions signalled using
media types in SIP/SDP. In those cases, Paul is correct that the
session is negotiated to convey only one top level media type (e.g.
only audio), and switching to an image format would require a
separate session.
Discussion of why this is the case should probably happen on the AVT
mailing list, since that is the working group responsible for RTP, or
on rai-discuss.
Colin
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf