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

[Tristan Delsol]

Checked a lot of things but I'm still getting a 404 not found from spce.
I managed to change the request-uri from 
sip:ngcp-lb;tgrp=9752;trunk-context=ipic.imscore.net at 87.239.101.193:5060;ngcpct=7369703a3132372e302e302e313a35303830 
to 
sip:ngcp-lb at 87.239.101.193:5060;ngcpct=7369703a3132372e302e302e313a35303830, 
but I'm still getting a 404 not found.
Shouldn't this work?
I mean the spce is sending this as Contact.

Tristan

On 2015-08-21 14:25, Daniel Grotti wrote:
> Hi,
> yes something like:
> 
> if(is_method("INVITE") && uri =~ "^sip:ngcp-lb;tgrp.+@")
> 
> 
> 
> --
> Daniel Grotti
> VoIP Engineer
> 
> 
> Sipwise GmbH
> Europaring F15 | 2345 Brunn am Gebirge, Austria | www.sipwise.com
> 
> On 08/20/2015 07:44 PM, Tristan Delsol wrote:
>> Hi Daniel,
>> 
>> The only problem is actually that the telco sends this weird invite 
>> with
>> the following request-uri:
>> sip:ngcp-lb;tgrp=9752;trunk-context=ipic.imscore.net at 87.239.101.193:5060;ngcpct=7369703a3132372e302e302e313a35303830
>> 
>> 
>> If I could maybe rewrite this to remove the
>> ";tgrp=9752;trunk-context=ipic.imscore.net" or send a 488 then I 
>> should
>> be good.
>> 
>> Could I add something to
>> /etc/ngcp-config/templates/etc/kamailio/proxy/proxy.cfg.customtt.tt2 
>> like
>> if(is_method("INVITE") &&
>> search("tgrp=9752;trunk-context=ipic.imscore.net"))
>> {
>>    sl_send_reply("488", "Not Acceptable Here");
>>    exit;
>> }
>> 
>> Thanks,
>> Tristan
>> 
>> On 2015-08-20 16:15, Tristan Delsol wrote:
>>> The reason is that the interconnect with our telco is tripping over
>>> our contact-header of ngcplb@<ip> only with T.38, because of the
>>> re-invite.
>>> They hide behind the fact that they have a spec for the interconnect
>>> that only wants phonenumber@<ip>or<dns> in the contact-header.
>>> 
>>> 
>>> 
>>> On 20-08-15 16:05, Daniel Grotti wrote:
>>>> 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
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> 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