*actually the problem is that my callee crashes every time upon receiving
the Bye ( segmentation problems ! ) without even counting the received Bye
and therefore without terminating the ongoing call appropriately *
*for load tests this is crucial !*
*I saw the traces and thought maybe it's the via header but obviously this
isn't the case*
* ( I ll use the $second_via_header & $first_via_header in another scenario
so thanks by the way :D )*
2011/7/8 mayamatakeshi <mayamatake...@gmail.com>
>
>
> On Fri, Jul 8, 2011 at 9:54 PM, Hamza MIMI <inpt2...@gmail.com> wrote:
>
>> **
>> *Thanks for your answer , it looks like it's working fine now in the
>> authentication part *
>> *but I do have another probleme though ...*
>> *in my script upon receiving a Bye I should send a 200 OK answer with the
>> [last via:] *
>> *the probleme is that the received Bye contains multiple via headers and
>> when injecting the last via in my script it conctenate the two received VIAs
>> and send the whole thing *
>> *is there a way to change that !? *
>>
>
> But why is this a problem? As far as I know, all responses must be sent
> containing all Via info received in the request.
> It just happens that sipp [last_via:] concatenates them in a single Via
> header, which is perfectly legal.
>
> If you really need to get the last Via header and send only that (to
> simulate a buggy server for example) or because the client cannot cope with
> concatenated info in a single Via header (in which case you want to send
> both headers, but not concatenated), you can use a ereg action upon
> reception of the request extract the desired Via header(s) and inject
> it/them in the reply. Like this:
>
> <recv request="BYE" crlf="true">
> <action>
> <ereg regexp="(Via: [^\n]*\n)(Via: [^\n]*\n)" search_in="msg"
> assign_to="whole_match,first_via_header,second_via_header"/>
> </action>
> </recv>
> <Reference variables="whole_match"/>
>
> Then you could send the Via headers in the inverse order or whatever other
> nasty things to simulate buggy servers:
>
> <send retrans="500">
> <![CDATA[
>
> SIP/2.0 200 OK
> [$second_via_header]
> [$first_via_header]
> [last_From:]
> [last_To:];tag=[pid]SIPpTag01[call_number]
>
> ... abridged ....
>
> ]]>
>
>
>
>
>>
>>
>>
>> 2011/7/5 mayamatakeshi <mayamatake...@gmail.com>
>>
>>>
>>>
>>> On Tue, Jul 5, 2011 at 6:20 PM, Hamza MIMI <inpt2...@gmail.com> wrote:
>>>
>>>> *Hello all *
>>>> *I am currently doing some tests using SIPp , and I noticed that the
>>>> authentication header is truncated causing a registration failure!*
>>>> *am doing an authentication with Digest / MD5 and the Opaque Value is
>>>> always truncated in the same place ! *
>>>> **
>>>> *In the returned 401 : *
>>>>
>>>> Opaque Value: *
>>>> "ALU:QbkRBthOEgEQAkhWV1hYRAIBHgkdHwQCQ1lFRkVWCQgucyo3JnZ0ZiAnOGI
>>>> -KD1-PzcnbmBmbmg_"*
>>>> **
>>>> *In the following SIPp REGISTER (*opaque field is shortened*)*
>>>>
>>>>
>>>>
>>>> Opaque Value: *
>>>> "ALU:QbkRBthOEgEQAkhWV1hYRAIBHgkdHwQCQ1lFRkVWCQgucyo3JnZ0ZiAnOGI"*
>>>> **
>>>> *
>>>>
>>>> according to RFC2617
>>>>
>>>>
>>>>
>>>> opaque
>>>>
>>>> A string of data, specified by the server, which should be returned
>>>>
>>>> by the client unchanged in the Authorization header of subsequent
>>>>
>>>> requests with URIs in the same protection space. It is recommended
>>>>
>>>> that this string be base64 or hexadecimal data.
>>>>
>>>> *
>>>> **
>>>> **
>>>> **
>>>> *I will apreciate any help regarding this issue *
>>>>
>>>> **
>>>> *Thanks All*
>>>>
>>> *
>>>
>>> *
>>> Looking at sipp code we see this:
>>>
>>> char tmp[MAX_HEADER_LEN], authtype[16], cnonce[32], nc[32], *
>>> opaque[64];*
>>>
>>> So, opaque is too long and it is being truncated (63 chars plus
>>> zero-terminator)
>>> It should not be difficult do solve (assuming the issue is just this).
>>> Do some tweaking (increase opaque buffer length) and recompile sipp.
>>>
>>>
>>>
>>>
>>
>
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
