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

From: Kreuter Ruediger <[email-masked]>
Date: Mon, 5 May 2003 11:54:28 +0200

> 
> Kreuter Ruediger wrote:
> 
> > 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.
> 
> 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.
> 

Agreed !

BTW,
in ch. 8.3.3 "Changing Media Types" of RFC3264 it says :
  "... The offerer MUST be prepared to
   receive media with both the old and new types until the answer is
   received, and media with the new type is received and reaches the top
   of the playout buffer."

If the UDP port number is reused during the switch over from
voice to T.38/UDPTL, this may end up, that T.38/UDPTL packets
will be thrown to the RTP stack until the answer for the 
switch over comes in ...

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

Sounds good to me.
Even though SIMCAP only exchanges potential additional capabilities,
but there is no guarantee that the remote side will use its propagated
capability if it is not negotiated; e.g. to switch on the fly between
voice and text/t140 (both on top of RTP).

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

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 05 May 2003 10:02:16 -0400

> voice and text/t140 (both on top of RTP).

Right - the idea would be to extend those semantics in conjunction with
offer/answer.

-- Flemming