| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
No, there is no CANCEL and there is no
response from the IP (it’s a fake IP there is no UA running there –
specifically to test greylisting). This is a 408 generated by the stack. And
the transaction is in state “Calling” Brocha From: Byron Campen
[mailto:bcampen@xxxxxxxxxxxx] Greylisting
should only happen if we get no response from the wire; a 408 that was actually
received from the other end doesn't count. Also, if we have received a
provisional on the same transaction, we probably shouldn't greylist. Now, in
what event are you getting a timeout after a provisional in an INVITE
transaction? I think this can only occur after a CANCEL has been sent,
correct? Best regards, Byron Campen
Hi, I see that
if a DNS resolved IP is not responding that IP doesn’t get greylisted because
in TransactionState::sendToTU(TransactionMessage* msg) mState==Calling
and not Trying as the if is looking for. If I change the if to
if(sipMsg->getReceivedTransport() == 0 && (mState == Trying ||
mState == Calling)) // only greylist if internal\ ly generated
and we haven't received any responses yet Then I get
the expected behavior. Can someone
please explain? Thanks, Brocha _______________________________________________ resiprocate-devel mailing list |