[Spce-user] No rewrite on T.38 INVITE

[Daniel Grotti]

Hi,
any reason for that ?
The callee should reply 488, not the server.
Anyway, I remember some old threasd about that:
https://lists.sipwise.com/pipermail/spce-user/2014-June/006788.html

Maybe this could help.

--
Daniel Grotti
VoIP Engineer


Sipwise GmbH
Europaring F15 | 2345 Brunn am Gebirge, Austria | www.sipwise.com

On 08/20/2015 03:41 PM, Tristan Delsol wrote:
> Back again on this :)
> 
> One more thing. Would it be possible to disable T.38 support somehow. So
> that if the RE-INVITE comes in that we send back a 488?
> Or maybe I can set it up for certain subscriber numbers?
> 
> Thanks,
> Tristan
> 
> On 17-08-15 17:01, Tristan Delsol wrote:
>> Thanks for the info. I will experiment with that to see if it works.
>> Then I will check if we would really want that or not.
>>
>> Tristan
>>
>> On 17-08-15 16:58, Andrew Pogrebennyk wrote:
>>> On 08/17/2015 03:39 PM, Tristan Delsol wrote:
>>>> They state that they don't support that format for the contact header.
>>>> They have it in the specs for the interconnect that the contact header
>>>> can only contain the following:
>>>> sip:+«ISN»@«ip-address/URL»:«port» with optional user=”phone”, so for
>>>> example sip:+31703434343 at domain.net:5060;user=”phone”.
>>>>
>>>> Where
>>>> ISN: International Subscriber Number
>>>> port: UDP portnumber;
>>>> URL: Uniform Resource Locator: domain name;
>>>>
>>>> Is it possible I can adjust the contact header for this kind of request
>>>> to keep the format as needed?
>>>
>>> Unfortunately this is not something you can easily achieve, but if you
>>> have some understanding of kamailio config scripts you can try to modify
>>> /etc/ngcp-config/templates/etc/kamailio/lb/kamailio.cfg.tt2
>>> and disable the Contact masking completely, e.g. comment out all calls
>>> of ROUTE_MASK_CONTACT and ROUTE_UNMASK_CONTACT as a starting point.
>>>
>>> Then each side will receive the internal IP of b2b as Contact:
>>> sip:127.0.0.1:5080, which exposes your topology a bit to outside but
>>> still doesn't break the protocol. But we are not sending the number part
>>> which might be a problem for them (they didn't say that the number part
>>> is optional). Sorry I can't help you out more at this time.
>>>
>>> Regards,
>>> Andrew
>>>
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
>> https://lists.sipwise.com/listinfo/spce-user
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> https://lists.sipwise.com/listinfo/spce-user