[SIPForum-discussion] Would the fax call fail if there is a mistmatch between SDP Attributes

Kevin P. Fleming kpfleming at digium.com
Tue Aug 24 19:41:34 UTC 2010


On 08/24/2010 07:28 AM, mustafa aydin wrote:
> Hello Guys,
>  
> In my scenario, the receiving gateway sends a reinvite (to negotiate
> t38) with the following SDP attributes;
>  
> Media Attribute (a): T38FaxVersion:0
> Media Attribute (a): T38FaxMaxBuffer:1100
> Media Attribute (a): T38FaxMaxDatagram:612
> Media Attribute (a): T38MaxBitRate:14400
> Media Attribute (a): T38FaxRateManagement:transferredTCF
> Media Attribute (a): T38FaxUdpEC:t38UDPRedundancy
>  
> However, the emitting  gateway responds only with the  attributes below
> in 200 OK;
>  
> Media Attribute (a): T38FaxRateManagement:transferredTCF
> Media Attribute (a): T38MaxBitRate:14400
>  
> Then the recieving gateway sends another reinvite with removing the
> "T38FaxUdpEC:t38UDPRedundancy" attribute, but this time the emitting gw
> responds with a 200 which has "0" at it`s image port.
>  
> My questions are; whether the mismatch between these attributes is a
> reason for a failure ? If so, should not  the emitting gw respond back
> with a failure message instead of a 200 OK ? 
>  
> "draft-mule-sip-t38callflows-02.txt" indicates that only
> T38FaxMaxBuffer  and T38FaxMaxDatagram are optional, does it mean that
> all other attributes must reside at the SDP ?

Don't rely on expired drafts for this information; the T.38
recommendation is freely available at the ITU-T website, and does a
decent job of documenting the T.38 negotiation process in SDP.

To answer your question: the emitting gateway's response is completely
within the requirements of the recommendation. I cannot speak to why its
second response has zero for the image port, but the first exchange
looks to be proper.

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



More information about the discussion mailing list