[SR-Users] sipp and stateful transaction problem

[Daniel-Constantin Mierla]

On 5/25/10 10:49 PM, JR Richardson wrote:
> On Tue, May 25, 2010 at 11:10 AM, Daniel-Constantin Mierla
> <miconda at gmail.com>  wrote:
>    
>> Hello,
>>
>> On 5/22/10 2:22 AM, JR Richardson wrote:
>>      
>>> On Fri, May 21, 2010 at 4:46 PM, Daniel-Constantin Mierla
>>> <miconda at gmail.com>    wrote:
>>>
>>>        
>>>> Hello,
>>>>
>>>> On 5/21/10 10:47 PM, JR Richardson wrote:
>>>>
>>>>          
>>>>> Hi All,
>>>>>
>>>>> I'm doing some testing with kamailio 1.5:
>>>>>
>>>>> kamailio1:/etc/kamailio# kamailio -V
>>>>> version: kamailio 1.5.4-notls (i386/linux)
>>>>> flags: STATISTICS, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST,
>>>>> SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
>>>>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
>>>>> MAX_URI_SIZE 1024, BUF_SIZE 65535, PKG_SIZE 4194304
>>>>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>>>>> svnrevision: 2:6005M
>>>>> @(#) $Id: main.c 5608 2009-02-13 16:48:17Z henningw $
>>>>> main.c compiled on 10:14:11 May 18 2010 with gcc 4.3.2
>>>>>
>>>>> Using dispatcher module trying to load balance SIP calls across some
>>>>> Asterisk servers.  I have it working fine when I test in this
>>>>> scenario:
>>>>>
>>>>> sip phone dial out><asterisk><kamailio><round robin to several asterisk
>>>>> servers
>>>>>
>>>>> This works stateful and stateless, handles everything gracefully.
>>>>>
>>>>> This scenario is giving me fits:
>>>>>
>>>>> sipp dial out><kamailio><round robin to several asterisk servers
>>>>>
>>>>> I get retransmits on every call back to sipp with errors like
>>>>> "Discarding message which can't be mapped to a known SIPp call" and
>>>>> "SIP/2.0 481 Call leg/transaction does not exist"
>>>>>
>>>>> This happens with kamailio setup stateful or stateless.  I'm wondering
>>>>> if sipp is the problem or just doesn't play well with kamailio?
>>>>>
>>>>> I've kept the config as simple as possible for testing, it is listed
>>>>> here http://pastebin.com/BZ8hJvJv
>>>>>
>>>>> Here is my sipp usage:
>>>>>
>>>>> sipp -sn uac 10.10.12.53 -i 10.10.14.97 -s 55 -d 7000 -l 10 -r 1
>>>>> -trace_err
>>>>>
>>>>> Any insight would be appriciated.
>>>>>
>>>>>
>>>>>
>>>>>            
>>>> the problem is in your sipp scenario. The uac calls do not map to uas.
>>>> kamailio does not reply 481,  check the uas scenario, that is the one
>>>> that
>>>> sends back the 481.
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>> --
>>>> Daniel-Constantin Mierla
>>>> Kamailio (OpenSER) Advanced Training
>>>> Miami, Fl, USA - June 21-23, 2010
>>>> http://www.asipto.com/index.php/kamailio-advanced-training/
>>>>
>>>>
>>>>
>>>>          
>>> Thanks Daniel, I reveiwed the sipp docs, '-sn uas' just sits there as
>>> a responder, it will not initiate calls to kamailio.  I don't
>>> understand what you are getting at?  How would I use this type of
>>> scenario to test?
>>>
>>>        
>> keeping the mailing list cc-ed is recommended, since others can respond
>> faster and new people can benefit of the discussion.
>>
>> What I wanted to say is that kamailio does not reply 481. So the problem is
>> in the responder of requests sent by UAC and forwarded by Kamailio. Somehow,
>> the dialog is destroyed before the BYE (or other in-dialog request) is sent
>> by UAS.
>>
>> If you can grab the SIP trace of such call (e.g., using ngrep on kamailio
>> server), I can give more hits (try to select the sip flow for one such call
>> only, sending full sip trace will be too big).
>>
>> Cheers,
>> Daniel
>>      
> Thanks Daniel.  I've moved on from the Dispatcher and now working with
> the carrierroute.  The first thing I notice is the transactions, being
> stateful has resolved the issue I was seeing with the dispatcher and
> sipp sending invites.  So and I don't have the dispatcher setup to
> collect sip traces, best I can tell is either my configuration or the
> lack of stateful tracking in the dispatcher module was the cause of my
> original post.
>
> I'm going to move the discussion along to a new topic for now, thanks.
>    
just for sake of completion - dispatcher has not much to do with 
stateless/stateful processing. Practically, dispatcher sets the address 
of next hop and builds a list of alternative routes in case first one 
fails. Stateless/stateful processing is decided in config, by using 
either forward() or t_relay().

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Miami, Fl, USA - June 21-23, 2010
http://www.asipto.com/index.php/kamailio-advanced-training/