Hi Venkat,
One thing I don't really understand in what you are trying to achieve here is
how you'd control which new call-ID gets assigned to which SIPp call instance.
If I understand what you're describing below, a same call (scenario) instance
would hold data for a REGISTER and an INVITE but nothing tells these are
related in any way? And if they are not necessarily related, what do you intent
to gain by combining them into a single scenario instance?
BTW, in IMS Bench SIPp (http://sipp.sourceforge.net/ims_bench), we've
implemented support for multiple scenarios in parallel within a single SIPp
process but there, there is a lot more orchestration happening - including
between multiple SIPp instances - to make sure the various scenarios that are
related do make use of common data, etc. (in case of IMS Bench SIPp, the shared
data is based on the user on behalf of which the scenario instance executes).
-David
________________________________
From: Venkat Narasimhan [mailto:[EMAIL PROTECTED]
Sent: mercredi 3 décembre 2008 7:21
To: Peter Higginson; sipp_users
Subject: Re: [Sipp-users] One Call-ID per scenario
Yes it would be, but consider this ... before SIPp even interprets
[last_Call-ID:], how about reverting back to the corresponding call-ID: by
maintaining some state in the code ...
say SIPp receives a REGISTER, the hack stores the call-ID and tags at index 0
of an arbitary array and sends 200 OK. Then it recieves an INVITE at this point
INVITE's call ID and tags gets stored in the same array at index 1. now
INVITE's call-ID gets replaced with REGISTER's call-ID. when any response goes
out ... we can compare the tags and accordingly replace the call-ID of the
response with the approproate call-ID stored in the array ...
this is just one thing to do ... specifically to achieve one call-flow ... will
this break anything ?
ps: sorry it was not john's reply but charles's reply
________________________________
From: Peter Higginson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]; sipp_users <sipp-users@lists.sourceforge.net>
Sent: Tuesday, 2 December, 2008 21:20:11
Subject: RE: [Sipp-users] One Call-ID per scenario
I did not see the suggestion, but if you looked for (or have) a hack that
changes the parameter to the Call-ID lookup, then [last_Call-ID] would enable
you to construct replies with the received Call-ID.
It sounds like you are changing the incomming message which then completely
loses the received Call-ID (and may also log the wrong value - which I think
would be a very bad thing to do).
Peter
________________________________
Date: Tue, 2 Dec 2008 06:24:43 +0000
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; sipp-users@lists.sourceforge.net
Subject: Re: [Sipp-users] One Call-ID per scenario
@ John - Thanks, I did what u suggested
the hack is changing the call-id of an incoming msg to the first call-ID if its
different from the first Call-ID ... its pretty neat and SIPp does'nt complain
...
the downside is that all incoming msgs which have different call-IDs will have
their call-ID changed .. :p ...
and to top it, all msgs sent from SIPp would have that old call-ID irespective
of which call that caused these msgs to go out ...
i may have to add more code to make the responses have the proper call-IDs, by
having some sort of state being maintained...
hypothetically, if this is done .. its not a major change right ?? am I missing
something here ...
If so, I would really like it is the next version had this issue fixed .. :)
Thanks and I'll keep you posted.
Venkat
________________________________
From: Venkat Narasimhan <[EMAIL PROTECTED]>
To: sipp-users@lists.sourceforge.net
Sent: Monday, 1 December, 2008 12:34:52
Subject: [Sipp-users] One Call-ID per scenario
Folks,
I am looking for a hack/mod that lets SIPp(running an xml) accept/send SIP msgs
irrespective of call-ID.
Is this too much to expect/does it require just a small code change or a major
design change in SIPp...
Or has this been debated before ???
Any Responses will be deeply appreciated.
Thanks in Advance
Regards
Venkat
________________________________
Great search results, great prizes. BigSnapSearch.com Search
now<http://clk.atdmt.com/UKM/go/117442309/direct/01/>
---------------------------------------------------------------------
Intel Corporation NV/SA
Rond point Schuman 6, B-1040 Brussels
RPM (Bruxelles) 0415.497.718.
Citibank, Brussels, account 570/1031255/09
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
