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
