Hi, I think this is probably due to the use of TCP - because TCP is a connection-oriented protocol, it's common to simply send messages back over the TCP connection the REGISTER came in on, rather than constructing a new connection based on the Contact header.
I take it that you need to use TCP rather than UDP, that you need to register your clients before receiving calls, and that there's no way to stop the server changing the Call-ID? Rob On 23 January 2014 21:03, <synverli...@hushmail.com> wrote: > I’m facing an issue, probably related to how ports & sockets gets used by > SIPp > > sipp -sf SND <sip_server_ip>:<sip_server_port> -t tn -p 45001 > sipp -oocsf REC <sip_server_ip>:<sip_server_port> -t tn -p 45002 > > Scenario: SND running on port 45001 > Sender registering on a specific port (per say 45001) > Receiver registering on a different port [per say 45002 – hardcoding this > port value in <Contact:>] > Send a message from sender to receiver > > Scenario: REC running on port 45002 > Accept incoming messages (out-of-call) and respond 200 back to complete > flow. > ** I had to use –oocsf because the call-id is changed by the server. > > Server is delivering message to recipient, but on a different port other > than expected 45002. > So REC isn’t able to receive the message. > > Are there any options to overcome this specific issue. > Your help is appreciated. > > Thanks ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Sipp-users mailing list Sipp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sipp-users