12 Mar
2009
12 Mar
'09
9:52 p.m.
Dear All,
Does anyone has an experience with Incoming FAX T38 using a PUBLIC IP on
endpoint?
Regards
10:33 p.m.
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(a)sunforyou.be>wrote;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.
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-project.org/cgi-bin/mailman/listinfo/users
11:12 p.m.
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(a)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(a)sunforyou.be>wrote;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.
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-project.org/cgi-bin/mailman/listinfo/users
13 Mar
13 Mar
10:14 a.m.
2009/3/12 michel freiha <michofr(a)gmail.com>om>:
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
10:33 a.m.
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(a)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(a)sunforyou.be>wrote;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.
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-project.org/cgi-bin/mailman/listinfo/users
11:47 a.m.
2009/3/13 michel freiha <michofr(a)gmail.com>om>:
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
11:37 a.m.
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
12:08 p.m.
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(a)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
12:15 p.m.
2009/3/13 michel freiha <michofr(a)gmail.com>om>:
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(a)aliax.net>
12:24 p.m.
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(a)aliax.net> wrote:
2009/3/13 michel freiha <michofr(a)gmail.com>om>:
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(a)aliax.net>
12:35 p.m.
2009/3/13 michel freiha <michofr(a)gmail.com>om>:
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(a)aliax.net>
2:50 p.m.
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(a)aliax.net> wrote:
2009/3/13 michel freiha <michofr(a)gmail.com>om>:
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(a)aliax.net>
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
3:09 p.m.
2009/3/13 michel freiha <michofr(a)gmail.com>om>:
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(a)aliax.net>
3:13 p.m.
You mean config problem outside Kamailio?
Regards
On Fri, Mar 13, 2009 at 4:09 PM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
2009/3/13 michel freiha <michofr(a)gmail.com>om>:
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(a)aliax.net>
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
3:18 p.m.
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(a)gmail.com> wrote:
You mean config problem outside Kamailio?
Regards
On Fri, Mar 13, 2009 at 4:09 PM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
2009/3/13 michel freiha
<michofr(a)gmail.com>om>:
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(a)aliax.net>
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
3:29 p.m.
2009/3/13 michel freiha <michofr(a)gmail.com>om>:
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4:40 p.m.
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(a)aliax.net> wrote:
2009/3/13 michel freiha <michofr(a)gmail.com>om>:
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(a)aliax.net>
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
14 Mar
14 Mar
6:40 p.m.
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
15 Mar
15 Mar
4:59 p.m.
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(a)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(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
6:12 p.m.
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
7:16 p.m.
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(a)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(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
8:05 p.m.
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
8:57 p.m.
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(a)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(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
9:08 p.m.
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.
--
Iñaki Baz Castillo
5528
days inactive
5531
days old
26 comments
5 participants
participants (5)
-
Henning Westerholt -
hh174 -
Iñaki Baz Castillo -
michel freiha -
olivier taylor