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

From: "Culpepper, Bert" <[email-masked]>
Date: Thu, 22 Feb 2001 09:47:46 -0600

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.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 22 Feb 2001 21:32:25 -0500

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

--
Flemming Andreasen
Cisco Systems

---

From: Jean-Francois Mule <[email-masked]>
Date: Fri, 23 Feb 2001 18:43:12 -0800

Thanks for the comments.

Flemming Andreasen wrote:
> streams. You are muting one when you want to use the other,
> so why have two in
> 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.
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).

To keep everyone happy, I've updated the draft to accomodate both scenarios
and message details with proper SDP descriptions.

Flemming Andreasen wrote:
> 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).
got it, thanks.
corrected - this was also noted in H.248/megaco Annex F

> - Why must CNG tone detection not lead to a switch to T.38 ?
it could but my understanding is that CNG is optional so to limit the number
of cases we selected the Preamble sequence.  Also, because of the potential
glare effect, we decided to mandate for the Preamble detection...
Do you have any comments to improve the text there?

> - SIP call flow should probably include a Contact header
> resulting in some of
why is that useful in the sip t.38 case?
fyi, a record-route header line has been added to enforce the route through
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.
ok, I'll make a more affirmative statement.  We've run across both cases
here too and this has not been caused any interop issue so far.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 24 Feb 2001 15:54:15 +0200

Hi,

Flemming Andreasen wrote:
>streams.

I guess there are reasons for this. One is that it is recommended that
you use TCP for fax, and since you use RTP/UDP for voice you will have
to use separate streams. I mean, you can modify the codecs you use for a
stream etc, but I don't think you can modify a single stream from UDP to
TCP...

>You are muting one when you want to use the other, so why have two in the first place ?

You want to continue the voice session after the fax has been sent, so
by keeping the voice stream during the fax transmissoion you don't have
to create a new voice stream after the fax, just "un-mute" the existing
one.

>Also note, that there may be some undesirable QoS interactions that way.
> 
>may have already gotten:

There are different way to detect a fax. The flows would be different
for all cases, and for interop issues you would have to implement all of
them. That is the reason why one mechanism was chosen.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 24 Feb 2001 16:01:04 +0200

Hi,

>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 :)

>session to return to voice mode after the fax is over (re-INVITE with audio

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. Ok, of course your gateway can be smart enough to handle this, but
- again - there probably would be some interop issues...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 25 Feb 2001 10:52:46 -0500

Christer Holmberg wrote:

> I guess there are reasons for this.

I have yet to hear a good one.

> One is that it is recommended that

Says who ? A media stream is a media stream.

> to create a new voice stream after the fax, just "un-mute" the existing

Well, first of all, how many fax calls actually turn into voice calls once they finish ?
Secondly, you already need signaling to "un-mute" the stream, so what's the advantage here ?
As mentioned previously, there are in fact several disadvantages, so if we were to do this,
it should be based on some real good pros, and I have yet to hear any.

> There are different way to detect a fax.

True, however T.30 CED/V.25 ANS is not one of them.

> The flows would be different

OK. I would suggest clarifying the draft to make that clear then, as it currently reads like
it is forbidden to switch to T.38 on CNG.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 25 Feb 2001 11:39:53 -0500

Christer Holmberg wrote:

> 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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 25 Feb 2001 19:32:42 +0200

Hi,

I guess I messed up the answers a little with the MGCP discussion for
T.38...

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

The problem is when the detecting node wants to ADD the fax stream (and
keep the voice stream) but the other node is not able to add the fax
stream. Instead it wants to REPLACE the voice stream with the fax
stream. Of course it should not be a problem to do that, but the issue
was that the detecting node should be informed about this if it happens
- or, should the node be able to send a "stream could not be added"
response back to the detecting node, which may then send another
re-INVITE where it replaces the voice with fax, instead of adding the
fax to the voice. I don't see this as a problem, just as a scenario that
may take place, and my proposal was that we describe it in the call
flows.

Regards,

Christer

---

From: David Israel <[email-masked]>
Date: Sun, 25 Feb 2001 10:05:35 -0800

Christer,

Are there call flows available?  (I need them in SIP and MGCP.)

Thank you,
David

Christer Holmberg wrote:
> I don't see this as a problem, just as a scenario that

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 25 Feb 2001 20:17:58 +0200

Hi,

>I have yet to hear a good one.

There are no reasons in the recommendation, and I guess that's why we
try to think of some.
 
>Says who ? A media stream is a media stream.

Well, the ones who made the recommendation maybe assumed that a UDP
stream can not be modified into a TCP stream just like that, and that
you will have to create a new TCP stream instead.

I do agree with you, though, that there is nothing from a protocol point
of view that would prevent this.

>Well, first of all, how many fax calls actually turn into voice calls once they finish ?

I don't know.

However, these questions will come up in future whenever we want to have
a multimedia session (audio + fax, audio + video, whatever), when
streams may be added and removed during the session. This may not be the
case for T.38, and the call flows are not supposed to solve general
multimedia issues, but if it is possible to solve also I see no reason
to "forbid" a voice session to continue after the fax transmission.

>Secondly, you already need signaling to "un-mute" the stream, so what's the advantage here ?

The only reason I can think about is what I wrote above about the UDP
and TCP streams. However, I would like the ones who made the
recommendation to use separate streams to define the reason why.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 25 Feb 2001 20:19:32 +0200

Hi David,

There are call flows for SIP. They are to be updated, though, and that
is what we are currently discussing.

Regards,

Christer

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Mon, 26 Feb 2001 09:17:13 -0500

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:
>> >>separate media

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Feb 2001 16:28:52 +0200

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

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 26 Feb 2001 10:12:05 -0500

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

--
Flemming Andreasen
Cisco Systems

---

From: Jean-Francois Mule <[email-masked]>
Date: Mon, 26 Feb 2001 07:57:16 -0800

Hold on:
This thread is going in every directions.

First and starting now, please mention references when you state things
like:
> you use TCP for fax
First, t.38 recommendation is clear:  either TCP or UDP. So I disagree on
that statement.
Second, we had polled the implementors when doing imtc inow profiles and the
response was clear for gw vendors: UDP.
Third, ultimately, vendors should support both and the internet-draft does
not prevent TCP at all.
So let's leave this out of the discussion.
Jean-Francois.

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Saturday, February 24, 2001 5:54 AM
> To: Flemming Andreasen
> Cc: Culpepper, Bert; Jean-Francois Mule; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [SIP] T.38 and multiple streams
>
>
>
> Hi,
>
> used as a fax
> resulting in some
> used where as

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Feb 2001 19:20:02 +0200

Hi,

This is NOT a we-must-use-multiple-streams argument, but do you think
the following case could have something to do with the recommendation?

Let's assume that gateway B detects the fax tone. It now modifies the
stream, which may lead to a new port, different from the voice stream,
for the fax stream. Now, it will take a while (even if a very short one)
for B to inform A about the change, so A may continue to send voice to
B's voice port. If B changed port when the fax was detected, that port
will not be available anymore, so A will probably start receiving ICMP
messages - which COULD (depending on the time it takes for B to inform A
about the modification) cause A to release the call, or something
similar unwanted... Instead, if you mute the channel the voice packets
will still be received on B's voice port, even if they will not be
forwarded.

Comments?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Feb 2001 19:02:59 +0200

Hi,

>than I thought we were. I also agree with your recommended next steps here.

The "funny" thing is that the recommendation is an ITU document (ITU-T
Recommendation T.38 Amendment 2)... 

The recommendation is also based on H.323, which could be the reason for
using separate streams.
They also use multiple m= lines to define options, which I don't think
is the correct usage or SDP(?)

Regards,

Christer

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 26 Feb 2001 13:41:32 -0500

It would probably be better to ask those that wrote the recommendation. Nevertheless, I
don't see this as an argument either as B could just keep the port open for a while, e.g.
until it gets the 200 OK. regardless of whether it was specified as a separate media
stream in the SDP or not.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Jean-Francois Mule <[email-masked]>
Date: Mon, 26 Feb 2001 08:06:36 -0800

Christer Holmberg wrote:
> to create a new voice stream after the fax, just "un-mute"
> the existing one.

There are pros and cons for both methods and I don't think we should force a
decision on this now.  The SIP T.38 call flows will show both options.  We
should leave that to vendors' implementations and see if it does cause
interop issues - I bet it does not unless your implementation does not
support multiple media connections per session.

Jean-Francois Mule.

---

From: Jean-Francois Mule <[email-masked]>
Date: Mon, 26 Feb 2001 08:53:19 -0800

Agreeing on a common approach does not mean removing the other ones from the
internet-draft, right?

Based on our thread, I do not see any reason for updating the ITU-T T.38
recommendation ("recommendation") but many good reasons to update the SIP
T.38 Internet-Draft.

My goal is to collect all the good comments and submit an updated draft for
your review this week.  I'd propose to mute this thread on the points we've
beaten until then.

Jean-Francois Mule
Clarent Corporation.

> Sent: Monday, February 26, 2001 6:29 AM
> To: Michael A. Ramalho
> Cc: Flemming Andreasen; Jean-Francois Mule; 'Culpepper, Bert';
> [email-masked]; [email-masked]
> Subject: Re: [SIP] T.38 - to add fax stream or to replace voice stream
>
>
>
> Hi,
>
> > >> >to mute the voice channel.  The voice channel may be
> used again once
> > the end
> > >Even for implementations that can only handle a single
> connection per
> > endpoint,
> > >Can we please get some real arguments on the table here -
> what is the
> > problem ?
> > >
> > >-- Flemming
> > >
> > >
> > >--
> > >Flemming Andreasen
> > >Cisco Systems
> > >
> > >
> > >

---

From: Jean-Francois Mule <[email-masked]>
Date: Mon, 26 Feb 2001 08:23:24 -0800

Jean-Francois Mule wrote:
> > BTW, this "replacement" does not prevent the
> >session to return to voice mode after the fax is over
> > (re-INVITE with audio sdp).

Christer Holmberg
> - again - there probably would be some interop issues...

first of, I believe most of the fax call are terminated when fax is over.
For the cases where audio connection is required at the end of fax, we will
see the interop issues at the bake-off and revise the draft accordingly,
right?

---

From: Jean-Francois Mule <[email-masked]>
Date: Mon, 26 Feb 2001 08:46:35 -0800

Michael A. Ramalho wrote:
> QoS requirements for the session
To me, the most persuasive reason is to book the DSP resources for not much
at the end...
As far as QoS, why would'nt your QoS decision/enforcement points recognize
the codec used or whether you're muting the channel to make appropriate
choices...

Flemming Andreasen wrote:
> what is the problem ?
I'm trying to remain neutral in this discussion because I believe both
should be allowed even though, as implementors, I have a preference based on
the target application...
A good argument for maintaining 2 connections: let's forget the pstn handles
fax on one physical line - this is the source of  the pb.  Let's think not
about replicating the way the PSTN handles this.
New kinds of IP terminals should allow users to speak while sending the fax
if end-users desire to.  We must not limit speech only when fax is over.
This, to me, is a SUFFICIENT reason.

Jean-Francois Mule

> From: Michael A. Ramalho [mailto:[email-masked]]
> Sent: Monday, February 26, 2001 6:17 AM
> To: Flemming Andreasen; Christer Holmberg
> Cc: Jean-Francois Mule; 'Culpepper, Bert'; [email-masked];
> [email-masked]

---

From: Jean-Francois Mule <[email-masked]>
Date: Mon, 26 Feb 2001 08:10:37 -0800

Christer Holmberg wrote:
> you use TCP for fax, and since you use RTP/UDP for voice
> you will have to use separate streams.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is wrong.  No matter what transport is used for voice, one single
stream *can* be used when switching to fax.

Jean-Francois Mule

---

From: Jean-Francois Mule <[email-masked]>
Date: Mon, 26 Feb 2001 09:41:07 -0800

> The recommendation is also based on H.323, which could be the
> reason for using separate streams.
No.
In H.323 provides 2 H.245 commands to control the logical channels,
Replacementfor and RequestMode.  A similar debate applies to H.323, MGCP,
...

> is the correct usage or SDP(?)
I had sent comments to Glen Parsons.  Upon update of the new draft, we'll
send follow-up.

Jean-Francois.

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 26 Feb 2001 17:37:51 -0500

<snip>

> Do you have any comments to improve the text there?

If it's just a particular call flow that shows fax detect based on V.21 fax
preamble rather then T.30 CNG, then that's fine. If the text on the other hand
says that in general you shall not switch based on CNG, then that's problematic,
and I believe that's the way the current text reads.

> why is that useful in the sip t.38 case?

Well, that's how SIP normally works.

> fyi, a record-route header line has been added to enforce the route through

I suppose that's another way of solving that. I personally think it's just
muddying the picture a little, but it's your I-D.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 26 Feb 2001 17:48:42 -0500

> support multiple media connections per session.

And that's the problem. There will be lots of devices out there that will not
want to support more than one media stream at a time. Considering this is to be
a BCP and you want to specify something that's interoperable, I'd strongly
suggest that the mono-media solution is considered the base-line that all
implementations should be expected to support. For those more sophisticated
types of devices that allow you to send faxes and continue talking at the same
time, I have no problem specifying a multi-media call flow that adds an extra
active stream, however do note, that this is different from what has been
discussed so far, which was a single active media stream.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 26 Feb 2001 17:55:43 -0500

> the codec used or whether you're muting the channel to make appropriate

That would imply that you give up the old (audio) reservation then, however I'd
rather not turn this into a QoS discussion.

> This, to me, is a SUFFICIENT reason.

I agree, but that is indeed also a multi-media call (two active media streams),
which is not what has been discussed so far.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Jean-Francois Mule <[email-masked]>
Date: Tue, 27 Feb 2001 23:02:13 -0800

To end this thread properly:
Flemming, Bert and Christer: we would like to thank you for all the
comments.  As you have seen in the preliminary draft01 text, we believe the
major comments have been addressed:
 - fax stream: the replacement of audio stream by fax stream which was
really the only call flow in draft00 is the recommended one; a multi-media
call flow has been added to illustrate the t38 annex D recommendations,
 - several call flows have been added accordingly,
 - section 4 has been completely rewritten and addresses your comments: CNG
may trigger fax detection, CED must not be used to trigger fax switch-over,
 - the text has been clarified on the voice muting and msg details updated.

We look forward to receiving more comments on draft01 and, more importantly,
to demonstrating the true value of this BCP  draft in the interop events,
Jean-Francois.
Clarent Corp.

> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Monday, February 26, 2001 2:49 PM
> To: Jean-Francois Mule
> Cc: 'Christer Holmberg'; 'Culpepper, Bert'; [email-masked];
> Jieying Li