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

From: "Culpepper, Bert" <[email-masked]>
Date: Wed, 21 Feb 2001 08:45:15 -0600

Hi,

comments below...

> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email-masked]]
> Sent: Wednesday, February 21, 2001 2:20 AM
> To: 'Christer Holmberg'; 'Culpepper, Bert'
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [SIP] T.38 and multiple streams
> 
> 
> Thanks Bert for the clarifications and opinions.  See comments below.
> Jean-Francois.
> --------------
> Bert Culpepper wrote:
> > Yes, that is true. The recommendation, however, says that the
> > fax stream
> > 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...)
> 
> > >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.
> 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.

> 
> > >So RFC 2327 allows placing the audio on hold while the T.38
> > >is active at the protocol level.
> >
> > 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.
> Agreed.  As a side note, how many of us send a fax and then 
> return to an
> audio call once fax transmission is complete?

My voice and fax communications are curently separate calls.  But 
I don't have access to a SIP-enabled terminal capable of 
simultaneous voice and fax, yet :-)

Regards,
Bert

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

_______________________________________________
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: Thu, 22 Feb 2001 00:29:08 +0200

Hi,

More of my comments.

"Culpepper, Bert" wrote:
>>>fax stream should be ADDED to the connection, not REPLACE the voice stream.
>>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...)

Of course, but then I think we should include all possible scenarios in
the call flows draft. Currently we only include one, and it's not even
the one according to the recommendation, ie the *SHOULD* :)

We should remember, though, that even if the fax initiator has enough
DSP resources, the other party may not. So, another question is if he
should be allowed to release the voice stream anyway, and somehow
indicate that
to the initiator, which then would know that it may not be possible to
switch back to voice after the fax transmission...

OR

...should be define some kind of "media stream could not be added" error
response code, and send back. After that, the initiator could send a new
re-INVITE, without the voice media description, and the receiver would
terminate the voice stream and replace it with the fax stream.

Things like this may of course be implementation issues, but I think
it's good to define the behaviour, and include them in the call flows -
to make sure we interop even when things don't work :)

>>>>method defined in the SIP RFC, it would have included both media descriptions and an
>>>>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

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?

>>>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
>>return to an audio call once fax transmission is complete?
> 

I don't use fax at all :)

Regards,

Christer Holmberg
Ericsson Finland