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

From: Kreuter Ruediger <[email-masked]>
Date: Wed, 30 Apr 2003 11:34:30 +0200

Sending a reinvite for a switchover from voice 
to voiceband data (incl. fax) is applicable.
But Rajesh's example below is text/t140, that 
is, we are "talking" about TTY/TDD. This is 
completely different because the transmission 
of TTY characters and voice can be mixed in
any way on a TDM line, and therefore must be
transferable in a VoIP connection too.
That is, it can be that during a connection
a sender types some characters on his TTY,
then he speeks some sentences, then he types
some characters ...
You don't really want to send re-invites
every couple of sentences, do you ?
The only practicable way is to mix text/t140 
and audio/G7xx the same way as audio/RFC2833 
and audio/G7xx.

Another good reason to mix these media types
is performance. Depending on the TTY terminal
type, a TTY transmission can start without a
startup sequence as it is used by fax or data
modem transmissions. Therefore the switch over
to text/t140 must be very fast otherwise you
loose characters. And the sending person doesn't
know if his characters were lost or not.
Now imagine a deaf person calling an emergancy
line ...
Sending a re-invite to switch over the connection
may use up a second in a heavy loaded network.

Regards,
Ruediger Kreuter
[email-masked]

> -----Ursprüngliche Nachricht-----
> Von: Jonathan Rosenberg [mailto:[email-masked]]
> Gesendet: Dienstag, 29. April 2003 01:11
> An: Flemming Andreasen
> Cc: Stephen Casner; Rajesh Kumar; Colin Perkins; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Betreff: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number
> 
> 
> inline.
> 
> Flemming Andreasen wrote:
> > 
> > Stephen Casner wrote:
> > 
> > 
> >>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.
> >>
> > 
> > 
> > We also seem to be entering a bit of a gray area here in 
> terms of offer/answer
> > (RFC 3264). It's not clear that the definition of "m=" 
> lines and media streams
> > allow for something like this; for sure the parties would 
> have to recognize that
> > the two "m=" lines in fact are one media stream and hence 
> should not be sending
> > to "both" at the same time.  However, I'm not aware of such 
> behavior being
> > specified anywhere.
> 
> Using two m lines to represent alternate encodings for a 
> stream is not 
> consistent with the offer/answer model, IMHO. RFC 3264 has mechanisms 
> for transitioning from audio to fax, for example, but these require a 
> re-invite to do:
> 
> 8.3.3 Changing Media Types
> 
>     The media type (audio, video, etc.) for a stream MAY be 
> changed.  It
>     is RECOMMENDED that the media type be changed (as opposed 
> to adding a
>     new stream), when the same logical data is being 
> conveyed, but just
>     in a different media format.  This is particularly useful for
>     changing between voiceband fax and fax in a single 
> stream, which are
>     both separate media types.  To do this, the offerer creates a new
>     media description, with a new media type, in place of the 
> description
>     in the previous SDP which is to be changed.
> 
> 
> -Jonathan R.
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Scientist                             Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> 
> _______________________________________________
> 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: Flemming Andreasen <[email-masked]>
Date: Wed, 30 Apr 2003 17:42:45 -0400

> and audio/G7xx the same way as audio/RFC2833

Right - as long as both the transport and the underlying "type" of media
(not to be confused with MIME type which I think ends up being a bit too
restrictive) is the same, this should be just fine. For example, let's say
we defined a T.38 RTP payload format, but we were still using the existing
"image/t38" MIME type, then it should be perfectly fine to switch between
T.38 RTP packets and say PCMU. However, mixing different types of media,
such as audio and video, or different types of transport, such as RTP/AVP
and image/udptl for non-RTP T.38 fax is clearly not a good idea.

> may use up a second in a heavy loaded network.

Agreed - you really need a solution that enables you to switch on the fly,
however currently we don't have that when the top-level MIME types differ
(note that FID and ALT don't give you these capabilities either).  The
problem is, that SDP currently lacks a mechanism that would enable us to
negotiate different top-level MIME types in a single media stream. This can
however be addressed fairly easily by writing an extension to offer/answer
that uses SIMCAP (RFC 3407) capabilities during negotiation. If there is
interest, I can write something up.

-- Flemming