[Kamailio-Users] Need to handle an upstream carrier error - Duplicate INVITE Messages
Daniel-Constantin Mierla
miconda at gmail.com
Wed Feb 25 11:53:20 CET 2009
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 at 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 at 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 at 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 at 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 at 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
More information about the sr-users
mailing list