yes you are write by seeing the pcap file I knew something wrong but somehow
the calls are completed. Let me try to correct the scenario file.
On Fri, Mar 4, 2011 at 6:18 AM, mayamatakeshi <mayamatake...@gmail.com>wrote:
>
> On Fri, Mar 4, 2011 at 3:00 AM, Gopalakrishnan A.N <sai...@gmail.com>wrote:
>
>> while executing the attached script the result is success and there is no
>> failed call, infact i am able to generate sip log in the server end. But
>> while checking the wireshark log the flow seems to be different when
>> compared to normal scenario. Attached is the pcap file.
>>
>> why is the flow seems to be different just want to understand. The results
>> are success no error in the sipp.
>>
>>
> You are not telling us what is the difference you see between the scenario
> file and the packet capture.
> And there is not a single complete call in the pcap file (all calls are in
> "IN CALL" or "CALL SETUP" state instead of "COMPLETED").
>
> It is better to run sipp with "-m 1" and get the capture of only one call
> from start to end. Then you can be more clear saying: "Look at packet
> number 3. Why we have such packet? It is not expected according to the
> scenario but the call was successful anyway" or something like that.
>
>
>>
>> On Thu, Mar 3, 2011 at 8:46 PM, Gopalakrishnan A.N <sai...@gmail.com>wrote:
>>
>>> Hi,
>>>
>>> I am able to execute the INVITE - 100 - 180 - 200 - ACK - Bye... its
>>> working fine... let me do some more R&D....Thanks for all your assistance.
>>>
>>>
>>> On Thu, Mar 3, 2011 at 6:41 PM, Gopalakrishnan A.N <sai...@gmail.com>wrote:
>>>
>>>> ok thank you
>>>>
>>>>
>>>> On Thu, Mar 3, 2011 at 6:16 AM, mayamatakeshi
>>>> <mayamatake...@gmail.com>wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 3, 2011 at 9:45 AM, mayamatakeshi <mayamatake...@gmail.com
>>>>> > wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 3, 2011 at 12:57 AM, Gopalakrishnan A.N <sai...@gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> What is the difference between writing script like this for INVITE
>>>>>>>
>>>>>>> <recv request="INVITE" rrs="true" crlf="true" />
>>>>>>>
>>>>>>> and like this
>>>>>>>
>>>>>>> INVITE sip:*[service]*@*[remote_ip]*:*[remote_port]* SIP/2.0
>>>>>>> Via: SIP/2.0/*[transport]* *[local_ip]*:*[local_port]*
>>>>>>> From: sipp <sip:sipp@*[local_ip]*:*[local_port]*>;tag=*[call_number]*
>>>>>>> To: sut <sip:*[service]*@*[remote_ip]*:*[remote_port]*>
>>>>>>> Call-ID: *[call_id]*
>>>>>>> Cseq: 1 INVITE
>>>>>>> Contact: sip:sipp@*[local_ip]*:*[local_port]*
>>>>>>> Max-Forwards: 70
>>>>>>> Subject: Performance Test
>>>>>>> Content-Type: application/sdp
>>>>>>> Content-Length: *[len]*
>>>>>>>
>>>>>>> v=0
>>>>>>> o=user1 53655765 2353687637 IN IP*[local_ip_type]* *[local_ip]*
>>>>>>> s=-
>>>>>>> t=0 0
>>>>>>> c=IN IP*[media_ip_type]* *[media_ip]*
>>>>>>> m=audio *[media_port]* RTP/AVP 0
>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>
>>>>>>> Is it same or different?
>>>>>>>
>>>>>>
>>>>>> They are not the same thing. The first is a xml tag used to instruct
>>>>>> sipp to wait for a message (recv means receive)
>>>>>> The second is actually the contents of a message that you are
>>>>>> instructing sipp to send (so actually, it goes inside a xml tag <send/>).
>>>>>> Read about xml here http://en.wikipedia.org/wiki/XML
>>>>>> A sipp scenario is basically a sequence of <send/. and <recv/>
>>>>>> commands. So you send a message like USIN using <send/> and wait for
>>>>>> responses like 100/401/407/200 using <recv/>, then you send another
>>>>>> message
>>>>>> using <send/> and wait for other responses using <recv/> and so on.
>>>>>>
>>>>>
>>>>> There were some typos:
>>>>>
>>>>>
>>>>> They are not the same thing. The first is a xml tag used to instruct
>>>>> sipp to wait for a message (recv means receive)
>>>>> The second is actually the contents of a message that you are
>>>>> instructing sipp to send (so actually, it goes inside a xml tag <send/>).
>>>>> Read about xml here http://en.wikipedia.org/wiki/XML
>>>>> A sipp scenario is basically a sequence of <send/> and <recv/>
>>>>> commands. So you send a message like INVITE using <send/> and wait for
>>>>> responses like 100/401/407/200 using <recv/>, then you send another
>>>>> message
>>>>> using <send/> and wait for other responses using <recv/> and so on.
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Thank you with regards,
>>>> Gopalakrishnan A.N.
>>>> VoIP call - sip:sai...@gtalk2voip.com
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Thank you with regards,
>>> Gopalakrishnan A.N.
>>> VoIP call - sip:sai...@gtalk2voip.com
>>>
>>>
>>>
>>
>>
>> --
>> Thank you with regards,
>> Gopalakrishnan A.N.
>> VoIP call - sip:sai...@gtalk2voip.com
>>
>>
>>
>
--
Thank you with regards,
Gopalakrishnan A.N.
VoIP call - sip:sai...@gtalk2voip.com
------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
