Hi!
If ser relays an INVITE transaction stateful (t_relay), it automatically sends a provisional response (100 trying) back to the caller. When t_relay()ing non-INVITE requests (e.g. BYE), there will no (100 trying) produced. Any special reason for this?
So if the request timeouts (no repsonse within 500ms), both - ser and the callers UA - will retransmit the request.
My way to solve this would be:
... if ((method!="INVITE") && (method!="ACK")) sl_send_reply("100", "trying..."); t_relay() ...
Another possibility would be to relay non-INVITE requests stateless. Any comments/suggestions on this?
regards, Klaus
At 12:55 PM 3/23/2004, Klaus Darilion wrote:
Hi!
If ser relays an INVITE transaction stateful (t_relay), it automatically sends a provisional response (100 trying) back to the caller. When t_relay()ing non-INVITE requests (e.g. BYE), there will no (100 trying) produced. Any special reason for this?
RFC3261. (I have to admit though I am not 100% convinced leaving 100 out from non-INVITEs was a great buy.)
So if the request timeouts (no repsonse within 500ms), both - ser and the callers UA - will retransmit the request.
My way to solve this would be:
... if ((method!="INVITE") && (method!="ACK")) sl_send_reply("100", "trying..."); t_relay() ...
I'm not aware of a practical harm of doing so.
Another possibility would be to relay non-INVITE requests stateless. Any comments/suggestions on this?
I have been thinking of that too, just to avoid memory consumption. Fine as long as you don't need statful functionality such as accounting.
-jiri
Jiri Kuthan wrote:
Another possibility would be to relay non-INVITE requests stateless. Any comments/suggestions on this?
I have been thinking of that too, just to avoid memory consumption. Fine as long as you don't need statful functionality such as accounting.
Oh, yes. That was the reason I used stateful relaying - now I remember. :-)
Klaus
At 01:15 PM 3/23/2004, Klaus Darilion wrote:
Jiri Kuthan wrote:
Another possibility would be to relay non-INVITE requests stateless. Any comments/suggestions on this?
I have been thinking of that too, just to avoid memory consumption. Fine as long as you don't need statful functionality such as accounting.
Oh, yes. That was the reason I used stateful relaying - now I remember. :-)
Well, one could trade unlimited memory consumption caused by stateful processing for the accounting overhead. It comes down to what is worse overhead for your installation. In normal situation, stateful processing will eliminate generation of duplicate CDRs on BYE retransmissions. In abnormal situations with excessive traffic, the memory consumption caused by stateful processing may be a more significant overhead than that caused by accounting. If you optimize for such a case, you may generate a CDR for each BYE (and not care about what the reply for it is and duplicates due to retransmissions).
-jiri
-
Jiri Kuthan -
Klaus Darilion