[reSIProcate] Performance of a P2P-over-SIP program using resiprocate

[Byron Campen]

	The resip stack is capable of way more than 9 CPS, even when running  
at full DEBUG. Something is wrong with the sipp scenario, I bet.

	My first question is why you're using a 6xx-class response here. 6xx- 
class responses indicate a _global_ failure for a request. This is  
the tactical nuke of the sip world, and you probably shouldn't be  
using it.

	My second question is what your sipp scenario looks like. Are you  
making sure the branch-param of the ACK matches the branch-param of  
the INVITE? (since you're sending an ACK/failure; note that if you're  
using a 2xx response, you need to make sure that the branch on the  
ACK is different) Also, it might be worthwhile to examine the line- 
endings on the ACK that sipp is sending. sipp has been known to  
sometimes use things other than CRLF, and this will cause the stack  
to drop the message as garbage.

	If you want us to look at some logs, just have sipp fire off a  
single call, and log at DEBUG. That should give us a more precise  
idea of what is going on. A trace would be helpful also.

Best regards,
Byron Campen

> Hi!
>
> I developed for my thesis a program that uses resip. The scheme works
> using super peers that answer queries from mobile users.
>
> The super peer answers queries like this:
>
> Client         reSIP super-peer
>    |     INVITE      |
>    |---------------->|
>    |      606        |
>    |<----------------|
>    |      ACK        |
>    |---------------->|
>    |                 |
>
> I am using 606 to carry the answer back to the client. In this basic
> form there is no P2P interaction (the P2P is between super-peers).
>
> When using the "real" client all works perfectly fine.
>
> Now I am doing some performance testing using SIPp (test tool).
>
> The performance is not good, only 9CPS. After that the stack is
> re-sending 606 messages even though in a wireshark trace the ACK is
> sent immediately after the 606 is received by SIPp. Very soon the
> supe-peer drowns in retransmissions.
>
> I recompiled the stack with a T1 timer value of 1000ms hoping that
> this would give more time to get the ACK processed, but got exactly
> the same results.
>
> I have analyzed the logs in DEBUG and INFO modes, and cannot see any
> error message so I am assuming the ACK is not being dropped.
>
> I know this is difficult to analyze like this but if someone could
> give me any pointers as why this could possibly be happening I would
> be extremely thankful.
>
> Of course I have plenty of traces and logs, if you think those could
> be useful.
>
> Thank you.
>
> Victor M.
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070504/0a52e890/attachment.bin>