[Spce-user] NGCP 2.6 - mis-routed replys after 180 ringing

Klaus Peter v. Friedeburg friedeburg at aco.de
Mon Oct 8 08:59:03 EDT 2012


Hello Andrew,

thank you for your reply.
I have tested some days more and I find that is something wrong in OPAL-Lib-3.9.0 which is using by T38modem-2.0.0. I think that Opal have problems to handle the reINVITE's and Port-negatiation of the RTP-Session. There exist a discussion in the OPAL-community.  I solve this problem to insert asterisk in the flow between NGCP and T38modem-2.0.0

Using T38modem-1.2.0 which use OPAL-3.7.7 an ptlib-3.8.3 you have no problems to use t38modem as a SIP-client on NGCP, but T38modem-1.2.0 don’t make fallback to G.711
T38modem-1.2.0 work fine with NGCP as a normal SIP-client, but faxing only with T.38 so you need a mediagateway for faxing to fax-machines in the PSTN ore for fax-machines hanging on a CPW who does't supported T38.

Some VOIP-business providers offer a mediagateway from T38 to PSTN and vice versa. My Provider use a Siemens hiQ9200 and T38-faxing to PSTN have no problems.
But what to do with faxes not going to PSTN but rather going to a SIP-Client who doesn't support T.38 ore using a PSTN Provider who doesn't support T38?
To solve this problem you need a T38 Endpoint which make fallback to G.711. 
Using IAXModem isn't a solution because IAXMODEM only use G.711 as faxprotocoll

The solution is using T38modem-2.0.0!
My success-rate to using T38modem for faxing is 100% with T38 or G711 fallback!

But be aware it is a little bit tricky to compile the sources. Use svn version 24174 of OPAL and PTLIB, you must patch sippdu.cxx of opal in line 1366 (end = val -1;)  and spandsp-0.0.6
If you compile in the /root/t38modem Directory the make lines are:
export PTLIBPLUGINDIR=/usr/local/lib/opal-3.9.0
export PTLIBDIR=/root/ptlib/
export OPALDIR=/root/opal/
make USE_OPAL=1 USE_UNIX98_PTY=1 opt
after that you find the binary in obj_linux_x86_opal\
copy it to /usr/local/bin

here my solution:
Don’t use T38modem-2.0.0 as SIP-client directly on NGCP!!!! Build something like this
Hylafax <--------> T38modem <-------> Asterisk 1.4 <------------> NGCP <------> PSTN-Gateway or other local CPE's (T.38 and not-T.38)

Now I have build a working fax-solution (on 2 dedicated machines) for incomming (fax2mail) and outgoing (fax2fax) faxes:
- Hylafax 4.4.4 (with customized jcontrol-virtual.sh, notify, FaxNotify scripts) with Clientauth via PAM against the kamailio-subscriber table and with job-specific t38modem and faxgetty calls
- Asterisk 1.4
- T38modem 2.0.0 
- a little patch in the kamailio-proxy script vom NGCP:
	- Inserted the faxserver in the dispatcher-list (in mysql, with setid=44)
	- in route[ROUTE_PBX_REQUEST] modify the line 
		if($fu == "sip:reminder at voicebox.sip-test.local" && $rU =~ "^fax\-" && ds_is_from_list("2")); to
		if($fu == "sip:reminder at voicebox.sip-test.local" && $rU =~ "^fax\-") # because ds_ip_from_list give me -1 (don't know why)
	- in route[ROUTE_FIND_CALLER] modify the line
		avp_db_query("select setid from dispatcher where setid=4 and destination='sip:$avp(s:ip):$avp(s:port)'", "$avp(s:tmpfaxgw)"); to
		avp_db_query("select setid from dispatcher where setid=44 and destination='sip:$avp(s:ip):$avp(s:port)'", "$avp(s:tmpfaxgw)");
		and the line
		else if($avp(s:tmpfaxgw) == 4) to 
		else if($avp(s:tmpfaxgw) == 4 || $avp(s:tmpfaxgw) == 44 )
		go 5 lines down and modify the line
		$var(local_endpoint) = 1; to
		$var(local_endpoint) = 0;
	- in route[ROUTE_FAXSERVER]
		Disabled the lines:
			#setbflag(FLB_NATB);
			#$var(local_endpoint) = 1;
		Setting $var(no_sbc) = 1;
	- disabled mediaproxy for calls from faxserver by setting $var(local_endpoint) = 0 for calls from faxserver (yes it has an public IP)

Now you have to customizes the config-scripts for NGCP so that you can using the fax_features (call forwarding to faxserver and setting the fax_preferences) in NGCP-admin

That’s all,
Working with 100% success on sending an receiving faxes over the Network. Only if the customer-CPE don't use T38 and have a slow dirty line to the internet the faxes fail. 
We have tested in our DSL-Network with DSL3000, latency of up to 40ms with and without T.38. Over 40ms you have problems to faxing over G711 because the latency is to great.

To build up this solution I have seen that it where very helpful when NGCP support other generic dispatchers. So the NGCP-user can build up own dispatcher-applications by default, Do you understand what I mean?


          Klaus Peter


> -----Ursprüngliche Nachricht-----
> Von: Andrew Pogrebennyk [mailto:apogrebennyk at sipwise.com]
> Gesendet: Sonntag, 7. Oktober 2012 16:43
> An: Klaus Peter v. Friedeburg
> Cc: spce-user at lists.sipwise.com
> Betreff: Re: AW: [Spce-user] NGCP 2.6 - mis-routed replys after 180 ringing
> 
> Hello Klaus,
> 
> Well, I'm not sure what is wrong, signaling looks perfectly fine to me
> and 200 OK has proper Contact and Record-Route headers. But there's no
> ACK from the caller. Is it possible to check the trace on machine with
> T38Modem? Any debug information from it?
> 
> Also kamailio-proxy log doesn't say about mis-routed packets in this
> case because neither proxy nor lb received an ACK from T38Modem, right?
> 
> Andrew
> 
> On 10/05/2012 10:11 PM, Klaus Peter v. Friedeburg wrote:
> > Hi Andrew,
> >
> > I have sended the PCAP-File dirercly to your Email-account.
> > When I see it right the ports in the contact header fields from T38Modem are the same as the sending ports.
> >
> > I don’t know what is wrong ....
> >
> > I have made an other test: Relaying the calls from T38Modem over an Asterisk, there are no misrouted
> packets. 2 from 5 faxes are sended without any errors. But this is no solution because asterisk (1.4) dont make
> T38 passthrougt with fallback to G711 right.
> > My target is to build up a fax solution which is transparent for ngcp and handled as a normal SIP-CPE, so that
> no patches in the kamailio scripts are nessesary.
> >
> >
> > Klaus Peter
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: Andrew Pogrebennyk [mailto:apogrebennyk at sipwise.com]
> >> Gesendet: Freitag, 5. Oktober 2012 15:14
> >> An: Klaus Peter v. Friedeburg
> >> Cc: spce-user at lists.sipwise.com
> >> Betreff: Re: [Spce-user] NGCP 2.6 - mis-routed replys after 180 ringing
> >>
> >> Hi Klaus,
> >>
> >> Maybe a full trace for the failed case including replies and ACK and
> >> port numbers would help, I just don't see the port information in this one.
> >>
> >> The problem I've had with T38modem is it was sending the request from
> >> different port than it puts into Contact and Via, but the log says ACK
> >> is incorrect so we need to check Record-Routing and RURI in the ACK too.
> >>
> >> On 10/05/2012 03:06 PM, Klaus Peter v. Friedeburg wrote:
> >>> Hi,
> >>>
> >>> I have problems with mis-routed replys in NGCP 2.6:
> >>>
> >>> This is an initial Invite that works:
> >>> *******************************************************************
> >>> INVITE sip:9830355 at sip-test.aco-connect.de SIP/2.0
> >>> Date: Fri, 05 Oct 2012 12:05:51 GMT
> >>> CSeq: 2 INVITE
> >>> Via: SIP/2.0/UDP 81.90.192.217:25614;branch=z9hG4bKdc6301ad-520d-e211-9999-000c296dbef0;rport
> >>> User-Agent: T38Modem/1.2.0
> >>> From: "root" <sip:004956199797437 at sip-test.aco-connect.de>;tag=a061f9ac-520d-e211-9999-
> 000c296dbef0
> >>> Call-ID: 3270f9ac-520d-e211-9999-000c296dbef0 at fax2fax-test.aco-connect.de
> >>> Organization: Vyacheslav Frolov
> >>> To: <sip:9830355 at sip-test.aco-connect.de>
> >>> Contact: <sip:004956199797437 at 81.90.192.217:25614>
> >>> Proxy-Authorization: Digest username="004956199797437", realm="sip-test.aco-connect.de",
> >> nonce="xxxxxxxxx", uri="sip:9830355 at sip-test.aco-connect.de", algorithm=MD5, response="xxxxxxxxxx"
> >>> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING
> >>> Content-Type: application/sdp
> >>> Content-Length: 264
> >>> Max-Forwards: 70
> >>>
> >>> v=0
> >>> o=- 1349438751 1 IN IP4 81.90.192.217
> >>> s=Opal SIP Session
> >>> c=IN IP4 81.90.192.217
> >>> t=0 0
> >>> m=audio 5000 RTP/AVP 8 101 100
> >>> a=sendrecv
> >>> a=rtpmap:8 PCMA/8000/1
> >>> a=rtpmap:101 telephone-event/8000
> >>> a=fmtp:101 0-16,32,36
> >>> a=rtpmap:100 NSE/8000
> >>> a=fmtp:100 192-193
> >>> *******************************************************************
> >>>
> >>> This is an other initial Invite from the same machine that does not work!
> >>> *******************************************************************
> >>> INVITE sip:9830355 at sip-test.aco-connect.de SIP/2.0
> >>> CSeq: 2 INVITE
> >>> Via: SIP/2.0/UDP 81.90.192.217:32770;branch=z9hG4bK50a6fce0-580d-e211-964b-000c296dbef0;rport
> >>> User-Agent: T38Modem/2.0.0
> >>> From: "root" <sip:004956199797437 at sip-test.aco-connect.de>;tag=707ff4e0-580d-e211-964b-
> 000c296dbef0
> >>> Call-ID: e087f4e0-580d-e211-964b-000c296dbef0 at fax2fax-test.aco-connect.de
> >>> Organization: Vyacheslav Frolov
> >>> To: <sip:9830355 at sip-test.aco-connect.de>
> >>> Contact: <sip:004956199797437 at 81.90.192.217:32770>
> >>> Proxy-Authorization: Digest username="004956199797437", realm="sip-test.aco-connect.de", nonce="
> >> xxxxxxxxx", uri="sip:9830355 at sip-test.aco-connect.de", algorithm=MD5, response=" xxxxxxxxx"
> >>> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING
> >>> Content-Type: application/sdp
> >>> Content-Length: 231
> >>> Max-Forwards: 70
> >>>
> >>> v=0
> >>> o=- 1349441415 1 IN IP4 81.90.192.217
> >>> s=T38Modem/2.0.0
> >>> c=IN IP4 81.90.192.217
> >>> t=0 0
> >>> m=audio 5000 RTP/AVP 8 101
> >>> a=sendrecv
> >>> a=rtpmap:8 PCMA/8000/1
> >>> a=rtpmap:101 telephone-event/8000
> >>> a=fmtp:101 0-16,32,36
> >>> a=maxptime:240
> >>> *******************************************************************
> >>>
> >>> The kamailio-proxy log show this:
> >>> *******************************************************************
> >>> Oct  5 14:50:15 sip3 /usr/sbin/kamailio[2436]: INFO: <script>: Appending P-D-URI
> >> 'sip:192.168.100.55:5060;received='sip:62.180.237.70:5060;transport=udp'' - R=sip:4
> >>> 95619830355 at 62.180.237.70:5060;transport=udp ID=e087f4e0-580d-e211-964b-000c296dbef0 at fax2fax-
> >> test.aco-connect.de
> >>> Oct  5 14:50:15 sip3 /usr/sbin/kamailio[2436]: INFO: <script>: Forcing request via B2BUA
> >> 'sip:192.168.100.55:5080' - R=sip:495619830355 at 62.180.237.70:5060;transport
> >>> =udp ID=e087f4e0-580d-e211-964b-000c296dbef0 at fax2fax-test.aco-connect.de
> >>> Oct  5 14:50:15 sip3 /usr/sbin/kamailio[2436]: INFO: <script>: Setting P-Caller-UUID to '18205f5a-cfe6-49fc-
> >> 9937-0a64d090498b' - R=sip:495619830355 at 62.180.237.70:50
> >>> 60;transport=udp ID=e087f4e0-580d-e211-964b-000c296dbef0 at fax2fax-test.aco-connect.de
> >>> Oct  5 14:50:15 sip3 /usr/sbin/kamailio[2436]: INFO: <script>: Setting P-Callee-UUID to '0' -
> >> R=sip:495619830355 at 62.180.237.70:5060;transport=udp ID=e087f4e0-580d-e
> >>> 211-964b-000c296dbef0 at fax2fax-test.aco-connect.de
> >>> Oct  5 14:50:15 sip3 /usr/sbin/kamailio[2436]: INFO: <script>: Request leaving server, D-
> >> URI='sip:192.168.100.55:5080' - R=sip:495619830355 at 62.180.237.70:5060;trans
> >>> port=udp ID=e087f4e0-580d-e211-964b-000c296dbef0 at fax2fax-test.aco-connect.de
> >>> Oct  5 14:50:15 sip3 /usr/sbin/kamailio[2439]: INFO: <script>: NAT-Reply - S=100 - Connecting M=INVITE
> >> IP=81.90.192.217:32770 (192.168.100.55:5080) ID=e087f4e0-580d
> >>> -e211-964b-000c296dbef0 at fax2fax-test.aco-connect.de
> >>> Oct  5 14:50:18 sip3 /usr/sbin/kamailio[2428]: INFO: <script>: NAT-Reply - S=180 - Ringing M=INVITE
> >> IP=81.90.192.217:32770 (192.168.100.55:5080) ID=e087f4e0-580d-e2
> >>> 11-964b-000c296dbef0 at fax2fax-test.aco-connect.de
> >>> Oct  5 14:50:23 sip3 /usr/sbin/kamailio[2444]: INFO: <script>: NAT-Reply - S=200 - OK M=INVITE
> >> IP=81.90.192.217:32770 (192.168.100.55:5080) ID=e087f4e0-580d-e211-96
> >>> 4b-000c296dbef0 at fax2fax-test.aco-connect.de
> >>> Oct  5 14:50:23 sip3 /usr/sbin/kamailio[2448]: INFO: <script>: New request - M=ACK R=sip:9830355 at sip-
> >> test.aco-connect.de F=sip:004956199797437 at sip-test.aco-connect.
> >>> de T=sip:9830355 at sip-test.aco-connect.de IP=81.90.192.217:32770 (192.168.100.55:5060) ID=e087f4e0-
> >> 580d-e211-964b-000c296dbef0 at fax2fax-test.aco-connect.de
> >>> Oct  5 14:50:23 sip3 /usr/sbin/kamailio[2448]: INFO: <script>: Relaying request, du='<null>' -
> >> R=sip:9830355 at sip-test.aco-connect.de ID=e087f4e0-580d-e211-964b-000c
> >>> 296dbef0 at fax2fax-test.aco-connect.de
> >>> Oct  5 14:50:23 sip3 /usr/sbin/kamailio[2442]: INFO: <script>: New request - M=ACK R=sip:9830355 at sip-
> >> test.aco-connect.de F=sip:056199797437 at sip-test.aco-connect.de
> >>> T=sip:9830355 at sip-test.aco-connect.de IP=81.90.192.214:5060 (192.168.100.55:5060) ID=e087f4e0-
> 580d-
> >> e211-964b-000c296dbef0 at fax2fax-test.aco-connect.de
> >>> Oct  5 14:50:23 sip3 /usr/sbin/kamailio[2442]: INFO: <script>: Dropping mis-routed request -
> >> R=sip:9830355 at sip-test.aco-connect.de ID=e087f4e0-580d-e211-964b-000c29
> >>> 6dbef0 at fax2fax-test.aco-connect.de
> >>> *******************************************************************
> >>>
> >>> Nothing in sems log!
> >>>
> >>> The differences are in the SDP body
> >>> But what is wrong?????
> >>>
> >>>
> >>> _______________________________________________
> >>> Spce-user mailing list
> >>> Spce-user at lists.sipwise.com
> >>> http://lists.sipwise.com/listinfo/spce-user
> >>>
> >





More information about the Spce-user mailing list