| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
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@xxxxxxxxxxxxxxxxxxxx https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
Attachment:
smime.p7s
Description: S/MIME cryptographic signature