Re: [Kamailio-Users] Need to handle an upstream carrier error - Duplicate INVITE Messages
22 Feb
2009
22 Feb
'09
4:24 a.m.
Hello,
I have a carrier who provides PSTN gateway services. They have
multiple redundant sip gateway devices in their network. The problem
occurs when one of their devices starts to have issues. I will
receive an INVITE request from both gateways with the same call-id.
The problem is that my Kamailio system doesn't detect that I already
set a call up for the INVITE once, and forwards the request to another
server in the dispatcher list. What I end up with is a call on two
asterisk servers, but only one has the actual RTP stream. The BYE
request gets routed to the wrong server, and everything just gets
screwy. If anyone could provide any hint on how I might be able to deal with
this scenario, I would really appreciate it.
I have attached my current config file, and the following is a link to
a google spreadsheet which
shows the SIP trace.
http://spreadsheets.google.com/ccc?key=pU5i2J6Ck3b519-_M6Et3cw
I have masked my IP addresses for my own sanity.
XX.XX.XX.179 - Kamailio SIP Gateway
XX.XX.XX.189 - Asterisk1
XX.XX.XX.186 - Asterisk2
Thanks!
Geoff
23 Feb
23 Feb
3:14 p.m.
New subject: [Kamailio-Users] Need to handle an upstream carrier error - Duplicate INVITE Messages
Hello,
please do not cross-post on many mailing lists. Will create confusion
about available solutions.
Theoretically, this is valid in SIP (e.g., 2 invites with same call-id)
-- it is same scenario as parallel forking in upstream.
However, if you know that this shouldn't happen, you can try to fix it
from config.
Fist is to identify why the BYE is routed to the wrong server. It should
follow the Route set and contact address. Can you provide the pcap file
of such call?
As solution to deny new invites with same call id is to use the htable
module. Set a key there based on call id (eventually plus from user,
from tag, etc.) and check it before processing the invite, if there is
one, drop it.
You just set key auto-expire for 30-60sec so it gets automatically deleted.
Note that htable is in devel version (upcoming 1.5.0), but should work
out of the box with 1.4:
http://kamailio.org/docs/modules/1.5.x/htable.html
Cheers,
Daniel
On 02/22/2009 03:24 AM, Geoffrey Mina wrote:
Hello,
I have a carrier who provides PSTN gateway services. They have
multiple redundant sip gateway devices in their network. The problem
occurs when one of their devices starts to have issues. I will
receive an INVITE request from both gateways with the same call-id.
The problem is that my Kamailio system doesn't detect that I already
set a call up for the INVITE once, and forwards the request to another
server in the dispatcher list. What I end up with is a call on two
asterisk servers, but only one has the actual RTP stream. The BYE
request gets routed to the wrong server, and everything just gets
screwy. If anyone could provide any hint on how I might be able to deal with
this scenario, I would really appreciate it.
I have attached my current config file, and the following is a link to
a google spreadsheet which
shows the SIP trace.
http://spreadsheets.google.com/ccc?key=pU5i2J6Ck3b519-_M6Et3cw
I have masked my IP addresses for my own sanity.
XX.XX.XX.179 - Kamailio SIP Gateway
XX.XX.XX.189 - Asterisk1
XX.XX.XX.186 - Asterisk2
Thanks!
Geoff
------------------------------------------------------------------------
_______________________________________________
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
--
Daniel-Constantin Mierla
http://www.asipto.com
4:50 p.m.
New subject: [Kamailio-Users] Need to handle an upstream carrier error - Duplicate INVITE Messages
Sorry about the cross post. I wasn't sure how many people were on
both the OpenSIPs and Kamailio mailing lists... and since this is a
'core' issue, I figured it would be good to get input from the most
people. In the future I will only post to one.
I will go down the path of the htable, what kind of performance/memory
hit am I going to take?
This system has a lot of memory available to it, how would I increase
memory appropriately to ensure the htable had enough to live happily?
thanks,
Geoff
On Mon, Feb 23, 2009 at 7:14 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
Hello,
please do not cross-post on many mailing lists. Will create confusion about
available solutions.
Theoretically, this is valid in SIP (e.g., 2 invites with same call-id) --
it is same scenario as parallel forking in upstream.
However, if you know that this shouldn't happen, you can try to fix it from
config.
Fist is to identify why the BYE is routed to the wrong server. It should
follow the Route set and contact address. Can you provide the pcap file of
such call?
As solution to deny new invites with same call id is to use the htable
module. Set a key there based on call id (eventually plus from user, from
tag, etc.) and check it before processing the invite, if there is one, drop
it.
You just set key auto-expire for 30-60sec so it gets automatically deleted.
Note that htable is in devel version (upcoming 1.5.0), but should work out
of the box with 1.4:
http://kamailio.org/docs/modules/1.5.x/htable.html
Cheers,
Daniel
On 02/22/2009 03:24 AM, Geoffrey Mina wrote:
Hello,
I have a carrier who provides PSTN gateway services. They have
multiple redundant sip gateway devices in their network. The problem
occurs when one of their devices starts to have issues. I will
receive an INVITE request from both gateways with the same call-id.
The problem is that my Kamailio system doesn't detect that I already
set a call up for the INVITE once, and forwards the request to another
server in the dispatcher list. What I end up with is a call on two
asterisk servers, but only one has the actual RTP stream. The BYE
request gets routed to the wrong server, and everything just gets
screwy. If anyone could provide any hint on how I might be able to deal
with
this scenario, I would really appreciate it.
I have attached my current config file, and the following is a link to
a google spreadsheet which
shows the SIP trace.
http://spreadsheets.google.com/ccc?key=pU5i2J6Ck3b519-_M6Et3cw
I have masked my IP addresses for my own sanity.
XX.XX.XX.179 - Kamailio SIP Gateway
XX.XX.XX.189 - Asterisk1
XX.XX.XX.186 - Asterisk2
Thanks!
Geoff
------------------------------------------------------------------------
_______________________________________________
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
--
Daniel-Constantin Mierla
http://www.asipto.com
5:13 p.m.
New subject: [Kamailio-Users] Need to handle an upstream carrier error - Duplicate INVITE Messages
On 02/23/2009 03:50 PM, Geoffrey Mina wrote:
Sorry about the cross post. I wasn't sure how
many people were on
both the OpenSIPs and Kamailio mailing lists... and since this is a
'core' issue, I figured it would be good to get input from the most
people.
ok, but separately is better, as solutions in one side do not apply
always in the other side and will create confusion. Kamailio works on
the same mailing lists as openser, so we have quite large and mature
community here, over 1000 subscribed people to this mailing lists only.
In the future I will only post to one.
I will go down the path of the htable, what kind of performance/memory
hit am I going to take?
performance should not be an issue, as everything is in memory, just set
the size of the hash table to a reasonable number. You can count the
memory via the calls setups per second rate. For example, if you have
100 calls setups per second, that mean 100 INVITEs per second.
So if you let the key in hash table for 30 second, that means you need
memory for 3000 item in hash table. One entry has the size of the key
name and value plus a 40 bytes (or so) overhead. If you take an average
of 32 per call id and you store an integer, that means about 80bytes per
key (rounded up). So, you would need 240kB for it, which is not such big
and can live with default share memory size.
Anyhow, if you need more share memory, increase it via -m command line
parameter. Default is 32MB.
This system has a lot of memory available to it, how
would I increase
memory appropriately to ensure the htable had enough to live happily?
If you have enough, then is better to start with 128 MB of shared
memoru: -m 128
Cheers,
Daniel
thanks,
Geoff
On Mon, Feb 23, 2009 at 7:14 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com
Hello,
please do not cross-post on many mailing lists. Will create confusion about
available solutions.
Theoretically, this is valid in SIP (e.g., 2 invites with same call-id) --
it is same scenario as parallel forking in upstream.
However, if you know that this shouldn't happen, you can try to fix it from
config.
Fist is to identify why the BYE is routed to the wrong server. It should
follow the Route set and contact address. Can you provide the pcap file of
such call?
As solution to deny new invites with same call id is to use the htable
module. Set a key there based on call id (eventually plus from user, from
tag, etc.) and check it before processing the invite, if there is one, drop
it.
You just set key auto-expire for 30-60sec so it gets automatically deleted.
Note that htable is in devel version (upcoming 1.5.0), but should work out
of the box with 1.4:
http://kamailio.org/docs/modules/1.5.x/htable.html
Cheers,
Daniel
On 02/22/2009 03:24 AM, Geoffrey Mina wrote:
_______________________________________________
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
Hello,
I have a carrier who provides PSTN gateway services. They have
multiple redundant sip gateway devices in their network. The problem
occurs when one of their devices starts to have issues. I will
receive an INVITE request from both gateways with the same call-id.
The problem is that my Kamailio system doesn't detect that I already
set a call up for the INVITE once, and forwards the request to another
server in the dispatcher list. What I end up with is a call on two
asterisk servers, but only one has the actual RTP stream. The BYE
request gets routed to the wrong server, and everything just gets
screwy. If anyone could provide any hint on how I might be able to deal
with
this scenario, I would really appreciate it.
I have attached my current config file, and the following is a link to
a google spreadsheet which
shows the SIP trace.
http://spreadsheets.google.com/ccc?key=pU5i2J6Ck3b519-_M6Et3cw
I have masked my IP addresses for my own sanity.
XX.XX.XX.179 - Kamailio SIP Gateway
XX.XX.XX.189 - Asterisk1
XX.XX.XX.186 - Asterisk2
Thanks!
Geoff
------------------------------------------------------------------------
_______________________________________________
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
--
Daniel-Constantin Mierla
http://www.asipto.com
24 Feb
24 Feb
5:17 a.m.
New subject: [Kamailio-Users] Need to handle an upstream carrier error - Duplicate INVITE Messages
Daniel,
Thanks for the info. I am already starting my server with -m 2048, so
I should be more than fine on the memory side :) My Kamailio
deployment is a 64bit server with 8G of RAM.
How does this look for an implementation of this check? I based it
off the following snippet of the RFC
8.2.2.2 Merged Requests
If the request has no tag in the To header field, the UAS core MUST
check the request against ongoing transactions. If the From tag,
Call-ID, and CSeq exactly match those associated with an ongoing
transaction, but the request does not match that transaction (based
on the matching rules in Section 17.2.3), the UAS core SHOULD
generate a 482 (Loop Detected) response and pass it to the server
transaction.
The same request has arrived at the UAS more than once, following
different paths, most likely due to forking. The UAS processes
the first such request received and responds with a 482 (Loop
Detected) to the rest of them.
loadmodule("ht.so")
modparam("htable","htable","loop_check=>size=6000;autoexpire=30")
##
## Check to make sure we don't already have an active
## transaction for this call-id, c-seq, and from-tag
## RFC3261 - 8.2.2.2
##
if($sht(loop_check=>$ci::$cs::$ft) == null){
$sht(loop_check=>$ci::$cs::$ft) = 1
}else{
sl_reply_error("482","Loop Detected - Duplicate Session
Presentation");
exit;
}
Thanks for the assistance!!
Geoff
On Mon, Feb 23, 2009 at 9:13 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
On 02/23/2009 03:50 PM, Geoffrey Mina wrote:
Sorry about the cross post. I wasn't sure how many people were on
both the OpenSIPs and Kamailio mailing lists... and since this is a
'core' issue, I figured it would be good to get input from the most
people.
ok, but separately is better, as solutions in one side do not apply always
in the other side and will create confusion. Kamailio works on the same
mailing lists as openser, so we have quite large and mature community here,
over 1000 subscribed people to this mailing lists only.
In the future I will only post to one.
I will go down the path of the htable, what kind of performance/memory
hit am I going to take?
performance should not be an issue, as everything is in memory, just set the
size of the hash table to a reasonable number. You can count the memory via
the calls setups per second rate. For example, if you have 100 calls setups
per second, that mean 100 INVITEs per second.
So if you let the key in hash table for 30 second, that means you need
memory for 3000 item in hash table. One entry has the size of the key name
and value plus a 40 bytes (or so) overhead. If you take an average of 32 per
call id and you store an integer, that means about 80bytes per key (rounded
up). So, you would need 240kB for it, which is not such big and can live
with default share memory size.
Anyhow, if you need more share memory, increase it via -m command line
parameter. Default is 32MB.
This system has a lot of memory available to it, how would I increase
memory appropriately to ensure the htable had enough to live happily?
If you have enough, then is better to start with 128 MB of shared memoru: -m
128
Cheers,
Daniel
thanks,
Geoff
On Mon, Feb 23, 2009 at 7:14 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com
Hello,
please do not cross-post on many mailing lists. Will create confusion
about
available solutions.
Theoretically, this is valid in SIP (e.g., 2 invites with same call-id)
--
it is same scenario as parallel forking in upstream.
However, if you know that this shouldn't happen, you can try to fix it
from
config.
Fist is to identify why the BYE is routed to the wrong server. It should
follow the Route set and contact address. Can you provide the pcap file
of
such call?
As solution to deny new invites with same call id is to use the htable
module. Set a key there based on call id (eventually plus from user, from
tag, etc.) and check it before processing the invite, if there is one,
drop
it.
You just set key auto-expire for 30-60sec so it gets automatically
deleted.
Note that htable is in devel version (upcoming 1.5.0), but should work
out
of the box with 1.4:
http://kamailio.org/docs/modules/1.5.x/htable.html
Cheers,
Daniel
On 02/22/2009 03:24 AM, Geoffrey Mina wrote:
_______________________________________________
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
Hello,
I have a carrier who provides PSTN gateway services. They have
multiple redundant sip gateway devices in their network. The problem
occurs when one of their devices starts to have issues. I will
receive an INVITE request from both gateways with the same call-id.
The problem is that my Kamailio system doesn't detect that I already
set a call up for the INVITE once, and forwards the request to another
server in the dispatcher list. What I end up with is a call on two
asterisk servers, but only one has the actual RTP stream. The BYE
request gets routed to the wrong server, and everything just gets
screwy. If anyone could provide any hint on how I might be able to deal
with
this scenario, I would really appreciate it.
I have attached my current config file, and the following is a link to
a google spreadsheet which
shows the SIP trace.
http://spreadsheets.google.com/ccc?key=pU5i2J6Ck3b519-_M6Et3cw
I have masked my IP addresses for my own sanity.
XX.XX.XX.179 - Kamailio SIP Gateway
XX.XX.XX.189 - Asterisk1
XX.XX.XX.186 - Asterisk2
Thanks!
Geoff
------------------------------------------------------------------------
_______________________________________________
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
--
Daniel-Constantin Mierla
http://www.asipto.com
25 Feb
25 Feb
1:53 p.m.
New subject: [Kamailio-Users] Need to handle an upstream carrier error - Duplicate INVITE Messages
Hello,
On 02/24/2009 04:17 AM, Geoffrey Mina wrote:
Daniel,
Thanks for the info. I am already starting my server with -m 2048, so
I should be more than fine on the memory side :) My Kamailio
deployment is a 64bit server with 8G of RAM.
How does this look for an implementation of this check? I based it
off the following snippet of the RFC
8.2.2.2 Merged Requests
If the request has no tag in the To header field, the UAS core MUST
check the request against ongoing transactions. If the From tag,
Call-ID, and CSeq exactly match those associated with an ongoing
transaction, but the request does not match that transaction (based
on the matching rules in Section 17.2.3), the UAS core SHOULD
generate a 482 (Loop Detected) response and pass it to the server
transaction.
The same request has arrived at the UAS more than once, following
different paths, most likely due to forking. The UAS processes
the first such request received and responds with a 482 (Loop
Detected) to the rest of them.
loadmodule("ht.so")
modparam("htable","htable","loop_check=>size=6000;autoexpire=30")
the size is far too much. Remember that the number entries in the hash
table is "2 power size". If size=10, means the hash table has 1024
entries. Anyhow, there is a check and if the size is greater than 14, it
is automatically lowered to 14.
##
## Check to make sure we don't already have an active
## transaction for this call-id, c-seq, and from-tag
## RFC3261 - 8.2.2.2
##
if($sht(loop_check=>$ci::$cs::$ft) == null){
$sht(loop_check=>$ci::$cs::$ft) = 1
}else{
sl_reply_error("482","Loop Detected - Duplicate Session
Presentation");
exit;
}
The check looks ok.
Cheers,
Daniel
Thanks for the assistance!!
Geoff
On Mon, Feb 23, 2009 at 9:13 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com
On 02/23/2009 03:50 PM, Geoffrey Mina wrote:
_______________________________________________
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
Sorry about the cross post. I wasn't sure
how many people were on
both the OpenSIPs and Kamailio mailing lists... and since this is a
'core' issue, I figured it would be good to get input from the most
people.
ok, but separately is better, as solutions in one side do not apply always
in the other side and will create confusion. Kamailio works on the same
mailing lists as openser, so we have quite large and mature community here,
over 1000 subscribed people to this mailing lists only.
In the future I will only post to one.
I will go down the path of the htable, what kind of performance/memory
hit am I going to take?
performance should not be an issue, as everything is in memory, just set
the
size of the hash table to a reasonable number. You can count the memory via
the calls setups per second rate. For example, if you have 100 calls setups
per second, that mean 100 INVITEs per second.
So if you let the key in hash table for 30 second, that means you need
memory for 3000 item in hash table. One entry has the size of the key name
and value plus a 40 bytes (or so) overhead. If you take an average of 32 per
call id and you store an integer, that means about 80bytes per key (rounded
up). So, you would need 240kB for it, which is not such big and can live
with default share memory size.
Anyhow, if you need more share memory, increase it via -m command line
parameter. Default is 32MB.
This system has a lot of memory available to it,
how would I increase
memory appropriately to ensure the htable had enough to live happily?
If you have enough, then is better to start with 128 MB of shared memoru:
-m
128
Cheers,
Daniel
thanks,
Geoff
On Mon, Feb 23, 2009 at 7:14 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com
Hello,
please do not cross-post on many mailing lists. Will create confusion
about
available solutions.
Theoretically, this is valid in SIP (e.g., 2 invites with same call-id)
--
it is same scenario as parallel forking in upstream.
However, if you know that this shouldn't happen, you can try to fix it
from
config.
Fist is to identify why the BYE is routed to the wrong server. It should
follow the Route set and contact address. Can you provide the pcap file
of
such call?
As solution to deny new invites with same call id is to use the htable
module. Set a key there based on call id (eventually plus from user, from
tag, etc.) and check it before processing the invite, if there is one,
drop
it.
You just set key auto-expire for 30-60sec so it gets automatically
deleted.
Note that htable is in devel version (upcoming 1.5.0), but should work
out
of the box with 1.4:
http://kamailio.org/docs/modules/1.5.x/htable.html
Cheers,
Daniel
On 02/22/2009 03:24 AM, Geoffrey Mina wrote:
> Hello,
> I have a carrier who provides PSTN gateway services. They have
> multiple redundant sip gateway devices in their network. The problem
> occurs when one of their devices starts to have issues. I will
> receive an INVITE request from both gateways with the same call-id.
> The problem is that my Kamailio system doesn't detect that I already
> set a call up for the INVITE once, and forwards the request to another
> server in the dispatcher list. What I end up with is a call on two
> asterisk servers, but only one has the actual RTP stream. The BYE
> request gets routed to the wrong server, and everything just gets
> screwy. If anyone could provide any hint on how I might be able to deal
> with
> this scenario, I would really appreciate it.
>
> I have attached my current config file, and the following is a link to
> a google spreadsheet which
> shows the SIP trace.
>
> http://spreadsheets.google.com/ccc?key=pU5i2J6Ck3b519-_M6Et3cw
>
> I have masked my IP addresses for my own sanity.
>
> XX.XX.XX.179 - Kamailio SIP Gateway
> XX.XX.XX.189 - Asterisk1
> XX.XX.XX.186 - Asterisk2
>
> Thanks!
> Geoff
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
>
>
--
Daniel-Constantin Mierla
http://www.asipto.com
_______________________________________________
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
5735
days inactive
5738
days old
5 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Geoffrey Mina