Dear All,
Does anyone has an experience with Incoming FAX T38 using a PUBLIC IP on endpoint?
Regards
Dear Oliver,
I'm using asterisk as Gateway behind Kamailio...I need to force rtp proxy for FAX...The issue that T38 is failing on asterisk...I need to know if there is any working config file for that
Regards
On Thu, Mar 12, 2009 at 11:10 PM, olivier taylor olivier@sunforyou.bewrote:
Kamailo, openser, ser and others doesn't take care of the media. Even if you use RtpProxy or MediaProxy, they are pass-thru proxies, they doens't care of the codec used.
If you want T38 for faxes, go to the asterisk or callweaver list. Afaik, fax over IP is a pity, I have tried with 80% success, no more, it means20% loss, even with a public IP and T38.
That's my poor experience.
Olivier
michel freiha a écrit :
Dear All,
Does anyone has an experience with Incoming FAX T38 using a PUBLIC IP on endpoint?
Regards
Kamailio (OpenSER) - Users mailing listUsers@lists.kamailio.orghttp://lists.kamailio.org/cgi-bin/mailman/listinfo/usershttp://lists.openser...
Dear Sir,
I do not have any problem in the first INVITE...The one that contains G711 in the SDP...The problem in the REINVITE...The one that cotains T.38...Kamailio does not accept the INVITE and asterisk continue sendin the INVITE times and times to kamailio...Please find below the config:
if(does_uri_exist()){ # local uri does exist, is probably a user. xlog("L_INFO","User Exists UUUUUUUUUUUUUUUUUUUUUUEEEEEEEEEEEEEEEEEEEEEEE");
# lookup location if(lookup("location")){ xlog("L_INFO","User Online UUUUUUUUUUUUUUUUUUUUUOOOOOOOOOOOOOOOOOOOOOOOO");
t_on_failure("1"); t_on_reply("1"); force_rtp_proxy(); t_relay();
and the second INVITE:
if(is_method("INVITE")) {
t_on_failure("1"); t_on_reply("1"); t_relay();
}
onreply_route[1] { # if (t_check_status("2[0-9][0-9]") ) if((t_check_status("200|183|180") && search("Content_Type: application/sdp")) || search("Content-Type: application/sdp"))
{ force_rtp_proxy(); } exit; }
Any suggestions here?
Regards
Regards
On Fri, Mar 13, 2009 at 12:08 AM, hh174 olivier@hh174.be wrote:
HI again,
As said before, this is not the right list for that, just go to asterisk or callweaver list. I have tried a lot and didn't get a trustable Foip solution, anyhow, Kamailo is a proxy, not an endpoint. Asterisk and callweaver have many threads about faxing. Sorry and good luck.
Olivier
michel freiha a écrit :
Dear Oliver,
I'm using asterisk as Gateway behind Kamailio...I need to force rtp proxy for FAX...The issue that T38 is failing on asterisk...I need to know if there is any working config file for that
Regards
On Thu, Mar 12, 2009 at 11:10 PM, olivier taylor olivier@sunforyou.bewrote:
Kamailo, openser, ser and others doesn't take care of the media. Even if you use RtpProxy or MediaProxy, they are pass-thru proxies, they doens't care of the codec used.
If you want T38 for faxes, go to the asterisk or callweaver list. Afaik, fax over IP is a pity, I have tried with 80% success, no more, it means20% loss, even with a public IP and T38.
That's my poor experience.
Olivier
michel freiha a écrit :
Dear All,
Does anyone has an experience with Incoming FAX T38 using a PUBLIC IP on endpoint?
Regards
Kamailio (OpenSER) - Users mailing listUsers@lists.kamailio.orghttp://lists.kamailio.org/cgi-bin/mailman/listinfo/usershttp://lists.openser...
2009/3/12 michel freiha michofr@gmail.com:
Dear Sir,
I do not have any problem in the first INVITE...The one that contains G711 in the SDP...The problem in the REINVITE...The one that cotains T.38...Kamailio does not accept the INVITE and asterisk continue sendin the INVITE times and times to kamailio...Please find below the config:
I hope you are not using "if(does_uri_exist())" to check the re-INVITE since the RURI will never match a local URI (it's the *target* URI in fact, the "Contact" URI of the other endpoint of the dialog).
The re-INVITE should be handled in "loose_route()" section as *usual*, but in that section you should also enable RtpProxy for the INVITE request and for the 200 response. No more.
So, you have a *basic* problem with your proxy configuration and in-dialog requests routing. Check with ngrep what is happening in fact.
Regards.
Dear Inaki,
Thanks a lot for your reply...The INVITE check is created outside the URI existing check...But It was not inside the loose route function...I have implemented it now as you said...I need please to check below and let me know if I'm missing anything here
if(loose_route()){
if((t_check_status("200|183|180") && search("Content_Type: application/sdp")) || search("Content-Type: application/sdp"))
{ t_on_failure("1"); t_on_reply("6"); force_rtp_proxy(); t_relay();
}
if (is_method("INVITE")) { t_on_failure("1"); t_on_reply("6"); force_rtp_proxy(); t_relay();
} }
onreply_route[6] {
force_rtp_proxy();
exit; }
Thanks again for your help
Regards
On Fri, Mar 13, 2009 at 12:08 AM, hh174 olivier@hh174.be wrote:
HI again,
As said before, this is not the right list for that, just go to asterisk or callweaver list. I have tried a lot and didn't get a trustable Foip solution, anyhow, Kamailo is a proxy, not an endpoint. Asterisk and callweaver have many threads about faxing. Sorry and good luck.
Olivier
michel freiha a écrit :
Dear Oliver,
I'm using asterisk as Gateway behind Kamailio...I need to force rtp proxy for FAX...The issue that T38 is failing on asterisk...I need to know if there is any working config file for that
Regards
On Thu, Mar 12, 2009 at 11:10 PM, olivier taylor olivier@sunforyou.bewrote:
Kamailo, openser, ser and others doesn't take care of the media. Even if you use RtpProxy or MediaProxy, they are pass-thru proxies, they doens't care of the codec used.
If you want T38 for faxes, go to the asterisk or callweaver list. Afaik, fax over IP is a pity, I have tried with 80% success, no more, it means20% loss, even with a public IP and T38.
That's my poor experience.
Olivier
michel freiha a écrit :
Dear All,
Does anyone has an experience with Incoming FAX T38 using a PUBLIC IP on endpoint?
Regards
Kamailio (OpenSER) - Users mailing listUsers@lists.kamailio.orghttp://lists.kamailio.org/cgi-bin/mailman/listinfo/usershttp://lists.openser...
2009/3/13 michel freiha michofr@gmail.com:
Dear Inaki,
Thanks a lot for your reply...The INVITE check is created outside the URI existing check...But It was not inside the loose route function...I have implemented it now as you said...I need please to check below and let me know if I'm missing anything here
if(loose_route()){
if((t_check_status("200|183|180") && search("Content_Type: application/sdp")) || search("Content-Type: application/sdp"))
I don't like at all that "t_check_status" into loose_route section. Instead add "t_on_reply("X")" into loose_route section.
On Thursday 12 March 2009, olivier taylor wrote:
Kamailo, openser, ser and others doesn't take care of the media. Even if you use RtpProxy or MediaProxy, they are pass-thru proxies, they doens't care of the codec used.
If you want T38 for faxes, go to the asterisk or callweaver list. Afaik, fax over IP is a pity, I have tried with 80% success, no more, it means20% loss, even with a public IP and T38.
That's my poor experience.
Hi olivier,
we're providing T.38 for our customers (and probably a lot others too), so i'd like to say that its possible to have a way better success rate. :-) But i agree, its not easy, and sometimes a pain. ;-)
Cheers,
Henning
Dear Inaki,
Thenaks agian for your responses and care...I did what you asked to do...Just have a look please to the below:
if(loose_route()){
t_on_reply("7"); if (is_method("INVITE")) {
t_on_failure("1"); t_on_reply("6"); force_rtp_proxy(); t_relay();
} }
And the onreply_route(7) will be:
onreply_route[7] {
if (status=~"200"){ t_on_failure("1"); t_on_reply("6"); force_rtp_proxy(); t_relay();
} exit; }
Regards
On Fri, Mar 13, 2009 at 12:37 PM, Henning Westerholt < henning.westerholt@1und1.de> wrote:
On Thursday 12 March 2009, olivier taylor wrote:
Kamailo, openser, ser and others doesn't take care of the media. Even if you use RtpProxy or MediaProxy, they are pass-thru proxies, they doens't care of the codec used.
If you want T38 for faxes, go to the asterisk or callweaver list. Afaik, fax over IP is a pity, I have tried with 80% success, no more, it means20% loss, even with a public IP and T38.
That's my poor experience.
Hi olivier,
we're providing T.38 for our customers (and probably a lot others too), so i'd like to say that its possible to have a way better success rate. :-) But i agree, its not easy, and sometimes a pain. ;-)
Cheers,
Henning
2009/3/13 michel freiha michofr@gmail.com:
Dear Inaki,
Thenaks agian for your responses and care...I did what you asked to do...Just have a look please to the below:
It's wrong:
if(loose_route()){
t_on_reply("7"); if (is_method("INVITE")) {
t_on_failure("1"); t_on_reply("6");
^^^ This t_on_reply("6") is overriding the previous t_on_reply("7").
force_rtp_proxy(); t_relay();
} }
And the onreply_route(7) will be:
onreply_route[7] {
if (status=~"200"){ t_on_failure("1"); t_on_reply("6");
^^^ You cannot use t_on_reply and t_on_failure in a onreply_route block.
force_rtp_proxy(); t_relay();
} exit; }
Hi Inaki,
I'm getting the below error when using t_relay(); in onreply_route[7]....Maybe i need to you something else?
Mar 13 13:11:03 [27785] DBG:core:find_cmd_export_t: <t_relay> not found Mar 13 13:11:03 [27785] DBG:core:find_cmd_export_t: found <t_relay>(0) in module tm [/usr/local/lib/opensips/modules/] Mar 13 13:11:03 [27785] CRITICAL:core:yyerror: parse error in config file, line 728, column 9-10: Command cannot be used in the block
Regards
On Fri, Mar 13, 2009 at 1:15 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
2009/3/13 michel freiha michofr@gmail.com:
Dear Inaki,
Thenaks agian for your responses and care...I did what you asked to do...Just have a look please to the below:
It's wrong:
if(loose_route()){
t_on_reply("7"); if (is_method("INVITE")) {
t_on_failure("1"); t_on_reply("6");
^^^This t_on_reply("6") is overriding the previous t_on_reply("7").
force_rtp_proxy(); t_relay();
} }
And the onreply_route(7) will be:
onreply_route[7] {
if (status=~"200"){ t_on_failure("1"); t_on_reply("6");
^^^You cannot use t_on_reply and t_on_failure in a onreply_route block.
force_rtp_proxy(); t_relay();
} exit; }
-- Iñaki Baz Castillo ibc@aliax.net
2009/3/13 michel freiha michofr@gmail.com:
Hi Inaki,
I'm getting the below error when using t_relay(); in onreply_route[7]....Maybe i need to you something else?
Mar 13 13:11:03 [27785] DBG:core:find_cmd_export_t: <t_relay> not found Mar 13 13:11:03 [27785] DBG:core:find_cmd_export_t: found <t_relay>(0) in module tm [/usr/local/lib/opensips/modules/] Mar 13 13:11:03 [27785] CRITICAL:core:yyerror: parse error in config file, line 728, column 9-10: Command cannot be used in the block
^^^^^ The error IS clearle explained, isn't?
Please check the doc about t_relay():
http://www.kamailio.org/docs/modules/devel/tm.html#id2506628
"This function can be used from REQUEST_ROUTE, FAILURE_ROUTE."
You can't use t_relay in on_replyroute (in fact you don't need it at all, t_relay is used to send *requests*).
Again, please read the documentation and tutorials instead of trying anything with no reason.
Regards.
Dear Sir,
My last issue is the following...The asterisk server replies by a second INVITE that contains T38 in SDP to kamailio...Asterisk continue retransmitting the INVITE to Kamailio with no reply from it as you can see below:
Retransmitting #6 (no NAT) to Kamailio_IP:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP Kamailio_IP;branch=z9hG4bK02e7.7581e8a2.0;received=Kamailio_IP Via: SIP/2.0/UDP 14.14.14.58:5060 ;received=79.132.227.35;branch=z9hG4bK-ba26313a;rport=45068 Record-Route: sip:Kamailio_IP;lr=on From: sip:151355001@Kamailio_IP;tag=c75da877876e372i0 To: "092968050" sip:092968050@Asterisk_IP;tag=as24bf1176 Call-ID: 6cb855a76b6ab33736cc85a83f9d7633@Asterisk_IP CSeq: 101 INVITE User-Agent: domain name Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: sip:092968050@Asterisk_IP Content-Type: application/sdp Content-Length: 354
v=0 o=root 26580 26581 IN IP4 Asterisk_IP s=session c=IN IP4 Asterisk_IP t=0 0 m=image 4338 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:122 a=T38FaxMaxDatagram:122 a=T38FaxUdpEC:t38UDPRedundancy
Kamailio enter in the following function:
onreply_route[7] {
if (status=~ "200"){ t_on_failure("1"); force_rtp_proxy(); } exit; }
I would like to know please what could be added in the onreply_route[7] in order to accept T38 negotiation and let the FAX go through
Regards
On Fri, Mar 13, 2009 at 1:35 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
2009/3/13 michel freiha michofr@gmail.com:
Hi Inaki,
I'm getting the below error when using t_relay(); in onreply_route[7]....Maybe i need to you something else?
Mar 13 13:11:03 [27785] DBG:core:find_cmd_export_t: <t_relay> not found Mar 13 13:11:03 [27785] DBG:core:find_cmd_export_t: found <t_relay>(0) in module tm [/usr/local/lib/opensips/modules/] Mar 13 13:11:03 [27785] CRITICAL:core:yyerror: parse error in config
file,
line 728, column 9-10: Command cannot be used in the block
^^^^^ The error IS clearle explained, isn't?Please check the doc about t_relay():
http://www.kamailio.org/docs/modules/devel/tm.html#id2506628
"This function can be used from REQUEST_ROUTE, FAILURE_ROUTE."
You can't use t_relay in on_replyroute (in fact you don't need it at all, t_relay is used to send *requests*).
Again, please read the documentation and tutorials instead of trying anything with no reason.
Regards.
-- Iñaki Baz Castillo ibc@aliax.net
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
2009/3/13 michel freiha michofr@gmail.com:
I would like to know please what could be added in the onreply_route[7] in order to accept T38 negotiation and let the FAX go through
As others have already explained, Kamailio has *nothing* to do with T38 negociation. You have a problem in your configuration when dealing with in-dialog requests, just it.
You mean config problem outside Kamailio?
Regards
On Fri, Mar 13, 2009 at 4:09 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
2009/3/13 michel freiha michofr@gmail.com:
I would like to know please what could be added in the onreply_route[7]
in
order to accept T38 negotiation and let the FAX go through
As others have already explained, Kamailio has *nothing* to do with T38 negociation. You have a problem in your configuration when dealing with in-dialog requests, just it.
-- Iñaki Baz Castillo ibc@aliax.net
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Dear Sir,
Please find below the Inbount negotioation function
if(does_uri_exist()){ # local uri does exist, is probably a user. # lookup location if(lookup("location")){
t_on_failure("1"); t_on_reply("1"); force_rtp_proxy(); t_relay(); }
Anything wrong here? Regards
On Fri, Mar 13, 2009 at 4:13 PM, michel freiha michofr@gmail.com wrote:
You mean config problem outside Kamailio?
Regards
On Fri, Mar 13, 2009 at 4:09 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
2009/3/13 michel freiha michofr@gmail.com:
I would like to know please what could be added in the onreply_route[7]
in
order to accept T38 negotiation and let the FAX go through
As others have already explained, Kamailio has *nothing* to do with T38 negociation. You have a problem in your configuration when dealing with in-dialog requests, just it.
-- Iñaki Baz Castillo ibc@aliax.net
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
2009/3/13 michel freiha michofr@gmail.com:
Dear Sir,
Please find below the Inbount negotioation function
if(does_uri_exist()){ # local uri does exist, is probably a user. # lookup location if(lookup("location")){
t_on_failure("1"); t_on_reply("1"); force_rtp_proxy(); t_relay(); }
Anything wrong here?
Nothing wrong there. I meant an error in your in-dialog section.
2009/3/13 michel freiha michofr@gmail.com:
You mean config problem outside Kamailio?
No, in kamailio config file. Check with ngrep how the re-INVITE is routed and also its 200 and ACK.
Dear Sir,
Kindly note that incoming voice is doing well in the Same Scenario...The issue is just with FAX because REINVITE is there...Please find below a trace taken from Kamailio...Please check and let me know about your comments
U +9.821258 79.132.227.35:45068 -> Kamailio_IP:5060 SIP/2.0 200 OK. To: sip:151355001@Kamailio_IP;tag=32ffee79a7f15755i0. From: "0473236354" sip:0473236354@Asterisk_IP;tag=as27afe4d7. Call-ID: 71d222ac7b77f421693e27aa4c921e12@Asterisk_IP. CSeq: 102 INVITE. Via: SIP/2.0/UDP Kamailio_IP;branch=z9hG4bKaa3b.6b1a7bf5.0. Via: SIP/2.0/UDP Asterisk_IP:5060;received=Asterisk_IP;branch=z9hG4bK34897521;rport=5060. Record-Route: sip:Kamailio_IP;lr=on. Contact: 28945557 sip:151355001@14.14.14.58:5060. Server: Linksys/SPA2102-3.3.6. Remote-Party-ID: 28945557 <sip:151355001@Kamailio_IP
;screen=yes;party=called.
Content-Length: 202. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. Supported: x-sipura. Content-Type: application/sdp. . v=0. o=- 26875 26875 IN IP4 14.14.14.58. s=-. c=IN IP4 14.14.14.58. t=0 0. m=audio 16418 RTP/AVP 0 101. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv.
U +0.000787 Kamailio_IP:5060 -> Asterisk_IP:5060 SIP/2.0 200 OK. To: sip:151355001@Kamailio_IP;tag=32ffee79a7f15755i0. From: "0473236354" sip:0473236354@Asterisk_IP;tag=as27afe4d7. Call-ID: 71d222ac7b77f421693e27aa4c921e12@Asterisk_IP. CSeq: 102 INVITE. Via: SIP/2.0/UDP Asterisk_IP:5060;received=Asterisk_IP;branch=z9hG4bK34897521;rport=5060. Record-Route: sip:Kamailio_IP;lr=on. Contact: 28945557 sip:151355001@14.14.14.58:5060. Server: Linksys/SPA2102-3.3.6. Remote-Party-ID: 28945557 <sip:151355001@Kamailio_IP
;screen=yes;party=called.
Content-Length: 223. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. Supported: x-sipura. Content-Type: application/sdp. . v=0. o=- 26875 26875 IN IP4 14.14.14.58. s=-. c=IN IP4 Kamailio_IP. t=0 0. m=audio 36344 RTP/AVP 0 101. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. a=nortpproxy:yes.
U +0.530852 79.132.227.35:45068 -> Kamailio_IP:5060 SIP/2.0 200 OK. To: sip:151355001@Kamailio_IP;tag=32ffee79a7f15755i0. From: "0473236354" sip:0473236354@Asterisk_IP;tag=as27afe4d7. Call-ID: 71d222ac7b77f421693e27aa4c921e12@Asterisk_IP. CSeq: 102 INVITE. Via: SIP/2.0/UDP Kamailio_IP;branch=z9hG4bKaa3b.6b1a7bf5.0. Via: SIP/2.0/UDP Asterisk_IP:5060;received=Asterisk_IP;branch=z9hG4bK34897521;rport=5060. Record-Route: sip:Kamailio_IP;lr=on. Contact: 28945557 sip:151355001@14.14.14.58:5060. Server: Linksys/SPA2102-3.3.6. Remote-Party-ID: 28945557 <sip:151355001@Kamailio_IP
;screen=yes;party=called.
Content-Length: 202. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. Supported: x-sipura. Content-Type: application/sdp. . v=0. o=- 26875 26875 IN IP4 14.14.14.58. s=-. c=IN IP4 14.14.14.58. t=0 0. m=audio 16418 RTP/AVP 0 101. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv.
U +0.001586 Kamailio_IP:5060 -> Asterisk_IP:5060 SIP/2.0 200 OK. To: sip:151355001@Kamailio_IP;tag=32ffee79a7f15755i0. From: "0473236354" sip:0473236354@Asterisk_IP;tag=as27afe4d7. Call-ID: 71d222ac7b77f421693e27aa4c921e12@Asterisk_IP. CSeq: 102 INVITE. Via: SIP/2.0/UDP Asterisk_IP:5060;received=Asterisk_IP;branch=z9hG4bK34897521;rport=5060. Record-Route: sip:Kamailio_IP;lr=on. Contact: 28945557 sip:151355001@14.14.14.58:5060. Server: Linksys/SPA2102-3.3.6. Remote-Party-ID: 28945557 <sip:151355001@Kamailio_IP
;screen=yes;party=called.
Content-Length: 223. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. Supported: x-sipura. Content-Type: application/sdp. . v=0. o=- 26875 26875 IN IP4 14.14.14.58. s=-. c=IN IP4 Kamailio_IP. t=0 0. m=audio 36344 RTP/AVP 0 101. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. a=nortpproxy:yes.
U +2.253091 79.132.227.35:45068 -> Kamailio_IP:5060 INVITE sip:0473236354@Asterisk_IP SIP/2.0. Via: SIP/2.0/UDP 14.14.14.58:5060;branch=z9hG4bK-6224e334;rport. From: sip:151355001@Kamailio_IP;tag=32ffee79a7f15755i0. To: "0473236354" sip:0473236354@Asterisk_IP;tag=as27afe4d7. Remote-Party-ID: 28945557 <sip:151355001@Kamailio_IP
;screen=yes;party=called.
Call-ID: 71d222ac7b77f421693e27aa4c921e12@Asterisk_IP. CSeq: 101 INVITE. Max-Forwards: 70. Route: sip:Kamailio_IP;lr=on. Contact: 28945557 sip:151355001@14.14.14.58:5060. Expires: 30. User-Agent: Linksys/SPA2102-3.3.6. Content-Length: 261. Content-Type: application/sdp. . v=0. o=- 28218 28218 IN IP4 14.14.14.58. s=-. c=IN IP4 14.14.14.58. t=0 0. m=image 16418 udptl t38. a=T38FaxVersion:0. a=T38MaxBitRate:14400. a=T38FaxRateManagement:transferredTCF. a=T38FaxMaxBuffer:200. a=T38FaxMaxDatagram:200. a=T38FaxUdpEC:t38UDPRedundancy.
U +0.003427 Kamailio_IP:5060 -> Asterisk_IP:5060 INVITE sip:0473236354@Asterisk_IP SIP/2.0. Record-Route: sip:Kamailio_IP;lr=on. Via: SIP/2.0/UDP Kamailio_IP;branch=z9hG4bKda3b.326bee4.0. Via: SIP/2.0/UDP 14.14.14.58:5060 ;received=79.132.227.35;branch=z9hG4bK-6224e334;rport=45068. From: sip:151355001@Kamailio_IP;tag=32ffee79a7f15755i0. To: "0473236354" sip:0473236354@Asterisk_IP;tag=as27afe4d7. Remote-Party-ID: 28945557 <sip:151355001@Kamailio_IP
;screen=yes;party=called.
Call-ID: 71d222ac7b77f421693e27aa4c921e12@Asterisk_IP. CSeq: 101 INVITE. Max-Forwards: 69. Contact: 28945557 sip:151355001@79.132.227.35:45068. Expires: 30. User-Agent: Linksys/SPA2102-3.3.6. Content-Length: 282. Content-Type: application/sdp. . v=0. o=- 28218 28218 IN IP4 14.14.14.58. s=-. c=IN IP4 Kamailio_IP. t=0 0. m=image 36344 udptl t38. a=T38FaxVersion:0. a=T38MaxBitRate:14400. a=T38FaxRateManagement:transferredTCF. a=T38FaxMaxBuffer:200. a=T38FaxMaxDatagram:200. a=T38FaxUdpEC:t38UDPRedundancy. a=nortpproxy:yes.
U +0.372411 79.132.227.35:45068 -> Kamailio_IP:5060 INVITE sip:0473236354@Asterisk_IP SIP/2.0. Via: SIP/2.0/UDP 14.14.14.58:5060;branch=z9hG4bK-6224e334;rport. From: sip:151355001@Kamailio_IP;tag=32ffee79a7f15755i0. To: "0473236354" sip:0473236354@Asterisk_IP;tag=as27afe4d7. Remote-Party-ID: 28945557 <sip:151355001@Kamailio_IP
;screen=yes;party=called.
Call-ID: 71d222ac7b77f421693e27aa4c921e12@Asterisk_IP. CSeq: 101 INVITE. Max-Forwards: 70. Route: sip:Kamailio_IP;lr=on. Contact: 28945557 sip:151355001@14.14.14.58:5060. Expires: 30. User-Agent: Linksys/SPA2102-3.3.6. Content-Length: 261. Content-Type: application/sdp. . v=0. o=- 28218 28218 IN IP4 14.14.14.58. s=-. c=IN IP4 14.14.14.58. t=0 0. m=image 16418 udptl t38. a=T38FaxVersion:0. a=T38MaxBitRate:14400. a=T38FaxRateManagement:transferredTCF. a=T38FaxMaxBuffer:200. a=T38FaxMaxDatagram:200. a=T38FaxUdpEC:t38UDPRedundancy.
U +0.251115 79.132.227.35:45068 -> Kamailio_IP:5060 ACK sip:0473236354@Asterisk_IP SIP/2.0. Via: SIP/2.0/UDP 14.14.14.58:5060;branch=z9hG4bK-5e48f760;rport. From: sip:151355001@Kamailio_IP;tag=32ffee79a7f15755i0. To: "0473236354" sip:0473236354@Asterisk_IP;tag=as27afe4d7. Call-ID: 71d222ac7b77f421693e27aa4c921e12@Asterisk_IP. CSeq: 101 ACK. Max-Forwards: 70. Route: sip:Kamailio_IP;lr=on. Contact: 28945557 sip:151355001@14.14.14.58:5060. User-Agent: Linksys/SPA2102-3.3.6. Content-Length: 0. .
U +0.240288 79.132.227.35:45068 -> Kamailio_IP:5060 ACK sip:0473236354@Asterisk_IP SIP/2.0. Via: SIP/2.0/UDP 14.14.14.58:5060;branch=z9hG4bK-5e48f760;rport. From: sip:151355001@Kamailio_IP;tag=32ffee79a7f15755i0. To: "0473236354" sip:0473236354@Asterisk_IP;tag=as27afe4d7. Call-ID: 71d222ac7b77f421693e27aa4c921e12@Asterisk_IP. CSeq: 101 ACK. Max-Forwards: 70. Route: sip:Kamailio_IP;lr=on. Contact: 28945557 sip:151355001@14.14.14.58:5060. User-Agent: Linksys/SPA2102-3.3.6. Content-Length: 0. .
U +0.439631 79.132.227.35:45068 -> Kamailio_IP:5060 ACK sip:0473236354@Asterisk_IP SIP/2.0. Via: SIP/2.0/UDP 14.14.14.58:5060;branch=z9hG4bK-5e48f760;rport. From: sip:151355001@Kamailio_IP;tag=32ffee79a7f15755i0. To: "0473236354" sip:0473236354@Asterisk_IP;tag=as27afe4d7. Call-ID: 71d222ac7b77f421693e27aa4c921e12@Asterisk_IP. CSeq: 101 ACK. Max-Forwards: 70. Route: sip:Kamailio_IP;lr=on. Contact: 28945557 sip:151355001@14.14.14.58:5060. User-Agent: Linksys/SPA2102-3.3.6. Content-Length: 0. .
U +0.781811 79.132.227.35:45068 -> Kamailio_IP:5060 ACK sip:0473236354@Asterisk_IP SIP/2.0. Via: SIP/2.0/UDP 14.14.14.58:5060;branch=z9hG4bK-5e48f760;rport. From: sip:151355001@Kamailio_IP;tag=32ffee79a7f15755i0. To: "0473236354" sip:0473236354@Asterisk_IP;tag=as27afe4d7. Call-ID: 71d222ac7b77f421693e27aa4c921e12@Asterisk_IP. CSeq: 101 ACK. Max-Forwards: 70. Route: sip:Kamailio_IP;lr=on. Contact: 28945557 sip:151355001@14.14.14.58:5060. User-Agent: Linksys/SPA2102-3.3.6. Content-Length: 0. .
U +2.022102 79.132.227.35:45068 -> Kamailio_IP:5060 ACK sip:0473236354@Asterisk_IP SIP/2.0. Via: SIP/2.0/UDP 14.14.14.58:5060;branch=z9hG4bK-5e48f760;rport. From: sip:151355001@Kamailio_IP;tag=32ffee79a7f15755i0. To: "0473236354" sip:0473236354@Asterisk_IP;tag=as27afe4d7. Call-ID: 71d222ac7b77f421693e27aa4c921e12@Asterisk_IP. CSeq: 101 ACK. Max-Forwards: 70. Route: sip:Kamailio_IP;lr=on. Contact: 28945557 sip:151355001@14.14.14.58:5060. User-Agent: Linksys/SPA2102-3.3.6. Content-Length: 0. .
U +4.164228 79.132.227.35:45068 -> Kamailio_IP:5060 ACK sip:0473236354@Asterisk_IP SIP/2.0. Via: SIP/2.0/UDP 14.14.14.58:5060;branch=z9hG4bK-5e48f760;rport. From: sip:151355001@Kamailio_IP;tag=32ffee79a7f15755i0. To: "0473236354" sip:0473236354@Asterisk_IP;tag=as27afe4d7. Call-ID: 71d222ac7b77f421693e27aa4c921e12@Asterisk_IP. CSeq: 101 ACK. Max-Forwards: 70. Route: sip:Kamailio_IP;lr=on. Contact: 28945557 sip:151355001@14.14.14.58:5060. User-Agent: Linksys/SPA2102-3.3.6. Content-Length: 0. .
U +4.128904 79.132.227.35:45068 -> Kamailio_IP:5060 ACK sip:0473236354@Asterisk_IP SIP/2.0. Via: SIP/2.0/UDP 14.14.14.58:5060;branch=z9hG4bK-5e48f760;rport. From: sip:151355001@Kamailio_IP;tag=32ffee79a7f15755i0. To: "0473236354" sip:0473236354@Asterisk_IP;tag=as27afe4d7. Call-ID: 71d222ac7b77f421693e27aa4c921e12@Asterisk_IP. CSeq: 101 ACK. Max-Forwards: 70. Route: sip:Kamailio_IP;lr=on. Contact: 28945557 sip:151355001@14.14.14.58:5060. User-Agent: Linksys/SPA2102-3.3.6. Content-Length: 0. .
U +4.093784 79.132.227.35:45068 -> Kamailio_IP:5060 ACK sip:0473236354@Asterisk_IP SIP/2.0. Via: SIP/2.0/UDP 14.14.14.58:5060;branch=z9hG4bK-5e48f760;rport. From: sip:151355001@Kamailio_IP;tag=32ffee79a7f15755i0. To: "0473236354" sip:0473236354@Asterisk_IP;tag=as27afe4d7. Call-ID: 71d222ac7b77f421693e27aa4c921e12@Asterisk_IP. CSeq: 101 ACK. Max-Forwards: 70. Route: sip:Kamailio_IP;lr=on. Contact: 28945557 sip:151355001@14.14.14.58:5060. User-Agent: Linksys/SPA2102-3.3.6. Content-Length: 0. .
On Fri, Mar 13, 2009 at 4:28 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
2009/3/13 michel freiha michofr@gmail.com:
You mean config problem outside Kamailio?
No, in kamailio config file. Check with ngrep how the re-INVITE is routed and also its 200 and ACK.
-- Iñaki Baz Castillo ibc@aliax.net
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
El Viernes, 13 de Marzo de 2009, michel freiha escribió:
U +4.093784 79.132.227.35:45068 -> Kamailio_IP:5060 ACK sip:0473236354@Asterisk_IP SIP/2.0. Via: SIP/2.0/UDP 14.14.14.58:5060;branch=z9hG4bK-5e48f760;rport. From: sip:151355001@Kamailio_IP;tag=32ffee79a7f15755i0. To: "0473236354" sip:0473236354@Asterisk_IP;tag=as27afe4d7. Call-ID: 71d222ac7b77f421693e27aa4c921e12@Asterisk_IP. CSeq: 101 ACK. Max-Forwards: 70. Route: sip:Kamailio_IP;lr=on. Contact: 28945557 sip:151355001@14.14.14.58:5060. User-Agent: Linksys/SPA2102-3.3.6. Content-Length: 0.
This ACK should arrive to Asterisk, does it? If not, then you have a problem with your in-dialog routing for ACK-200.
Dear Inaki,
You are right...Just let me know what could be done in order to fix this issue...I can provide you all info needed in order to fix
Regards
On Sat, Mar 14, 2009 at 7:40 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
El Viernes, 13 de Marzo de 2009, michel freiha escribió:
U +4.093784 79.132.227.35:45068 -> Kamailio_IP:5060 ACK sip:0473236354@Asterisk_IP SIP/2.0. Via: SIP/2.0/UDP 14.14.14.58:5060;branch=z9hG4bK-5e48f760;rport. From: sip:151355001@Kamailio_IP;tag=32ffee79a7f15755i0. To: "0473236354" sip:0473236354@Asterisk_IP;tag=as27afe4d7. Call-ID: 71d222ac7b77f421693e27aa4c921e12@Asterisk_IP. CSeq: 101 ACK. Max-Forwards: 70. Route: sip:Kamailio_IP;lr=on. Contact: 28945557 sip:151355001@14.14.14.58:5060. User-Agent: Linksys/SPA2102-3.3.6. Content-Length: 0.
This ACK should arrive to Asterisk, does it? If not, then you have a problem with your in-dialog routing for ACK-200.
-- Iñaki Baz Castillo
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
El Domingo, 15 de Marzo de 2009, michel freiha escribió:
Dear Inaki,
You are right...Just let me know what could be done in order to fix this issue...I can provide you all info needed in order to fix
Fix your in-dialog section. The default kamailio.cfg already does it well.
Dear Inaki,
This is my in dialog:
if(does_uri_exist()){ # local uri does exist, is probably a user. # lookup location if(lookup("location")){ t_on_failure("1"); t_on_reply("1"); force_rtp_proxy(); t_relay(); }
Here I defined the loose route to reply on the REINVITE message:
f(loose_route()){ t_on_reply("7"); if (is_method("INVITE")) { t_on_failure("1"); force_rtp_proxy(); t_relay(); exit(); } }
and the Onreply(7) is: onreply_route[7] {
if (status=~ "200"){ t_on_failure("1"); force_rtp_proxy(); } exit; }
Please help me in this...I tried everything with No luck...I just have the 200OK issue that is not sent back to Asterisk and everything will work fine
Regards
On Sun, Mar 15, 2009 at 7:12 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
El Domingo, 15 de Marzo de 2009, michel freiha escribió:
Dear Inaki,
You are right...Just let me know what could be done in order to fix this issue...I can provide you all info needed in order to fix
Fix your in-dialog section. The default kamailio.cfg already does it well.
-- Iñaki Baz Castillo
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
El Domingo, 15 de Marzo de 2009, michel freiha escribió:
Here I defined the loose route to reply on the REINVITE message:
if(loose_route()){ t_on_reply("7"); if (is_method("INVITE")) { t_on_failure("1"); force_rtp_proxy(); t_relay(); exit(); } }
This is wrong. I already suggested you to compare your loose_route section with that in the Kamailio default config file, but it seems you haven't done it.
I hope you know that ACK after INVITE-200 is a *new* transaction, and an in-dialog request (so it goes into loose_route section). Question: is your loose_route section allowing this ACK to be routed? I just see the t_relay for INVITE, what about other requests as INFO, PRACK, NOTIFY... *ACK* ?
Dear Inaki,
Thanks for the help..really appreciated...I guess I should add a ACK check to loose route because as you said it's a new in dialog transaction...Please chek below:
if ( is_method("ACK") ) { if ( t_check_trans() ) {
t_relay(); exit; } }
Regarding INFO and NOTIFY...I'll do that later after ACK is OK
What I did above is OK?
Regards
On Sun, Mar 15, 2009 at 9:05 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
El Domingo, 15 de Marzo de 2009, michel freiha escribió:
Here I defined the loose route to reply on the REINVITE message:
if(loose_route()){ t_on_reply("7"); if (is_method("INVITE")) { t_on_failure("1"); force_rtp_proxy(); t_relay(); exit(); } }
This is wrong. I already suggested you to compare your loose_route section with that in the Kamailio default config file, but it seems you haven't done it.
I hope you know that ACK after INVITE-200 is a *new* transaction, and an in-dialog request (so it goes into loose_route section). Question: is your loose_route section allowing this ACK to be routed? I just see the t_relay for INVITE, what about other requests as INFO, PRACK, NOTIFY... *ACK* ?
-- Iñaki Baz Castillo
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
El Domingo, 15 de Marzo de 2009, michel freiha escribió:
Dear Inaki,
Thanks for the help..really appreciated...I guess I should add a ACK check to loose route because as you said it's a new in dialog transaction...Please chek below:
if ( is_method("ACK") ) { if ( t_check_trans() ) {
t_relay(); exit;} }
Regarding INFO and NOTIFY...I'll do that later after ACK is OK
What I did above is OK?
Check the default config file of Kamailio:
http://openser.svn.sourceforge.net/viewvc/openser/branches/1.5/etc/kamailio....
Basically copy&paste it and just add "t_on_failure("1")" and "force_rtp_proxy()" if the method is INVITE.
-
Henning Westerholt -
hh174 -
Iñaki Baz Castillo -
michel freiha -
olivier taylor