Hi Guys
I'm trying to get T38 working between our VoIP Provider and my epygi PBX.
I have the epygi registered with openSER when a phone call is received from our provider openSER forwards the call to the epygi. When this unit detects the fax tone it does a re invite. (the re invite has the SDP indicating it want a T38) This re invite never gets to our VoIP provider. OpenSER is blocking the request.
The invite would seem to be hitting our loose routing
if (loose_route()) { xlog("L_NOTICE", "Running loose_route logic"); if ((is_method("INVITE|REFER") && ! has_totag())) { route(ROUTE_AUTHTEST); if (retcode == FALSE) return; };
if (method=="INVITE") { route(ROUTE_AUTHTEST); if (retcode == FALSE) return; };
append_hf("P-hint: rr-enforced\r\n"); route(ROUTE_DEFAULTHANDLER); return; };
route[ROUTE_DEFAULTHANDLER] {
t_on_reply("REPLYROUTE");
if (!t_relay()) { sl_reply_error(); }; }
Any ideas as to what I might have wrong ?
Keep in mind that we are using OpenSER as a part of VoIP service to a small number of customers.
Thanks Mike
Hi Franz
A capture of the sip packets from the epygi showed the T38 reinvite was sent to openser.
Thanks for your question, as I have not been able to find out why this is not working.
Mike
Are you sure that the 2nd INVITE touches OpenSER at all? Otherwise I would guess you did not record-route.
Franz
Internet Protocol, Src: 203.xxx.xxx.xx6 (203.xxx.xxx.xx6), Dst: 118.xxx.xxx.x10 (118.xxx.xxx.x10) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 1077 Identification: 0x0000 (0) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x2be8 [correct] Source: 203.xxx.xxx.xx6 (203.xxx.xxx.xx6) Destination: 118.xxx.xxx.x10 (118.xxx.xxx.x10) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Source port: sip (5060) Destination port: sip (5060) Length: 1057 Checksum: 0x2d6c [correct] Session Initiation Protocol Request-Line: INVITE sip:0883893111@202.xxx.xxx.xx3:5060 SIP/2.0 Method: INVITE Resent Packet: False Message Header Via: SIP/2.0/UDP 203.xxx.xxx.xx6:5060;rport;branch=z9hG4bKEPSVBUS64b55558-a141-4f2c-b16b-a12a8ab6bf3b To: "0883893111" sip:0883893111@202.xxx.xxx.xx3:5060;tag=5aa0fdcc-co3356-INS001 SIP Display info: "0883893111" SIP to address: sip:0883893111@202.xxx.xxx.xx3:5060 SIP tag: 5aa0fdcc-co3356-INS001 From: sip:0888622196@118.xxx.xxx.x10:5060;tag=11979545488eec7fd7-b919-4d3d-97ac-9a723c5b719a SIP from address: sip:0888622196@118.xxx.xxx.x10:5060 SIP tag: 11979545488eec7fd7-b919-4d3d-97ac-9a723c5b719a CSeq: 307 INVITE Call-ID: 0086-0F08-B626A854-0@578365F692451C054 Contact: sip:111020@203.xxx.xxx.xx6:5060 Contact Binding: sip:111020@203.xxx.xxx.xx6:5060 URI: sip:111020@203.xxx.xxx.xx6:5060 SIP contact address: sip:111020@203.xxx.xxx.xx6:5060 Content-Type: application/sdp User-Agent: Epygi Quadro SIP User Agent/v4.1.40 (QUADRO-2X) Max-Forwards: 70 Route: sip:118.xxx.xxx.x10;lr=on;ftag=5aa0fdcc-co3356-INS001 Proxy-Authorization: Digest realm="118.xxx.xxx.x10",nonce="4769e7f5a8ae6f21980eea447f694d68968d77f9",username="111020",uri="sip:0883893111@202.xxx.xxx.xx3:5060",response="9948c4e88338754b0cef4c53665288cf" Content-Length: 217 Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): 111020 309 569 IN IP4 203.xxx.xxx.xx6 Owner Username: 111020 Session ID: 309 Session Version: 569 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 203.xxx.xxx.xx6 Session Name (s): - Connection Information (c): IN IP4 203.xxx.xxx.xx6 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 203.xxx.xxx.xx6 Time Description, active time (t): 0 0 Session Start Time: 0 Session Stop Time: 0 Media Description, name and address (m): image 6030 udptl t38 Media Type: image Media Port: 6030 Media Proto: udptl Media Format: t38 Media Attribute (a): T38FaxVersion:0 Media Attribute Fieldname: T38FaxVersion Media Attribute Value: 0 Media Attribute (a): T38MaxBitRate:14400 Media Attribute Fieldname: T38MaxBitRate Media Attribute Value: 14400 Media Attribute (a): T38FaxRateManagement:transferredTCF Media Attribute Fieldname: T38FaxRateManagement Media Attribute Value: transferredTCF Media Attribute (a): T38FaxUdpEC:t38UDPRedundancy Media Attribute Fieldname: T38FaxUdpEC Media Attribute Value: t38UDPRedundancy
Hi Guys
Does anyone have any idea where I should start to find this problem ?
Mike
Mike O'Connor wrote:
Hi Guys
I'm trying to get T38 working between our VoIP Provider and my epygi PBX.
I have the epygi registered with openSER when a phone call is received from our provider openSER forwards the call to the epygi. When this unit detects the fax tone it does a re invite. (the re invite has the SDP indicating it want a T38) This re invite never gets to our VoIP provider. OpenSER is blocking the request.
The invite would seem to be hitting our loose routing
if (loose_route()) { xlog("L_NOTICE", "Running loose_route logic"); if ((is_method("INVITE|REFER") && ! has_totag())) { route(ROUTE_AUTHTEST); if (retcode == FALSE) return; }; if (method=="INVITE") { route(ROUTE_AUTHTEST); if (retcode == FALSE) return; }; append_hf("P-hint: rr-enforced\r\n"); route(ROUTE_DEFAULTHANDLER); return; };route[ROUTE_DEFAULTHANDLER] {
t_on_reply("REPLYROUTE"); if (!t_relay()) { sl_reply_error(); };}
Any ideas as to what I might have wrong ?
Keep in mind that we are using OpenSER as a part of VoIP service to a small number of customers.
Thanks Mike
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Hi Mike,
Does anyone have any idea where I should start to find this problem ?
Looking at your configuration, seems that both INVITEs and re-INVITEs go to route(ROUTE_AUTHTEST) ... after that, who knows :)
Add some xlog() logs to your script and try to find what occurs with the re-INVITE.
Also, obtain a trace of the signaling with "ngrep -Wbyline -d any - qt . port 5060" (or whatever port you use) and send it to the list.
Regards.
Saludos JesusR.
Mike O'Connor wrote:
Hi Guys
I'm trying to get T38 working between our VoIP Provider and my epygi PBX.
I have the epygi registered with openSER when a phone call is received from our provider openSER forwards the call to the epygi. When this unit detects the fax tone it does a re invite. (the re invite has the SDP indicating it want a T38) This re invite never gets to our VoIP provider. OpenSER is blocking the request.
The invite would seem to be hitting our loose routing
if (loose_route()) { xlog("L_NOTICE", "Running loose_route logic"); if ((is_method("INVITE|REFER") && ! has_totag())) { route(ROUTE_AUTHTEST); if (retcode == FALSE) return; }; if (method=="INVITE") { route(ROUTE_AUTHTEST); if (retcode == FALSE) return; }; append_hf("P-hint: rr-enforced\r\n"); route(ROUTE_DEFAULTHANDLER); return; };route[ROUTE_DEFAULTHANDLER] {
t_on_reply("REPLYROUTE"); if (!t_relay()) { sl_reply_error(); };}
Any ideas as to what I might have wrong ?
Keep in mind that we are using OpenSER as a part of VoIP service to a small number of customers.
Thanks Mike
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
Check your logs to see how the reINVITE is handled by your config. Check how the reINVITE is handled inside route(ROUTE_AUTHTEST) - of course, if it is arriving there.
Regards, Ovidiu Sas
On Dec 23, 2007 5:51 PM, Mike O'Connor mike@pineview.net wrote:
Hi Guys
Does anyone have any idea where I should start to find this problem ?
Mike
Mike O'Connor wrote:
Hi Guys
I'm trying to get T38 working between our VoIP Provider and my epygi PBX.
I have the epygi registered with openSER when a phone call is received from our provider openSER forwards the call to the epygi. When this unit detects the fax tone it does a re invite. (the re invite has the SDP indicating it want a T38) This re invite never gets to our VoIP provider. OpenSER is blocking the request.
The invite would seem to be hitting our loose routing
if (loose_route()) { xlog("L_NOTICE", "Running loose_route logic"); if ((is_method("INVITE|REFER") && ! has_totag())) { route(ROUTE_AUTHTEST); if (retcode == FALSE) return; }; if (method=="INVITE") { route(ROUTE_AUTHTEST); if (retcode == FALSE) return; }; append_hf("P-hint: rr-enforced\r\n"); route(ROUTE_DEFAULTHANDLER); return; };route[ROUTE_DEFAULTHANDLER] {
t_on_reply("REPLYROUTE"); if (!t_relay()) { sl_reply_error(); };}
Any ideas as to what I might have wrong ?
Keep in mind that we are using OpenSER as a part of VoIP service to a small number of customers.
Thanks Mike
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-
Franz Edler -
Jesus Rodriguez -
Mike O'Connor -
Ovidiu Sas