Re: [Sipp-users] Option in recv

If SIPp is UAS, it will accept messages from anywhere, as long as the message has the correct call-id. What are you experiencing? On 3/5/07, Monica.S [EMAIL PROTECTED] wrote: Hi, My requirement is to be able to specify another entity as the one from which the message is expected .Not the

Re: [Sipp-users] Option in recv

I always thought that SIPP listened on the port, would take packets from anywhere and just match the Call-ID. Peter _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Monica.S Sent: 05 March 2007 13:57 To: Alok Mohapatra; sipp-users@lists.sourceforge.net Subject:

[Sipp-users] Retransmission Counter Fix

Hello, This patch corrects a couple of bugs in received transmission handling: (1) If a send is unsuccessful, the retransmission should still be counted as received. (2) Cookies for optional messages should also be recorded so that the has comparison works. (3) If a message matches

[Sipp-users] reinvite with UAS and peer_tag_param issue

Hi, I am sending a re-invite with a UAS script in SIPp and am having trouble with the [peer_tag_param] not getting populated on the To header. Is there anything I am missing? See my script below. Thanks for any help, Paul recv request=INVITE/recv send ![CDATA[ SIP/2.0 180 Ringing

Re: [Sipp-users] reinvite with UAS and peer_tag_param issue

Paul, From a quick look at the code, it seems that the peer tag is only picked up out of responses and not replies, and in your scenario there are no received replies before you use the peer_tag_param. You should take a look at this bit of code: /* It is a response: update peer_tag */

[Sipp-users] Feature proposal: Wildcard notation for response code

Hi, I propose the following feature: As an alternative to using multiple response statements (and always including a new response code on occasion) like: recv response=403 optional=true next=1 /recv recv response=404 optional=true next=1 /recv recv