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

Tristan Delsol tdelsol at qfast.nl
Wed Aug 26 09:27:11 EDT 2015


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



More information about the Spce-user mailing list