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

Mon Aug 24 05:40:11 EDT 2015

Hi,
something wrong in your rewriting patch, cause proxy receives:

Call from PSTN -
R=sip:ngcp-lb at 87.239.101.193:5060;ngcpct=7369703a3132372e302e302e313a35303830
ID=1183523204412000183319 at 192.168.111.25_b2b-1

I would suggest to do not rewrite, but just reject the re-invite with
488 on LB if the RURI has that format.

--
Daniel Grotti
VoIP Engineer

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

On 08/24/2015 11:12 AM, Tristan Delsol wrote:
> No problem. Attached.
> And thanks for the help.
> 
> Tristan
> 
> On 24-08-15 11:09, Daniel Grotti wrote:
>> would help to see LB an PROXY log.
>>
>>
>> -- 
>> Daniel Grotti
>> VoIP Engineer
>>
>>
>> Sipwise GmbH
>> Europaring F15 | 2345 Brunn am Gebirge, Austria | www.sipwise.com
>>
>> On 08/24/2015 10:35 AM, Tristan Delsol wrote:
>>> Daniel,
>>>
>>> I have no clue :)
>>>
>>> Here the re-invite before I rewrite the request-uri and the 404
>>> response:
>>> INVITE
>>> sip:ngcp-lb;tgrp=9752;trunk-context=ipic.imscore.net at 87.239.101.193:5060;ngcpct=7369703a3132372e302e302e313a35303830
>>>
>>> SIP/2.0
>>> Via: SIP/2.0/UDP
>>> 139.156.126.49:5060;branch=z9hG4bKfofomd006o71lno6s1i0.1
>>> Call-ID: 585966869312000201754 at 192.168.111.25_b2b-1
>>> From:
>>> <sip:+31306665648 at ims.imscore.net>;tag=SDemtl399-127.0.0.1alUtKGp-09752+1+a3000095+156d2c30
>>>
>>>
>>> To:
>>> <sip:+31756418049 at 192.168.111.25>;tag=3D534336-55D9A6A9000B9F71-7E3B2700
>>> CSeq: 98894742 INVITE
>>> Expires: 180
>>> Contact: <sip:+31306665648 at 139.156.126.49:5060;transport=udp>
>>> Min-SE: 90
>>> Session-Expires: 7200;refresher=uac
>>> Supported: replaces, path, 100rel, timer
>>> Content-Length: 276
>>> Allow: INVITE, BYE, REGISTER, ACK, OPTIONS, CANCEL, SUBSCRIBE, NOTIFY,
>>> PRACK, INFO, REFER, UPDATE, PUBLISH, MESSAGE
>>> Max-Forwards: 69
>>> Content-Type: application/sdp
>>> User-Agent: Alcatel-Lucent 5060 MGC-8 9.2.0.4.0.11
>>> Route:
>>> <sip:87.239.101.193;r2=on;lr=on;ftag=3D534336-55D9A6A9000B9F71-7E3B2700;ngcplb=yes>
>>>
>>>
>>> Route:
>>> <sip:127.0.0.1;r2=on;lr=on;ftag=3D534336-55D9A6A9000B9F71-7E3B2700;ngcplb=yes>
>>>
>>>
>>>
>>> v=0
>>> o=- 3649316138 3649316139 IN IP4 139.156.126.49
>>> s=-
>>> c=IN IP4 139.156.126.49
>>> t=0 0
>>> m=image 23680 udptl t38
>>> a=T38FaxVersion:0
>>> a=T38MaxBitRate:14400
>>> a=T38FaxRateManagement:transferredTCF
>>> a=T38FaxMaxBuffer:72
>>> a=T38FaxMaxDatagram:316
>>> a=T38FaxUdpEC:t38UDPRedundancy
>>>
>>>
>>> SIP/2.0 404 Not Found
>>> Via: SIP/2.0/UDP
>>> 139.156.126.49:5060;rport=5060;branch=z9hG4bKfofomd006o71lno6s1i0.1
>>> Call-ID: 585966869312000201754 at 192.168.111.25_b2b-1
>>> From:
>>> <sip:+31306665648 at ims.imscore.net>;tag=SDemtl399-127.0.0.1alUtKGp-09752+1+a3000095+156d2c30
>>>
>>>
>>> To:
>>> <sip:+31756418049 at 192.168.111.25>;tag=3D534336-55D9A6A9000B9F71-7E3B2700
>>> CSeq: 98894742 INVITE
>>> Server: Sipwise NGCP Proxy 3.X
>>> Content-Length: 0
>>>
>>> Tristan
>>>
>>>
>>> On 24-08-15 09:08, Daniel Grotti wrote:
>>>> Hi,
>>>> how can you receive a 404 on a re-invite ?
>>>> Does the re-invite have the From-tag and To-tag ?
>>>>
>>>>
>>>> -- 
>>>> Daniel Grotti
>>>> VoIP Engineer
>>>>
>>>>
>>>> Sipwise GmbH
>>>> Europaring F15 | 2345 Brunn am Gebirge, Austria | www.sipwise.com
>>>>
>>>> On 08/24/2015 12:23 AM, Tristan Delsol wrote:
>>>>> 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