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

Wed Aug 26 09:31:42 EDT 2015

ok, remember to disable kamailio debug.
Log is unreadable like that.
if you want to ad verbose:

ngcp-kamctl proxy fifo debug 2
ngcp-kamctl lb fifo debug 2

--
Daniel Grotti
VoIP Engineer

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

On 08/26/2015 03:27 PM, Tristan Delsol wrote:
> Thanks. I just now also saw something in the lb log.
> So Daniel don't waste your time for now. Let me do a bit more digging
> myself.
> 
> Thanks for all the help.
> Tristan
> 
> On 2015-08-26 15:21, Lorenzo Mangani wrote:
>> Tristan,
>>
>> Did not look deep but could likely a side effect to the following
>> error representing over 50% of your log:
>>
>>        ERROR: pv [pv_trans.c:1022]: tr_eval_uri(): invalid uri [0]
>>
>> Regards,
>>
>> Lorenzo
>>
>> On Wed, Aug 26, 2015 at 3:03 PM, Tristan Delsol <tdelsol at qfast.nl>
>> wrote:
>>
>>> Hi Daniel,
>>>
>>> I'm hoping you're not fed up with this one. I did a debug on the
>>> proxy for this and I noticed that for some reason the proxy reads
>>> the Callee as "0". But I'm not sure why. I'm not really familiar
>>> with the debug log.
>>> I hope you can find some spare time to have a look anyways.
>>> On line 959 you can see the "No matching rewrite rules for '0'
>>> found".
>>>
>>> Thanks,
>>> Tristan
>>>
>>> On 2015-08-25 17:13, Tristan Delsol wrote:
>>> I asked them a couple of days back, but it's not possible. They are
>>> flexible as most big telco's are.
>>> I will try and sell them the idea that I will use a separate analog
>>> line for faxing then or something.
>>> Not sure what else to try anymore.
>>>
>>> Tristan
>>>
>>> On 25-08-15 16:43, Daniel Grotti wrote:
>>> Can you disable t38 in such a broken device ?
>>>
>>> -- 
>>> Daniel Grotti
>>> VoIP Engineer
>>>
>>> Sipwise GmbH
>>> Europaring F15 | 2345 Brunn am Gebirge, Austria | www.sipwise.com
>>> [1]
>>>
>>> On 08/25/2015 04:40 PM, Tristan Delsol wrote:
>>> Hi Daniel,
>>>
>>> If I send a 488 back it tries another re-invite with just g711 but
>>> then
>>> I get the 404 not found also. So that one is not working.
>>> Does spce check the request-uri? If so, then I can understand the
>>> 404
>>> because of the weird request-uri.
>>>
>>> On 25-08-15 16:35, Daniel Grotti wrote:
>>> Hi,
>>> how is that possible ?
>>> Did you add a section in LB like ?
>>>
>>> if(is_method("INVITE") && uri =~ "^sip:ngcp-lb;tgrp.+@")
>>> {
>>> sl_send_reply("488", "Not acceptable");
>>> exit;
>>> }
>>>
>>> -- 
>>> Daniel Grotti
>>> VoIP Engineer
>>>
>>> Sipwise GmbH
>>> Europaring F15 | 2345 Brunn am Gebirge, Austria | www.sipwise.com
>>> [1]
>>>
>>> On 08/25/2015 04:32 PM, Tristan Delsol wrote:
>>> Just to be sure I reinstalled the whole box and configured it as
>>> basic
>>> as possible, but unfortunately still getting the 404 not found on
>>> the
>>> re-invite.
>>> Is there anything else I can try?
>>>
>>> Tristan
>>>
>>> On 24-08-15 11:55, Tristan Delsol wrote:
>>> I tried the 488 from LB, but if I do that I still get the same 404
>>> not
>>> found. So I send the 488, the telco ACKs it and then sends a new
>>> INVITE
>>> without T.38 but the same happens with this INVITE, which is the
>>> 404
>>> not
>>> found.
>>>
>>> I have a trace of that one also if you want.
>>>
>>> On 24-08-15 11:40, Daniel Grotti wrote:
>>> 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
>>> [1]
>>>
>>> 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
>>> [1]
>>>
>>> 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 [2]@139.156.126.49:5060
>>> [3];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
>>> [1]
>>>
>>> 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 [1]
>>>
>>> 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 [4]" 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 [4]"))
>>> {
>>> 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
>>> [5]
>>>
>>> Maybe this could help.
>>>
>>> -- 
>>> Daniel Grotti
>>> VoIP Engineer
>>>
>>> Sipwise GmbH
>>> Europaring F15 | 2345 Brunn am Gebirge, Austria |
>>> www.sipwise.com [1]
>>>
>>> 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 [6]@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 [7], 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 [8]
>>  _______________________________________________
>>  Spce-user mailing list
>>  Spce-user at lists.sipwise.com
>>  https://lists.sipwise.com/listinfo/spce-user [8]
>>  _______________________________________________
>>  Spce-user mailing list
>>  Spce-user at lists.sipwise.com
>>  https://lists.sipwise.com/listinfo/spce-user [8]
>>
>>  _______________________________________________
>>  Spce-user mailing list
>>  Spce-user at lists.sipwise.com
>>  https://lists.sipwise.com/listinfo/spce-user [8]
>>  _______________________________________________
>>  Spce-user mailing list
>>  Spce-user at lists.sipwise.com
>>  https://lists.sipwise.com/listinfo/spce-user [8]
>>  _______________________________________________
>>  Spce-user mailing list
>>  Spce-user at lists.sipwise.com
>>  https://lists.sipwise.com/listinfo/spce-user [8]
>>  _______________________________________________
>>  Spce-user mailing list
>>  Spce-user at lists.sipwise.com
>>  https://lists.sipwise.com/listinfo/spce-user [8]
>>  _______________________________________________
>>  Spce-user mailing list
>>  Spce-user at lists.sipwise.com
>>  https://lists.sipwise.com/listinfo/spce-user [8]
>>  _______________________________________________
>>  Spce-user mailing list
>>  Spce-user at lists.sipwise.com
>>  https://lists.sipwise.com/listinfo/spce-user [8]
>>
>>  _______________________________________________
>>  Spce-user mailing list
>>  Spce-user at lists.sipwise.com
>>  https://lists.sipwise.com/listinfo/spce-user [8]
>>  _______________________________________________
>>  Spce-user mailing list
>>  Spce-user at lists.sipwise.com
>>  https://lists.sipwise.com/listinfo/spce-user [8]
>>
>>  _______________________________________________
>>  Spce-user mailing list
>>  Spce-user at lists.sipwise.com
>>  https://lists.sipwise.com/listinfo/spce-user [8]
>> _______________________________________________
>>  Spce-user mailing list
>>  Spce-user at lists.sipwise.com
>>  https://lists.sipwise.com/listinfo/spce-user [8]
>>
>>
>>
>> Links:
>> ------
>> [1] http://www.sipwise.com
>> [2] tel:%2B31306665648
>> [3] http://139.156.126.49:5060
>> [4] http://ipic.imscore.net
>> [5] https://lists.sipwise.com/pipermail/spce-user/2014-June/006788.html
>> [6] tel:%2B31703434343
>> [7] http://127.0.0.1:5080
>> [8] https://lists.sipwise.com/listinfo/spce-user
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> https://lists.sipwise.com/listinfo/spce-user