Hi Olivier,
This is what I have done in my local
version:
1) I
have added timeout=”milliseconds” as a recv (and recvCmd) option.
This sets a time limit on how long to wait for a received message. (Note that
if you have optional receives in a sequence, the timeout needs to be set on
every one, not just the last. The times may be additive.)
2) I
have added as an option to timeout for recv,
recvCmd and send (with retrans) to allow control of the flow on timeout rather
than just dropping through to the next statement.
3) I
have added CANCEL and BYE to the list of received packets that terminate a
retransmission. (The problem is that you cannot do any other sends while a
previous one is still retransmitting.)
4) I
have added optional=”global” as a new option and changed the
meaning of optional=”true” to be limited to a consecutive sequence
of receives.
3) and 4) were things I found necessary with
the greater use of optional receives, next etc.
These have now been working for a month or
so. Let me know if you are interested in adopting any of them and I will
extract the changes and try to see how they would fit into the latest public
code.
Regards,
Peter
From: Olivier Jacques
[mailto:[EMAIL PROTECTED]
Sent: 08 August 2006 16:02
To: Peter Higginson
Cc: Rick Davis;
[email protected]
Subject: Re: [Sipp-users] Timeout
for Message Response
Hi Peter,
did you had the opportunity to progress on this topic? Anything you would like
to share?
thanks a lot...
Olivier.
On 6/18/06, Peter
Higginson <[EMAIL PROTECTED]>
wrote:
Hi Olivier,
The change I'm looking at is per message, set in the scenario file. That
allows you more easily to do different things depending on whether the call
was open or not.
Clearly if you really want a global one then it is a bit laborious, but
possible.
I don't use the default behaviour changes, so I don't have abortCall as an
option. That might be a sensible default behaviour on receive timeout
without an explicit label to go to. When my things work, I'll indicate where
in them you would do it and you can decide which to add to the generic SIPp.
Regards,
Peter
Peter Higginson
Newport Networks Ltd,
Direct line 01494 470694
http://www.newport-networks.com/
-----Original Message-----
From: Olivier Jacques [mailto:[EMAIL PROTECTED]]
Sent: 18 June 2006 09:22
To: Peter Higginson
Cc: Rick Davis; [email protected]
Subject: Re: [Sipp-users] Timeout for Message Response
Hi Peter,
Timeout feature is very interesting for a bulk call generator. Thanks
Peter to have a look at it.
I'm not sure if the timeout feature should be per message or globally,
for the entire scenario, or both (a choice).
Maybe having a global timeout would be enough. Then, the ontimeout
could be simply a call to abortCall, just to close the call that is
"hanging".
What do you think?
Olivier.
On 6/18/06, Peter Higginson <
[EMAIL PROTECTED]> wrote:
>
> I'm working on a change to allow timeout="milliseconds" to be
added to
recv
> and recvCmd commands and to be added to those
and the
send
> command so you can make different things happen.
>
> It is not debugged yet, but if there is interest in having the changes I
> will share them once I'm reasonably sure they work correctly.
>
> I don't have the default behaviour stuff in the version I use - I think
the
> right interaction is for the send ontimeout test to be before the default
> behaviour test but someone who uses it might like to comment.
>
> Peter
>
> Peter Higginson
> Newport Networks Ltd,
> Direct line 01494 470694
> http://www.newport-networks.com/
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
] On Behalf Of Rick Davis
> Sent: 17 June 2006 02:35
> To: [email protected]
> Subject: [Sipp-users] Timeout for Message Response
>
>
> SIPp Users,
>
> In XML scenario file expects a specific message response.
>
> Is there a syntax that would allow for a timeout and continue if a
> expected message is not received.
>
> Rick
>
>
>
>
>
> _______________________________________________
> Sipp-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sipp-users
>
>
> ---------------
> This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and delete this e-mail. Any
unauthorized copying, disclosure or distribution of the contents in this
e-mail is strictly forbidden.
> ---------------
>
>
>
> _______________________________________________
> Sipp-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sipp-users
>
--
HP OpenCall Software
http://www.hp.com/go/opencall/
---------------
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and delete this e-mail. Any unauthorized copying,
disclosure or distribution of the contents in this e-mail is strictly
forbidden.
---------------
--
HP OpenCall Software
http://www.hp.com/go/opencall/
