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

From: "Culpepper, Bert" <[email-masked]>
Date: Mon, 19 Feb 2001 10:02:54 -0600

My interpretation of the message flow (message contents) in the I-D is that
the egress gateway is replacing the audio stream with a T.38 stream since
the original m= line and parameters are replaced with t.38 data.  I guess
this effectively mutes the audio session :)

If the egress gateway wanted to mute the audio using the method defined in
the SIP RFC, it would have included both media descriptions and an
additional c= line for one of media descriptions.  By having a c= line in
the T.38 media description, the egress gateway could place the audio on hold
(using IP address of 0.0.0.0 in the main session description) and still have
the T.38 session.  SDP (RFC 2327) allows c= lines in media descriptions
(that only apply to the one media stream) which override c= lines in the
main session description.  A possibly more explicit session description
would not have a c= line in the general session description and c= lines in
each media description.

So RFC 2327 allows placing the audio on hold while the T.38 is active at the
protocol level.

regards,
Bert

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Monday, February 19, 2001 3:08 AM
> To: [email-masked]
> Subject: [SIP] T.38 and multiple streams
> 
> 
> 
> Hi,
> 
> I have a couple of questions about the t.38 call flow draft. 
> I looked at
> the fax discussions in the archieve, but I could not find anything
> related to this. It is, however, related to SDP in general, 
> so if it has
> been discussed I would be happy if someone could point me to 
> the thread
> (and, hopefully, the solution :)
> 
> 1. F11 INVITE IFTGW UA -> PROXY
> 
> In this re-INVITE we add the fax stream to the call. However, t.38 for
> SIP recommendation it says that the existing voice stream 
> should remain,
> so shouldn't the original voice parameters (m line etc) be included in
> the re-INVITE SDP?
> 
> 2. This questions is depending on the first.
> 
> Like I said, the recommendation says that the existing voice stream
> should remain, but that it should be muted during the fax 
> transmission.
> The problem is that SDP uses the c line, which is for the WHOLE call
> (not a single stream), to mute stream(s), so I wonder if it will be
> possible to do this on a protocol level, or if it has to be in the
> implementation?
> 
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer'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 sip-implementors" in the body.

---

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

Hi,

>this effectively mutes the audio session :)

Yes, that is true. The recommendation, however, says that the fax stream
should be ADDED to the connection, not REPLACE the voice stream.
 
>So RFC 2327 allows placing the audio on hold while the T.38 is active at the

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,

Christer Holmberg
Ericsson Finland

---

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

Thanks Bert for the clarifications and opinions.  See comments below.
Jean-Francois.
--------------
> should be ADDED to the connection, not REPLACE the voice stream.
This will be corrected.  Again it says *SHOULD* be added.
Note that there are cases where you would want to release the resources for
the audio streams when a fax is detected (for e.g. when your DSP pool is
running out of gas, should that ever happen...)

> >would not have a c= line in the general session description
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?

> when transmitting the fax, since I will probably need them if I switch
Agreed.  As a side note, how many of us send a fax and then return to an
audio call once fax transmission is complete?