Subject: FW: [SIP] T.38 SDP Attribute Negotiation

From: Jean-Francois Mule <[email-masked]>
Date: Thu, 15 Mar 2001 19:21:38 -0800

... sending the reply here too until implementors' list is back on line.

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]]
Sent: Thursday, March 15, 2001 10:40 AM
To: 'Bill Sulzen'
Cc: [email-masked]
Subject: [SIP] T.38 Attribute Negotiation

Bill,
As you pointed out, the negotiation depends on the actual gw
implementation.
See comments or rather thoughts & proposals interspersed below.
Jean-Francois.
------------------
Bill Sulzen wrote:
> I'm a bit confused over how certain T.38 attributes are negotiated. In
> particular, I the ones that specify a range (T38MaxBitRate,
> T38FaxMaxBuffer and T38FaxMaxDatagram). For example, if a T.38 INVITE
> contains the attribute T38MaxBitRate:14400, but the receiving device
> only supports 9600, what should occur?
ok.  First, there are a couple of choices here we can discuss.
1. The gw sending the re-INVITE specifies 1 media attribute line
T38MaxBitRate and indicates the higher bit rate it can support.
or
2. The gw sending the re-INVITE specifies multiple media attribute lines
for T38MaxBitRate, exactly one media line for each bit rate it supports.
I prefer option #1: it is simple and it means: the gw supports up to bit
rate 14400.

> Can the receiving device respond
> with a 200 OK containing T38MaxBitRate:9600?
Let's assume the re-INVITE had 1 line with T38MaxBitRate:14400 as you
proposed.  Based on that SDP description received in the re-INVITE, I'd
say the receiving gw should respond 200 OK and specify
T38MaxBitRate:9600 indeed.
Then the emitting device has the chance to confirm the transaction (with
an ACK containing T38MaxBitRate:9600 - meaning I heard you) or cancel
the transaction (in this case, I don't know why implementations
supporting bit rate up to 14.4kbps would cancel).

> Do all the negotiated T.38 attributes need to be included in
> the 200 OK
> for the case of a T.38 media stream replacing an audio stream?
Here again, it depends on how flexible your SDP implementation is.
I'd say:
- if all the attributes are accepted, no need to include any attributes
back in 200 ok (even though it is ok to do it I guess)
- if any of the attributes is "negotiated", I would recommend sending
all the attributes.

> Should a T.38 call be rejected based on a T.38 attribute negotiation
> failure?
It *may* be rejected based on some "T.38 attribute negotiation failure".
The current call flow shows 2 examples of rejection.

> For example, if the T.38 INVITE indicated UDP and localTCF,
> should this be rejected?
This particular case should trigger a rejection.

> Or what if the T.38 INVITE contained t38UDPRedundancy, but
> the recipient
> does not support redundancy?
In this particular case, I'd say the trasaction should be accepted (200
OK) but indicate you have no redundancy.  This leaves the final decision
up to the emitting side...  The emitting side could use some config
params: sometimes I can accept not to send redundant packets based on
the route right because this network's packet loss is okay...

> Thanks,
> Bill

Hope this helps.  Thank you Bill,
-------------------
Jean-Francois Mule
Clarent Corporation
T: +1 650 481-2835
[email-masked]

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