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

From: "Culpepper, Bert" <[email-masked]>
Date: Fri, 23 Feb 2001 11:06:28 -0600

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

_______________________________________________
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: Fri, 23 Feb 2001 12:44:24 -0500

"Culpepper, Bert" wrote:

> that's what the two SIP endpoints want.

Me too - I even think it's preferable.

> Christer already pointed out a
> 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
>

--
Flemming Andreasen
Cisco Systems

---

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

Bert Culpepper wrote:
> I-D replaces the audio with the t.38 fax as Christer pointed
> out, this is contrary to the text.

As you know, this has been corrected in the upcoming I-D: we have 2
different flows and the text is consistent with the message details.

---

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

Hi,

>Me too - I even think it's preferable.

I guess the reason you think so is because adding streams is not really
the easiest thing to do in MGCP, right? :) 

At the end, I guess this is up to the user to decide, and it also
depends on which transport protocols you use. For fax TCP is
recommended, while you use UDP (RTP) for voice. So, no matter if you
want to keep the voice stream or not, you still have to create a new
stream for the fax (you can't modify a stream from UDP to TCP...).

Also, if you want to continue the voice session after the fax
transmission it think the best thing to do is to keep the voice stream.
Otherwise you will have to, again, create a new stream after the fax,
instead of simply "un-mute" the existing one.
 
>Sorry - I missed that. Can you explain the issue again ?

Let's assume that the node receiving the fax tone wants to use separate
streams, so it sends a re-INVITE including SDP m= lines both for the
voice and fax (with the voice muted). Now, the node receiving the
re-INVITE may not have resources to establish an extra session. Instead
it may, if possible, want to modify to voice stream, OR to delete the
voice stream and replace it with a new fax stream. It must indicate this
to the other node, either by refusing to establish the fax session, or
to return a SDP indicating that there will not be two separate streams.

This case is not specific for fax, but whenever you have a session and
want to add streams.

Regards,

Christer Holmberg
Ericsson Finland

---

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

> the easiest thing to do in MGCP, right? :)

Wrong - just create a new connection.

The problem I have with this is that it is in fact a single media stream. By
treating it as multiple media streams you have undesirable QoS interactions, you
complicate the implemenation (especially for a decompased gateway architectures)
since you would normally not try and do multimedia for what basically amounts to a
mono-media call (albeit admittedly with changing media parameters). If T.38 didn't
happen to use a different protocol/profile than RTP/AVP, you would never have
dreamed of this (in fact, I could define a T.38 payload type for RTP/AVP and you
wouldn't argue this way). Also, if it turns out that you will not use T.38 for
this call, but rather just passthrough, e.g. G.711, you are not going to add a new
media stream either, right ? That is why I think this is a rather questionable
approach.

> stream for the fax (you can't modify a stream from UDP to TCP...).

Says who ?

> instead of simply "un-mute" the existing one.

This doesn't add up. You need signaling to "un-mute" your media stream. You need
signaling to change the parameters of a media stream. What is the difference here
?

> voice and fax (with the voice muted).

I was looking for the argument as to why this was needed in the first place....

> Now, the node receiving the
> re-INVITE may not have resources to establish an extra session.

media stream I assume

> Instead

So if I understand correctly, you are essentially trying to negotiate what to do,
i.e. T.38 or continue as voice, by putting the voice stream on hold, add a T.38
media stream, and you then expect the other end to pick either one, somehow
"un-muting the muted stream" if the voice stream is continued. I think this is a
serious overloading of current semantics and procedures.

If you want to change the media parameters of an existing media stream, you simply
send a re-INVITE with the new proposed parameters for that media stream. The
receiver then either accepts or rejects that. That's the way SIP and SDP normally
works - why doesn't that work here ?

> This case is not specific for fax, but whenever you have a session and

Yes, but please explain why you want to do that for fax ?

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 25 Feb 2001 21:01:57 +0200

Hi,

>Wrong - just create a new connection.

Ok, I guess we agreed on that. There is some issues on how it will be
done, however, but let's discuss that elsewhere.
 
>media stream either, right ?

I guess that is an implementation issue, and depends on your gateway. If
it uses G.711, and detects fax, it may choose to use the existing voice
stream. 

However, since TCP is recommended for fax, it may choose it wants to add
a separate stream for the fax (or, modify the existing stream from UDP
to TCP) anyway.

That is also a reason why the voice stream must be muted during the fax
transmission. Otherwise you would get the fax stuff both on the G.711
voice stream and on the fax stream (and mix it together) and the
receiving fax machine would probably not be too happy...

>That is why I think this is a rather questionable approach.

The reason I wanted both (single- and multi stream) scenarios in the
call flows is the allow the use of whatever method wanted. If someone
wants to use a single stream he may do so, but if he for whatever reason
wants to use multi streams he should be allowed to do so too. Both nodes
may not support, or want to, use multi streams, and that is the reason
why I also want that scenario described in the call flows.
 
>signaling to change the parameters of a media stream. What is the difference here

At the end I guess the difference will be more on an implementation
level, since the protocol call flows will look pretty much the same in
both cases. Again, the only reason I personally can think of is the
issue related to UDP and TCP.
 
>>re-INVITE may not have resources to establish an extra session.

Correct.
 
>>Instead it may, if possible, want to modify to voice stream, OR to delete the

What I said was what could happen if the detecting node wants to ADD a
stream, but the other node
isn't capable of doing that but it IS capable to replace/modify the
voice stream with the fax stream.
 
>works - why doesn't that work here ?

It DOES work here. I mentioned earlier that if the node refuses to add
the new stream (which is done using re-INVITE too) it normally shall
send some 4xx response. The issue I raised was if the node, instead of
doing this, should be allowed to instead replace the voice stream with
fax, and indicate that in the re-INVITE response. Personaly I do NOT
like the idea too much, though. First, it probably should be allowed
only for the specific fax case (which I mentioned earlier) and I think
most of us wants solution which are general from a SIP point of view.
Second, the detecting node should be informed if the fax stream can not
be added (after that, it MAY choose to send a new re-INVITE where the
voice is replaced with the fax).

>Yes, but please explain why you want to do that for fax ?

The only reason is that we would be able to quickly establish the fax
connection even if the other node is not able to ADD the fax stream, but
it is able to REPLACE the voice with fax.

I do think, however, that there should be a 4xx response code, or at
least a Warning header code, to indicate that we were not able to add
the stream. There are Warning header codes to indicate that the codec
was not supported etc, but that is not the same.

Regards,

Christer

---

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

Christer Holmberg wrote:
> recommended,
reference?

> transmission it think the best thing to do is to keep the
Again, I do not think this is always "the best thing" mainly because for
each fax call (and the entire duration of the fax transmission), 2 DSP
channels are used and worse depending on the complexity of the codec that
was selected for voice.
When you have a large DSP pool in a big fat gateway, you may think it is ok.
When you have a small enterprise gw with limited number of ports (8 for
example), you do not want fax calls to litteraly "block" voice calls because
the fax calls suck all the dsp resources.
=> so, and to shut down this specific point in the thread, I'll repeat:
both should be allowed in our Internet-Draft.