Subject: RE: [SIP] T.38 - to add fax stream or to replace voice stream

From: "Tom-PT Taylor" <[email-masked]>
Date: Sat, 10 Mar 2001 20:40:23 -0500

There's a simple answer to the "double book" problem: release the network
reservation when you put the stream on hold.  Obviously this means delay
when the muted stream is restarted.

The problem is more general than the T.38 application.  Streams can be put
on hold for significant periods of time during consultation hold, for
instance.  Whether implementations are parsimonious enough to unbook QOS
during the hold period is an implementation decision.

> -----Original Message-----
> From: Michael A. Ramalho [mailto:[email-masked]]
> Sent: Monday, February 26, 2001 9:17 AM
> To: Flemming Andreasen; Christer Holmberg
> Cc: Jean-Francois Mule; 'Culpepper, Bert'; [email-masked];
> [email-masked]
> Subject: Re: [SIP] T.38 - to add fax stream or to replace voice stream
> 
> 
> This email thread is getting monotonous.
> 
> Please provide Flemming with a *reason* why you
> desire two streams that makes sense.
> 
> Flemming has provided many reasons why you
> would not desire to do this ... the most persuasive
> being the fact that you would "double book" the
> QoS requirements for the session (in the sense of
> two QoS reservations - not necessarily double the
> bandwidth reservation).
> 
> If you desire - at any given instant - to have either
> stream "active" (i.e., non-muted) - and never desire
> both to be active at a given time - then Flemming's
> arguments should be sufficient.
> 
> The QoS argument is particularly persuasive
> for access (last mile) systems where bandwidth
> is precious (e.g., wireless, cable, DSL).
> 
> Even if this is not the case you are considering
> (e.g., you are only concerned with VoIP over
> large backbone networks) ... I'd still suggest,
> for generality, that you do what Flemming
> says. This is because you, IN GENERAL,
> won't know the bandwidth limitations, if any,
> of the other "IP end". And whoever "pays"
> for the connection might have to pay and/or
> account for two reservations instead of one.
> 
> Q.E.D.
> 
> Michael Ramalho
> 
> At 11:39 AM 2/25/01 -0500, Flemming Andreasen wrote:
> >
> >
> >Christer Holmberg wrote:
> >
> >> Hi,
> >>
> >> Jean-Francois Mule wrote:
> >> >
> >> >Thanks for the comments.
> >> >
> >> >Flemming Andreasen wrote:
> >> >>Fundamentally, I don't understand why you view this as two
> >> >>separate media
> >> >>streams. You are muting one when you want to use the other,
> >> >>so why have two in
> >> >>the first place ? Also note, that there may be some 
> undesirable QoS
> >> >>interactions that way.
> >> >
> >> >Christer Holmberg pointed earlier that T.38 suggests to 
> add the fax channel
> >> >to the voice stream and to mute the voice stream.
> >>
> >> Just to clarify: it's not T.38 that suggests this, it is 
> the node (e.g.
> >> gateway) that detects
> >> the fax that may suggest this :)
> >>
> >> >The only reference I found in T.38 Annex D (TD0262rev1), 
> section 2.2.4
> >> >states:
> >> >"Note that during this switch over and the facsimile 
> call, it may be useful
> >> >to mute the voice channel.  The voice channel may be used 
> again once
> the end
> >> >of facsimile transmission is detected."
> >> >=> this implies that T.38 annex D recommends both streams 
> in the same
> >> >session.
> >> >
> >> >As I've pointed out earlier - and this is what was shown 
> in the current
> >> >draft, I also prefer to replace the voice by a fax 
> channel for the same DSP
> >> >resource consumption reasons.  BTW, this "replacement" 
> does not prevent the
> >> >session to return to voice mode after the fax is over 
> (re-INVITE with audio
> >> >sdp).
> >>
> >> There may some issues here, especially if you have a PSTN 
> gateway. If
> >> you do this, you basically want to create a new connection on the
> >> endpoint. And, since you already have a connection there this won't
> >> work.
> >
> >Since when could you not create more than one connection on 
> an endpoint ?
> >
> >Even for implementations that can only handle a single connection per
> endpoint,
> >since when could you not change the media parameters of that 
> connection ?
> >
> >
> >Can we please get some real arguments on the table here - what is the
> problem ?
> >
> >-- Flemming
> >
> >
> >--
> >Flemming Andreasen
> >Cisco Systems
> >
> >
> >
> >_______________________________________________
> >This list is for continuing development of the SIP protocol.
> >The sip-implementor's list is the place to discuss implementation,
> >and to receive advice on understanding existing sip.
> >To subscribe to it, send mail to 
> >[email-masked] with "subscribe" in 
> the body.
> 
> 
> Michael A. Ramalho, Ph.D.
> Office email: [email-masked]
> Personal email: [email-masked]
> Office: +1.732.449.5762
> Cell: +1.732.809.0188
> Pager: +1.800.365.4578
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> [email-masked] with "subscribe" in the body.
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 13 Mar 2001 16:34:42 -0500

Just an oblique point here.  I don't know about the requirement with FAX,
but at some point we should get into alternating text/voice (as for service
to the hearing impaired).

> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Monday, February 26, 2001 10:12 AM
> To: Christer Holmberg
> Cc: Michael A. Ramalho; Jean-Francois Mule; 'Culpepper, Bert';
> [email-masked]; [email-masked]
> Right. Based on all your responses (thanks) it seems we are 
> in much more agreement
> than I thought we were. I also agree with your recommended 
> next steps here.
> 
> Regards
> 
>         Flemming
> 
> 
> Christer Holmberg wrote:
> 
> > Hi,
> >
> > I am very happy to allow a single stream, and that's the 
> reason why it
> > will be added to the call flows. I DO also agree, that if nobody can
> > give a good reason why we would need separate streams I 
> think we should
> > consider it to be removed from the recommendation draft. This
> > discussion, however, was from the beginning about the bugs 
> in call flows
> > draft, which is based on the recommendation. However, I think we all
> > agree that this discussion has showed that the 
> recommendation should be
> > updated too...
> >
> > Regards,
> >
> > Christer
> >
> > > >> >Christer Holmberg pointed earlier that T.38 suggests 
> to add the fax channel
> > > >> Just to clarify: it's not T.38 that suggests this, it 
> is the node (e.g.
> > > >> gateway) that detects
> > > >> >The only reference I found in T.38 Annex D 
> (TD0262rev1), section 2.2.4
> > > >> >states:
> > > >> >to mute the voice channel.  The voice channel may be 
> used again once
> > > the end
> > > >> >=> this implies that T.38 annex D recommends both 
> streams in the same
> > > >> >session.
> > > >> >
> > > >> >As I've pointed out earlier - and this is what was 
> shown in the current
> > > >> >resource consumption reasons.  BTW, this 
> "replacement" does not prevent the
> > > >> There may some issues here, especially if you have a 
> PSTN gateway. If
> > > >Since when could you not create more than one connection 
> on an endpoint ?
> > > >
> > > >since when could you not change the media parameters of 
> that connection ?
> > > >
> > > >