[Foip] SIP/SDP subgroup problem statement - round 2

[Stephen Choy (schoy)]

Hi Kevin, 
Regarding this topics:

"Well, unfortunately you've mixed terminology a bit here. I'm not aware
of indicating support of T.38 as an "attribute in the audio m-line"; can
you provide an example of that? I'd have to assume this would only be
possible for T.38 on RTP transport, as that's the only transport that is
indicated in SDP as 'audio', even though it's not audio."

Unfortunately, I don't have the sample case with me now, if I see that
again, I can send you a copy. 


Regarding the proposal you mentioned below. Not sure if I had missed the
email, do you know where I can get a copy for the new proposal about
SDSPCapNeg and SDPMediaCapNeg?

"That's why we are planning on proposing (and SG16 has already started
working into the T.38 draft) use of the SDPCapNeg and SDPMediaCapNeg
draft mechanisms that actually allow an endpoint to inform the other
endpoint what it is capable of, without actually requiring any resources
to be allocated until such time as those capabilities are requested.
Such a request would require a re-INVITE with an SDP that indicates a
switch to a different capability profile, which the receiver can
properly decline if it does not wish to (or does not have the resources
to) accept."


Thanks,
--Stephen


-----Original Message-----
From: Kevin P. Fleming [mailto:kpfleming at digium.com] 
Sent: Tuesday, February 09, 2010 1:06 PM
To: Stephen Choy (schoy)
Cc: foip at sipforum.org
Subject: Re: [Foip] SIP/SDP subgroup problem statement - round 2

Stephen Choy (schoy) wrote:

> Based on my experience, more than 50% of the fax issue is related to
how
> T.38 is initiated in SIP signal.
> In the middle of the voice call, I have seen the fax receiving side
> initiates invite with various ways.
> 1. Invite with a single image mline in Send-receive mode. 
> 2. Invite with a single audio mline and add a new image mline. i.e.
two
> media channels. 
> 3. invite wiht a single image mline in Inactive mode and then switch
to
> send-receive mode.
> 4. invite with replacing the audio mline to image mline and add second
> audio mline at the end. 

I have seen all of these as well, and I think that's one of the issues
we're trying to address. Scenario 4 is especially egregious, because in
this case the proper thing to do based on the SDP RFCs is to leave the
audio session in the first position but assign it a port number of zero
(indicating that it's just a placeholder, not a real media session) and
add the T.38 session in the second position. It's really not a good idea
from an interoperability point of view to change the type of an existing
media session, or assume that that endpoint you are sending an updated
SDP to will understand that the previously standalone audio session has
changed positions in the session list.

> Second, shall we standardize a way that to indicate T.38 capabilty,
when
> the call is still in audio session. 
> Some vendor indicate support of T.38 as attribute in the audio mline. 
> Some vendor indicate support of T.38 using inactive image mline. 

Well, unfortunately you've mixed terminology a bit here. I'm not aware
of indicating support of T.38 as an "attribute in the audio m-line"; can
you provide an example of that? I'd have to assume this would only be
possible for T.38 on RTP transport, as that's the only transport that is
indicated in SDP as 'audio', even though it's not audio.

The second method (including an 'inactive' image/t38 stream in the SDP)
is unfortunately *more* than just a declaration of capability; it's an
offer to actually support that media stream. Based on my understanding,
if an SDP offerer includes an 'inactive' media stream in their offer,
and the answerer accepts it, then later the answerer can request that
media stream be moved to 'active' and the initial offerer doesn't have
much choice... it has to comply, or risk the call breaking badly.

That's why we are planning on proposing (and SG16 has already started
working into the T.38 draft) use of the SDPCapNeg and SDPMediaCapNeg
draft mechanisms that actually allow an endpoint to inform the other
endpoint what it is capable of, without actually requiring any resources
to be allocated until such time as those capabilities are requested.
Such a request would require a re-INVITE with an SDP that indicates a
switch to a different capability profile, which the receiver can
properly decline if it does not wish to (or does not have the resources
to) accept.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming at digium.com
Check us out at www.digium.com & www.asterisk.org