23 Mar
2004
23 Mar
'04
12:55 p.m.
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
23 Mar
23 Mar
1:11 p.m.
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
1:15 p.m.
Jiri Kuthan wrote:
Oh, yes. That was the reason I used stateful relaying - now I remember. :-)
Klaus
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.
1:32 p.m.
At 01:15 PM 3/23/2004, Klaus Darilion wrote:
Jiri Kuthan wrote:
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
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.
7556
days inactive
7556
days old
3 comments
2 participants
participants (2)
-
Jiri Kuthan -
Klaus Darilion