[Spce-user] Fwd: Re: Blacklist t.38 fax codec

[Leopoldo Iglesia]

I'll Try this :)

Leopoldo iglesia 

> El 20/06/2014, a las 14:24, Daniel Grotti <dgrotti at sipwise.com> escribió:
> 
> Could be,
> as I see also the normal t38 negotiation is client-dependent....it 
> 
> But from RFC3261:
> 
>  During the session, either Alice or Bob may decide to change the
>    characteristics of the media session.  This is accomplished by
>    sending a re-INVITE containing a new media description.  This re-
>    INVITE references the existing dialog so that the other party knows
>    that it is to modify an existing session instead of establishing a
>    new session.  The other party sends a 200 (OK) to accept the change.
>    The requestor responds to the 200 (OK) with an ACK.  If the other
>    party does not accept the change, he sends an error response such as
>    488 (Not Acceptable Here), which also receives an ACK.  However, the
>    failure of the re-INVITE does not cause the existing call to fail -
>    the session continues using the previously negotiated
>    characteristics.
> 
> 
> 
> Daniel
> 
> 
> 
> 
>> On 06/20/2014 02:08 PM, Matthew Ogden wrote:
>> I think the problem is, a 488 will stop the call altogether?
>>  
>> I cant recall, but if you get a 488 in a REINVITE, will the call not terminate after that, or does it “failback” to leaving t38 un-negotiated… might be device dependent?
>>  
>> From: spce-user-bounces at lists.sipwise.com [mailto:spce-user-bounces at lists.sipwise.com] On Behalf Of Leopoldo Iglesia
>> Sent: 20 June 2014 01:55 PM
>> To: spce-user at lists.sipwise.com
>> Subject: Re: [Spce-user] Fwd: Re: Blacklist t.38 fax codec
>>  
>> Ok. "has_totag" where is located ??
>> 
>> El 20/06/2014 13:35, Daniel Grotti escribió:
>> I have nothing ready to give you right now.
>> Basically on kamailio proxy you should match a Re-invite (using the "has_totag") and check if SDP contains t38 headers/codec (just have a look how the T38 reinvite looks like).
>> So, if you receive a re-invite with T38 headers into SDP, just send back a 488 reply.
>> 
>> Daniel
>> 
>> 
>> 
>> 
>> 
>> On 06/20/2014 01:28 PM, Leopoldo Iglesia wrote:
>> Fine, how can I do this hack? cause endpoints is impossible to mod config, so they are rented and provisioned by an ftth operator.
>> 
>> El 20/06/2014 13:23, Daniel Grotti escribió:
>> Hi,
>> I think you need to avoid to forward the T38 Re-INVITE, so you should hack your SPCE in order to reply to the T38 re-invite with a "488 Not acceptable here", for example.
>> So the sender SHOULD fallback to G711.
>> Anyway, the best solution if you have endpoint with t38 enabled but they don't work well, is to disable t38.
>> 
>> 
>> Daniel
>> 
>> 
>> 
>> On 06/20/2014 01:15 PM, Leopoldo Iglesia wrote:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> > But both endpoints support it, that is the problem and the only > scenario when it fails, so i want SPCE not to send Fax negotiation to > endpoint,.
>> 
>> 
>> 
>>  El 20/06/2014 12:12, Daniel Grotti escribió: >> Hi, >> that's strange, if one of the endpoints try to switch to t38 and the >> other endpoint doesn't support it, they should fallback to G711. >> >> Daniel >> >> >> >> >> >> >> On 06/20/2014 01:33 AM, Leopoldo Iglesia wrote: >>> How can I, blacklist t.38 to avoid endpoints to try t38 negotiation? >>> >>> When i call from ericcson ont to fax capable endpoint, it try to >>> connect t38 fax and There is no voice. >>> >>> Thanks >>> >>> Leopoldo iglesia >>> >>> _______________________________________________ >>> Spce-user mailing list >>> Spce-user at lists.sipwise.com >>> http://lists.sipwise.com/listinfo/spce-user >> >> _______________________________________________ >> Spce-user mailing list >> Spce-user at lists.sipwise.com >> http://lists.sipwise.com/listinfo/spce-user > >
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
>> http://lists.sipwise.com/listinfo/spce-user
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
>> http://lists.sipwise.com/listinfo/spce-user
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
>> http://lists.sipwise.com/listinfo/spce-user
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
>> http://lists.sipwise.com/listinfo/spce-user
>>  
>> 
>> 
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
>> http://lists.sipwise.com/listinfo/spce-user
> 
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> http://lists.sipwise.com/listinfo/spce-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20140620/48fc0ed4/attachment-0001.html>