Subject: RE: [SIP] T.38 and multiple streams

From: "Culpepper, Bert" <[email-masked]>
Date: Fri, 23 Feb 2001 13:04:47 -0600

OK, this is what Christer wrote earlier in this thread, the message is
http://lists.bell-labs.com/pipermail/sip/2001q1/005726.html

"It was my understanding from the T.38 on IP recommendation that this is
the way it should work. We should add the fax stream, and mute the voice
stream instead of removing it, ie using a separate c= lines for each
media stream. I don't want to free resources I've used for the voice
when transmitting the fax, since I will probably need them if I switch
back from fax to voice."

Regards,
Bert

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Friday, February 23, 2001 12:44 PM
> To: Culpepper, Bert
> Cc: Christer Holmberg; Jean-Francois Mule; [email-masked];
> [email-masked]
> Subject: Re: [SIP] T.38 and multiple streams
> 
> 
> 
> 
> "Culpepper, Bert" wrote:
> 
> > Hello Flemming,
> >
> > The I-D's text talks about putting the audio on hold while the fax
> > transmission is active.  Putting a media stream on hold in 
> SIP is done by
> > specifying the connection address to be 0.0.0.0 (IP4).  So, 
> to support the
> > scenario described two IP addresses must be present in the 
> SDP.  The current
> > I-D replaces the audio with the t.38 fax as Christer 
> pointed out, this is
> > contrary to the text.
> >
> > I personally think it's fine to replace the audio with the 
> t.38 fax if
> > that's what the two SIP endpoints want.
> 
> Me too - I even think it's preferable.
> 
> > Christer already pointed out a
> > potential implementation problem if an endpoint wants to 
> resume audio after
> > the fax completes, and it released resources since the 
> audio session was
> > replaced.
> 
> Sorry - I missed that. Can you explain the issue again ?
> 
> Thanks
> 
>         Flemming
> 
> > It all depends on the service being provided and the desired
> > goals.
> >
> > Regards,
> > Bert
> >
> > > -----Original Message-----
> > > From: Flemming Andreasen [mailto:[email-masked]]
> > > Sent: Thursday, February 22, 2001 9:32 PM
> > > To: Culpepper, Bert
> > > Cc: Christer Holmberg; Jean-Francois Mule; 
> [email-masked];
> > > [email-masked]; [email-masked]
> > > Subject: Re: [SIP] T.38 and multiple streams
> > >
> > >
> > > Joining in a bit late here, but in any case:
> > >
> > > 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.
> > >
> > > A couple of more specific comments on the current draft, some
> > > of which you
> > > may
> > > have already gotten:
> > > - T.30 CED is the same as as V.25 ANS and hence cannot be
> > > used as a fax
> > > detection mechanism (the V.21 fax preamble is fine).
> > > - Why must CNG tone detection not lead to a switch to T.38 ?
> > > - SIP call flow should probably include a Contact header
> > > resulting in some
> > > of
> > > your messages (e.g. ACK) going end-to-end rather than through
> > > the proxy).
> > > - Section 4.1 mentions that different UDP ports are to be
> > > used where as
> > > Section
> > > 6.2 lists that as open issue. I agree with Section 6.2 and
> > > would leave that
> > > choice to the gateways.
> > >
> > >
> > >
> > > Regards
> > >
> > >         Flemming
> > >
> > > "Culpepper, Bert" wrote:
> > >
> > > > snip
> > > >
> > > > > >>I prefer the second option (no general c= line, one c= line
> > > > > per media
> > > > > >>description).  Shall we recommend this second option in the
> > > > > >>updated paper?
> > > > > >
> > > > > >I prefer the second option too.  c= lines in the media
> > > descriptions
> > > > > >are required when a session has more than one media 
> stream and
> > > > > >they need to be controlled independently.
> > > > >
> > > > > I guess this also depends on what the SDP standard says.
> > > For example,
> > > > > when we
> > > > > establish the call for voice, we probably will have a
> > > general c= line.
> > > > > Is it then allowed, in the re-INVITE, to remove that and
> > > then suddenly
> > > > > insert the c= for the media description?
> > > > >
> > > >
> > > > >From my reading of RFC 2327 (SDP standard) I don't see 
> a problem
> > > > with this.  But it doesn't concern itself with a SIP
> > > reINVITE.  I don't
> > > > remember seeing this detail discussed in the SIP RFC or 
> bis either.
> > > > I also don't believe it necessarily needs to be discussed
> > > in the bis.
> > > > However, I can understand an implementation having a
> > > problem with this.
> > > > But it's an implementation thing.  A robust 
> implementation (one that
> > > > realizes not all media streams may go to the same
> > > destination) should
> > > > handle this IMO.
> > > >
> > > > snip
> > > >
> > > > regards,
> > > > Bert
> > > >
> > > > _______________________________________________
> > > > 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.
> > >
> > > --
> > > Flemming Andreasen
> > > Cisco Systems
> > >
> > >
> 
> --
> 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.
> 

_______________________________________________
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: "Gross, Gerhard" <[email-masked]>
Date: Fri, 23 Feb 2001 11:44:24 -0800

The following may already be obvious but I'll
state it anyway.

Consider the case where QoS has been reserved for
the session, incurring a (usage based?) cost similar
to current PSTN long distance. Preserving this
reservation while faxing *MAY* not be an issue for some
consumers since the majority of faxes may be small
- seconds to a few minutes.

In other cases, such as in the legal world, faxes
may be quite large. One hundred page plus documents
faxed between offices is not uncommon in this
business. A significant cost savings could be realized
by releasing the bandwidth reservation during the
fax, then setting it up again when the fax is complete
(assuming voice will continue).

Some users may choose to hold the reservation during
fax transmission to increase transmission speed at a
monetary expense.

-Gery

        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        X                                         X
        X    Gerhard W. Gross, Ph.D.              X
        X    Intel                                X
        X    2111 NE 25th Ave                     X
        X    Hillsboro, OR 97124-5961, USA        X
        X    Internet Infrastructure Arch. Group  X
        X      - Internet and Communication Lab   X
        X    phone:    (503) 264-6389             X
        X    fax:      (503) 264-3483             X
        X    email:    [email-masked]    X
        X                                         X
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

> From: Culpepper, Bert [mailto:[email-masked]]
> Sent: Friday, February 23, 2001 11:05 AM
> To: Flemming Andreasen
> Subject: RE: [SIP] T.38 and multiple streams
> 
>