Hello,
I want to send an immediate 100 trying message when an Invite is received, then I do a DB lookup, then I rewrite the RURI and forward the message using t_relay.
Since I have already sent a 100 trying manually I'd like to short circuit the 100 t_relay sends so multiple 100 trying messages aren't sent.
Does anyone know of a way to do this?
Thanks,
T.R.
AFAI remember there was function t_relay_no_ack or similar. Take a lookat the README from TM module.
regards klaus
T.R. Missner wrote:
Hello,
I want to send an immediate 100 trying message when an Invite is received, then I do a DB lookup, then I rewrite the RURI and forward the message using t_relay.
Since I have already sent a 100 trying manually I’d like to short circuit the 100 t_relay sends so multiple 100 trying messages aren’t sent.
Does anyone know of a way to do this?
Thanks,
T.R.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
At the top of our ROUTE_INVITE, we have:
#---------------------------------------------------------------------- # Let the UA know we are working on their request - # they shouldn't send retransmissions #---------------------------------------------------------------------- sl_send_reply("100", "Trying");
This seems to work and it was adapted from code used during REGISTER processing.
Regards, Norm
Klaus Darilion wrote:
AFAI remember there was function t_relay_no_ack or similar. Take a lookat the README from TM module.
regards klaus
T.R. Missner wrote:
Hello,
I want to send an immediate 100 trying message when an Invite is received, then I do a DB lookup, then I rewrite the RURI and forward the message using t_relay.
Since I have already sent a 100 trying manually I’d like to short circuit the 100 t_relay sends so multiple 100 trying messages aren’t sent.
Does anyone know of a way to do this?
Thanks,
T.R.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi,
Norman Brandinger wrote:
At the top of our ROUTE_INVITE, we have:
#---------------------------------------------------------------------- # Let the UA know we are working on their request - # they shouldn't send retransmissions #---------------------------------------------------------------------- sl_send_reply("100", "Trying");
This seems to work and it was adapted from code used during REGISTER processing.
If I got Missner's problem right, he wants to prevent sending multiple 100 replies back to the uac.
The rfc says - Page 109, paragraph 5 - that "MUST be forwarded immediately [...] Any provisional response other than 100 (Trying)" and later, in same paragraph that "A stateful proxy MUST NOT immediately forward any other [= 101<=x<=299] responses". Now, it's true that in this case the proxy would not literally forward a 100 reply back, but the uac would still see 2x100.
Now, if he does SL reply at the beginning, the tm module will, again, send a 100 on his own, before relaying.
The question is how to prevent this, if I got it right...
WL.
Regards, Norm
Klaus Darilion wrote:
AFAI remember there was function t_relay_no_ack or similar. Take a lookat the README from TM module.
regards klaus
T.R. Missner wrote:
Hello,
I want to send an immediate 100 trying message when an Invite is received, then I do a DB lookup, then I rewrite the RURI and forward the message using t_relay.
Since I have already sent a 100 trying manually I’d like to short circuit the 100 t_relay sends so multiple 100 trying messages aren’t sent.
Does anyone know of a way to do this?
Thanks,
T.R.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
You have the question exactly correct
Now - how can I do this?
-----Original Message----- From: users-bounces@openser.org [mailto:users-bounces@openser.org] On Behalf Of Weiter Leiter Sent: Thursday, July 20, 2006 1:31 PM To: Norman Brandinger Cc: users Subject: Re: [Users] provisional response management ( 100 Trying )
Hi,
Norman Brandinger wrote:
At the top of our ROUTE_INVITE, we have:
#---------------------------------------------------------------------
- # Let the UA know we are working on their request - # they
shouldn't send retransmissions
#---------------------------------------------------------------------
sl_send_reply("100", "Trying");
This seems to work and it was adapted from code used during REGISTER processing.
If I got Missner's problem right, he wants to prevent sending multiple 100 replies back to the uac.
The rfc says - Page 109, paragraph 5 - that "MUST be forwarded immediately [...] Any provisional response other than 100 (Trying)" and later, in same paragraph that "A stateful proxy MUST NOT immediately forward any other [= 101<=x<=299] responses". Now, it's true that in this case the proxy would not literally forward a 100 reply back, but the uac would still see 2x100.
Now, if he does SL reply at the beginning, the tm module will, again, send a 100 on his own, before relaying.
The question is how to prevent this, if I got it right...
WL.
Regards, Norm
Klaus Darilion wrote:
AFAI remember there was function t_relay_no_ack or similar. Take a lookat the README from TM module.
regards klaus
T.R. Missner wrote:
Hello,
I want to send an immediate 100 trying message when an Invite is received, then I do a DB lookup, then I rewrite the RURI and forward
the message using t_relay.
Since I have already sent a 100 trying manually I'd like to short circuit the 100 t_relay sends so multiple 100 trying messages aren't
sent.
Does anyone know of a way to do this?
Thanks,
T.R.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Why would you want to prevent it? 1XX class messages are all provisional, do not solicit a response and are never forwarded upstream so only the previous hop will get multiple 100 messages which will effectively limit any chance of the upstream hop re-transmitting the original message.
Take the following example; A user sends their initial INVITE, you sl_send_reply 100 and then check your proxy_authorize which returns a 407 and challenges the user. The user sends the second invite with credentials you sl_send_reply 100 and then check your proxy_authorize again and say, for instance, your DB server is now under heavy load (a cronjob runs, etc) and takes longer then 1s to respond, since you haven't called t_relay yet which generates the second 100 message your initial 100 message would still stop the user from re-transmitting the INVITE while proxy_authorize is waiting for the DB.
-Evan
T.R. Missner wrote:
You have the question exactly correct
Now - how can I do this?
-----Original Message----- From: users-bounces@openser.org [mailto:users-bounces@openser.org] On Behalf Of Weiter Leiter Sent: Thursday, July 20, 2006 1:31 PM To: Norman Brandinger Cc: users Subject: Re: [Users] provisional response management ( 100 Trying )
Hi,
Norman Brandinger wrote:
At the top of our ROUTE_INVITE, we have:
#---------------------------------------------------------------------
- # Let the UA know we are working on their request - # they
shouldn't send retransmissions
#---------------------------------------------------------------------
sl_send_reply("100", "Trying");
This seems to work and it was adapted from code used during REGISTER processing.
If I got Missner's problem right, he wants to prevent sending multiple 100 replies back to the uac.
The rfc says - Page 109, paragraph 5 - that "MUST be forwarded immediately [...] Any provisional response other than 100 (Trying)" and later, in same paragraph that "A stateful proxy MUST NOT immediately forward any other [= 101<=x<=299] responses". Now, it's true that in this case the proxy would not literally forward a 100 reply back, but the uac would still see 2x100.
Now, if he does SL reply at the beginning, the tm module will, again, send a 100 on his own, before relaying.
The question is how to prevent this, if I got it right...
WL.
Regards, Norm
Klaus Darilion wrote:
AFAI remember there was function t_relay_no_ack or similar. Take a lookat the README from TM module.
regards klaus
T.R. Missner wrote:
Hello,
I want to send an immediate 100 trying message when an Invite is received, then I do a DB lookup, then I rewrite the RURI and forward
the message using t_relay.
Since I have already sent a 100 trying manually I'd like to short circuit the 100 t_relay sends so multiple 100 trying messages aren't
sent.
Does anyone know of a way to do this?
Thanks,
T.R.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi,
Evan Borgström wrote:
Why would you want to prevent it? 1XX class messages are all provisional, do not solicit a response and are never forwarded upstream so only the previous hop will get multiple 100 messages which will effectively limit any chance of the upstream hop re-transmitting the original message.
Take the following example; A user sends their initial INVITE, you sl_send_reply 100 and then check your proxy_authorize which returns a 407 and challenges the user. The user sends the second invite with credentials you sl_send_reply 100 and then check your proxy_authorize again and say, for instance, your DB server is now under heavy load (a cronjob runs, etc) and takes longer then 1s to respond, since you haven't called t_relay yet which generates the second 100 message your initial 100 message would still stop the user from re-transmitting the INVITE while proxy_authorize is waiting for the DB.
The question is not whether sl replying is good or not - it for sure is. The question is how to be 100% conformant.
However, imho, this misalignment is completely negligible, as if you make abstraction of the possible different reason phrase, the two messages will be identical - this duplicating can be done by some lower layered network entity, so, from the uac's point of view, the 2 100s should not be a problem.
However, adding a config for tm not to take care of the 100 might be the cherry on the cake.
WL.
ps. Imo, this is one of ser/openser's problems: one script function can actually take some more (more or less documented) "atomic" actions than its name states (even in cases where otherwise could be done, without a performance or complexity impact), which, from a strictly programming point of view is completely wrong.
-Evan
T.R. Missner wrote:
You have the question exactly correct
Now - how can I do this?
-----Original Message----- From: users-bounces@openser.org [mailto:users-bounces@openser.org] On Behalf Of Weiter Leiter Sent: Thursday, July 20, 2006 1:31 PM To: Norman Brandinger Cc: users Subject: Re: [Users] provisional response management ( 100 Trying )
Hi,
Norman Brandinger wrote:
At the top of our ROUTE_INVITE, we have:
#---------------------------------------------------------------------
- # Let the UA know we are working on their request - # they
shouldn't send retransmissions
#---------------------------------------------------------------------
sl_send_reply("100", "Trying");
This seems to work and it was adapted from code used during REGISTER processing.
If I got Missner's problem right, he wants to prevent sending multiple 100 replies back to the uac.
The rfc says - Page 109, paragraph 5 - that "MUST be forwarded immediately [...] Any provisional response other than 100 (Trying)" and later, in same paragraph that "A stateful proxy MUST NOT immediately forward any other [= 101<=x<=299] responses". Now, it's true that in this case the proxy would not literally forward a 100 reply back, but the uac would still see 2x100.
Now, if he does SL reply at the beginning, the tm module will, again, send a 100 on his own, before relaying.
The question is how to prevent this, if I got it right...
WL.
Regards, Norm
Klaus Darilion wrote:
AFAI remember there was function t_relay_no_ack or similar. Take a lookat the README from TM module.
regards klaus
T.R. Missner wrote:
Hello,
I want to send an immediate 100 trying message when an Invite is received, then I do a DB lookup, then I rewrite the RURI and forward
the message using t_relay.
Since I have already sent a 100 trying manually I'd like to short circuit the 100 t_relay sends so multiple 100 trying messages aren't
sent.
Does anyone know of a way to do this?
Thanks,
T.R.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Well, if we're going get technical about conforming to the RFC then sending a 100 message for anything other than an INVITE is a "SHOULD NOT".
8.2.6.1 Sending a Provisional Response
One largely non-method-specific guideline for the generation of responses is that UASs SHOULD NOT issue a provisional response for a non-INVITE request. Rather, UASs SHOULD generate a final response to a non-INVITE request as soon as possible.
However, to be RFC strict multiple responses to INVITE's are indeed allowed. Check section 13.1
Before sending a final response, the UAS can also send provisional responses (1xx) to advise the UAC of progress in contacting the called user.
After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses or one non-2xx final response.
All of my real world practices show that sending provisional messages for non INVITE messages is a big help, especially when you get into presence and IM related stuff. All too often clients like eyeBeam re-transmit SUBSCRIBE's, PUBLISH's and MESSAGE's because of latency within the network if you don't send a 100 trying upon receipt. So for me even if it's a SHOULD NOT it still makes my life easier than dealing with questions about receiving IM's twice...
-Evan
Weiter Leiter wrote:
Hi,
Evan Borgström wrote:
Why would you want to prevent it? 1XX class messages are all provisional, do not solicit a response and are never forwarded upstream so only the previous hop will get multiple 100 messages which will effectively limit any chance of the upstream hop re-transmitting the original message.
Take the following example; A user sends their initial INVITE, you sl_send_reply 100 and then check your proxy_authorize which returns a 407 and challenges the user. The user sends the second invite with credentials you sl_send_reply 100 and then check your proxy_authorize again and say, for instance, your DB server is now under heavy load (a cronjob runs, etc) and takes longer then 1s to respond, since you haven't called t_relay yet which generates the second 100 message your initial 100 message would still stop the user from re-transmitting the INVITE while proxy_authorize is waiting for the DB.
The question is not whether sl replying is good or not - it for sure is. The question is how to be 100% conformant.
However, imho, this misalignment is completely negligible, as if you make abstraction of the possible different reason phrase, the two messages will be identical - this duplicating can be done by some lower layered network entity, so, from the uac's point of view, the 2 100s should not be a problem.
However, adding a config for tm not to take care of the 100 might be the cherry on the cake.
WL.
ps. Imo, this is one of ser/openser's problems: one script function can actually take some more (more or less documented) "atomic" actions than its name states (even in cases where otherwise could be done, without a performance or complexity impact), which, from a strictly programming point of view is completely wrong.
-Evan
T.R. Missner wrote:
You have the question exactly correct
Now - how can I do this?
-----Original Message----- From: users-bounces@openser.org [mailto:users-bounces@openser.org] On Behalf Of Weiter Leiter Sent: Thursday, July 20, 2006 1:31 PM To: Norman Brandinger Cc: users Subject: Re: [Users] provisional response management ( 100 Trying )
Hi,
Norman Brandinger wrote:
At the top of our ROUTE_INVITE, we have:
#---------------------------------------------------------------------
- # Let the UA know we are working on their request - # they
shouldn't send retransmissions
#---------------------------------------------------------------------
sl_send_reply("100", "Trying");
This seems to work and it was adapted from code used during REGISTER processing.
If I got Missner's problem right, he wants to prevent sending multiple 100 replies back to the uac.
The rfc says - Page 109, paragraph 5 - that "MUST be forwarded immediately [...] Any provisional response other than 100 (Trying)" and later, in same paragraph that "A stateful proxy MUST NOT immediately forward any other [= 101<=x<=299] responses". Now, it's true that in this case the proxy would not literally forward a 100 reply back, but the uac would still see 2x100.
Now, if he does SL reply at the beginning, the tm module will, again, send a 100 on his own, before relaying.
The question is how to prevent this, if I got it right...
WL.
Regards, Norm
Klaus Darilion wrote:
AFAI remember there was function t_relay_no_ack or similar. Take a lookat the README from TM module.
regards klaus
T.R. Missner wrote:
Hello,
I want to send an immediate 100 trying message when an Invite is received, then I do a DB lookup, then I rewrite the RURI and forward
the message using t_relay.
Since I have already sent a 100 trying manually I'd like to short circuit the 100 t_relay sends so multiple 100 trying messages aren't
sent.
Does anyone know of a way to do this?
Thanks,
T.R.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
On Thu, July 20, 2006 20:25, Evan Borgström said:
Well, if we're going get technical about conforming to the RFC then sending a 100 message for anything other than an INVITE is a "SHOULD NOT".
AFAIK somewhere in the RFC they say you should send a provisional response if the processing of the requests (till we can send a final response) will take more the 200 ms. Thus, sending 100 for non-INVITE is IMO fine. Especially for REGISTER which is handled stateless in openser.
regards klaus
PS: If you still want to know how to do it without 2x100: Use t_newtran and t_forward_nonack. http://www.openser.org/docs/modules/1.1.x/tm.html#TFORWARDNONACK
8.2.6.1 Sending a Provisional Response
One largely non-method-specific guideline for the generation of responses is that UASs SHOULD NOT issue a provisional response for a non-INVITE request. Rather, UASs SHOULD generate a final response to a non-INVITE request as soon as possible.
However, to be RFC strict multiple responses to INVITE's are indeed allowed. Check section 13.1
Before sending a final response, the UAS can also send provisional responses (1xx) to advise the UAC of progress in contacting the called user.
After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses or one non-2xx final response.
All of my real world practices show that sending provisional messages for non INVITE messages is a big help, especially when you get into presence and IM related stuff. All too often clients like eyeBeam re-transmit SUBSCRIBE's, PUBLISH's and MESSAGE's because of latency within the network if you don't send a 100 trying upon receipt. So for me even if it's a SHOULD NOT it still makes my life easier than dealing with questions about receiving IM's twice...
-Evan
Weiter Leiter wrote:
Hi,
Evan Borgström wrote:
Why would you want to prevent it? 1XX class messages are all provisional, do not solicit a response and are never forwarded upstream so only the previous hop will get multiple 100 messages which will effectively limit any chance of the upstream hop re-transmitting the original message.
Take the following example; A user sends their initial INVITE, you sl_send_reply 100 and then check your proxy_authorize which returns a 407 and challenges the user. The user sends the second invite with credentials you sl_send_reply 100 and then check your proxy_authorize again and say, for instance, your DB server is now under heavy load (a cronjob runs, etc) and takes longer then 1s to respond, since you haven't called t_relay yet which generates the second 100 message your initial 100 message would still stop the user from re-transmitting the INVITE while proxy_authorize is waiting for the DB.
The question is not whether sl replying is good or not - it for sure is. The question is how to be 100% conformant.
However, imho, this misalignment is completely negligible, as if you make abstraction of the possible different reason phrase, the two messages will be identical - this duplicating can be done by some lower layered network entity, so, from the uac's point of view, the 2 100s should not be a problem.
However, adding a config for tm not to take care of the 100 might be the cherry on the cake.
WL.
ps. Imo, this is one of ser/openser's problems: one script function can actually take some more (more or less documented) "atomic" actions than its name states (even in cases where otherwise could be done, without a performance or complexity impact), which, from a strictly programming point of view is completely wrong.
-Evan
T.R. Missner wrote:
You have the question exactly correct
Now - how can I do this?
-----Original Message----- From: users-bounces@openser.org [mailto:users-bounces@openser.org] On Behalf Of Weiter Leiter Sent: Thursday, July 20, 2006 1:31 PM To: Norman Brandinger Cc: users Subject: Re: [Users] provisional response management ( 100 Trying )
Hi,
Norman Brandinger wrote:
At the top of our ROUTE_INVITE, we have:
#---------------------------------------------------------------------
- # Let the UA know we are working on their request - # they
shouldn't send retransmissions
#---------------------------------------------------------------------
sl_send_reply("100", "Trying");
This seems to work and it was adapted from code used during REGISTER processing.
If I got Missner's problem right, he wants to prevent sending multiple 100 replies back to the uac.
The rfc says - Page 109, paragraph 5 - that "MUST be forwarded immediately [...] Any provisional response other than 100 (Trying)" and later, in same paragraph that "A stateful proxy MUST NOT immediately forward any other [= 101<=x<=299] responses". Now, it's true that in this case the proxy would not literally forward a 100 reply back, but the uac would still see 2x100.
Now, if he does SL reply at the beginning, the tm module will, again, send a 100 on his own, before relaying.
The question is how to prevent this, if I got it right...
WL.
Regards, Norm
Klaus Darilion wrote:
AFAI remember there was function t_relay_no_ack or similar. Take a lookat the README from TM module.
regards klaus
T.R. Missner wrote:
> Hello, > > > > I want to send an immediate 100 trying message when an Invite is > received, then I do a DB lookup, then I rewrite the RURI and > forward > > the message using t_relay. > > Since I have already sent a 100 trying manually I'd like to short > circuit the 100 t_relay sends so multiple 100 trying messages > aren't > > sent. > > Does anyone know of a way to do this? > > > > Thanks, > > > > T.R. > > > > > -------------------------------------------------------------------- > ---- > > > _______________________________________________ > Users mailing list > Users@openser.org > http://openser.org/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Yep, section 21.1 says that. It's a perfect example of the grey area the RFC creates and why most of us send provisional responses for most/all messages. :)
Just remember that if you're going to sl_send_reply with a 100 for all messages you should first check that method != ACK as ACK's MUST NOT generate a provisional message.
-Evan
Klaus Darilion wrote:
On Thu, July 20, 2006 20:25, Evan Borgström said:
Well, if we're going get technical about conforming to the RFC then sending a 100 message for anything other than an INVITE is a "SHOULD NOT".
AFAIK somewhere in the RFC they say you should send a provisional response if the processing of the requests (till we can send a final response) will take more the 200 ms. Thus, sending 100 for non-INVITE is IMO fine. Especially for REGISTER which is handled stateless in openser.
regards klaus
PS: If you still want to know how to do it without 2x100: Use t_newtran and t_forward_nonack. http://www.openser.org/docs/modules/1.1.x/tm.html#TFORWARDNONACK
8.2.6.1 Sending a Provisional Response
One largely non-method-specific guideline for the generation of responses is that UASs SHOULD NOT issue a provisional response for a non-INVITE request. Rather, UASs SHOULD generate a final response to a non-INVITE request as soon as possible.
However, to be RFC strict multiple responses to INVITE's are indeed allowed. Check section 13.1
Before sending a final response, the UAS can also send provisional responses (1xx) to advise the UAC of progress in contacting the called user.
After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses or one non-2xx final response.
All of my real world practices show that sending provisional messages for non INVITE messages is a big help, especially when you get into presence and IM related stuff. All too often clients like eyeBeam re-transmit SUBSCRIBE's, PUBLISH's and MESSAGE's because of latency within the network if you don't send a 100 trying upon receipt. So for me even if it's a SHOULD NOT it still makes my life easier than dealing with questions about receiving IM's twice...
-Evan
Weiter Leiter wrote:
Hi,
Evan Borgström wrote:
Why would you want to prevent it? 1XX class messages are all provisional, do not solicit a response and are never forwarded upstream so only the previous hop will get multiple 100 messages which will effectively limit any chance of the upstream hop re-transmitting the original message.
Take the following example; A user sends their initial INVITE, you sl_send_reply 100 and then check your proxy_authorize which returns a 407 and challenges the user. The user sends the second invite with credentials you sl_send_reply 100 and then check your proxy_authorize again and say, for instance, your DB server is now under heavy load (a cronjob runs, etc) and takes longer then 1s to respond, since you haven't called t_relay yet which generates the second 100 message your initial 100 message would still stop the user from re-transmitting the INVITE while proxy_authorize is waiting for the DB.
The question is not whether sl replying is good or not - it for sure is. The question is how to be 100% conformant.
However, imho, this misalignment is completely negligible, as if you make abstraction of the possible different reason phrase, the two messages will be identical - this duplicating can be done by some lower layered network entity, so, from the uac's point of view, the 2 100s should not be a problem.
However, adding a config for tm not to take care of the 100 might be the cherry on the cake.
WL.
ps. Imo, this is one of ser/openser's problems: one script function can actually take some more (more or less documented) "atomic" actions than its name states (even in cases where otherwise could be done, without a performance or complexity impact), which, from a strictly programming point of view is completely wrong.
-Evan
T.R. Missner wrote:
You have the question exactly correct
Now - how can I do this?
-----Original Message----- From: users-bounces@openser.org [mailto:users-bounces@openser.org] On Behalf Of Weiter Leiter Sent: Thursday, July 20, 2006 1:31 PM To: Norman Brandinger Cc: users Subject: Re: [Users] provisional response management ( 100 Trying )
Hi,
Norman Brandinger wrote:
At the top of our ROUTE_INVITE, we have:
#---------------------------------------------------------------------
- # Let the UA know we are working on their request - # they
shouldn't send retransmissions
#---------------------------------------------------------------------
sl_send_reply("100", "Trying");
This seems to work and it was adapted from code used during REGISTER processing.
If I got Missner's problem right, he wants to prevent sending multiple 100 replies back to the uac.
The rfc says - Page 109, paragraph 5 - that "MUST be forwarded immediately [...] Any provisional response other than 100 (Trying)" and later, in same paragraph that "A stateful proxy MUST NOT immediately forward any other [= 101<=x<=299] responses". Now, it's true that in this case the proxy would not literally forward a 100 reply back, but the uac would still see 2x100.
Now, if he does SL reply at the beginning, the tm module will, again, send a 100 on his own, before relaying.
The question is how to prevent this, if I got it right...
WL.
Regards, Norm
Klaus Darilion wrote:
> AFAI remember there was function t_relay_no_ack or similar. Take a > lookat the README from TM module. > > regards > klaus > > T.R. Missner wrote: > >> Hello, >> >> >> >> I want to send an immediate 100 trying message when an Invite is >> received, then I do a DB lookup, then I rewrite the RURI and >> forward >> >> the message using t_relay. >> >> Since I have already sent a 100 trying manually I'd like to short >> circuit the 100 t_relay sends so multiple 100 trying messages >> aren't >> >> sent. >> >> Does anyone know of a way to do this? >> >> >> >> Thanks, >> >> >> >> T.R. >> >> >> >> >> -------------------------------------------------------------------- >> ---- >> >> >> _______________________________________________ >> Users mailing list >> Users@openser.org >> http://openser.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > Users@openser.org > http://openser.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Being normative, there's also an RFC relating to the provisional replies to non-INVITE transactions, RFC 4320, which does allow sending 100 provisional responses, and even recommend it, under some circumstances.
Just my 2 cents.
Samuel.
2006/7/20, Evan Borgström evan.borgstrom@ca.mci.com:
Yep, section 21.1 says that. It's a perfect example of the greyarea the RFC creates and why most of us send provisional responses for most/all messages. :)
Just remember that if you're going to sl_send_reply with a 100 forall messages you should first check that method != ACK as ACK's MUST NOT generate a provisional message.
-Evan
Klaus Darilion wrote:
On Thu, July 20, 2006 20:25, Evan Borgström said:
Well, if we're going get technical about conforming to the RFCthen
sending a 100 message for anything other than an INVITE is a "SHOULD
NOT".
AFAIK somewhere in the RFC they say you should send a provisional
response
if the processing of the requests (till we can send a final response)
will
take more the 200 ms. Thus, sending 100 for non-INVITE is IMO fine. Especially for REGISTER which is handled stateless in openser.
regards klaus
PS: If you still want to know how to do it without 2x100: Use t_newtran and t_forward_nonack. http://www.openser.org/docs/modules/1.1.x/tm.html#TFORWARDNONACK
8.2.6.1 Sending a Provisional Response
One largely non-method-specific guideline for the generation of responses is that UASs SHOULD NOT issue a provisional response for a non-INVITE request. Rather, UASs SHOULD generate a final response
to
a non-INVITE request as soon as possible.
However, to be RFC strict multiple responses to INVITE's areindeed
allowed. Check section 13.1
Before sending a final response, the UAS can also send provisional responses (1xx) to advise the UAC of progress in contacting the called user.
After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses or one non-2xx final response.
All of my real world practices show that sending provisionalmessages
for non INVITE messages is a big help, especially when you get into presence and IM related stuff. All too often clients like eyeBeam re-transmit SUBSCRIBE's, PUBLISH's and MESSAGE's because of latency within the network if you don't send a 100 trying upon receipt. So for me even if it's a SHOULD NOT it still makes my life easier than dealing with questions about receiving IM's twice...
-Evan
Weiter Leiter wrote:
Hi,
Evan Borgström wrote:
Why would you want to prevent it? 1XX class messages are all provisional, do not solicit a response and are never forwarded
upstream
so only the previous hop will get multiple 100 messages which will effectively limit any chance of the upstream hop re-transmitting the original message.
Take the following example; A user sends their initial INVITE, you sl_send_reply 100 and then check your proxy_authorize which returns a 407 and challenges the user. The user sends the second invite with credentials you sl_send_reply 100 and then check your proxy_authorize again and say, for instance, your DB server is now under heavy load
(a
cronjob runs, etc) and takes longer then 1s to respond, since you haven't called t_relay yet which generates the second 100 message
your
initial 100 message would still stop the user from re-transmitting
the
INVITE while proxy_authorize is waiting for the DB.
The question is not whether sl replying is good or not - it for sure
is.
The question is how to be 100% conformant.
However, imho, this misalignment is completely negligible, as if you make abstraction of the possible different reason phrase, the two messages will be identical - this duplicating can be done by some
lower
layered network entity, so, from the uac's point of view, the 2 100s should not be a problem.
However, adding a config for tm not to take care of the 100 might be
the
cherry on the cake.
WL.
ps. Imo, this is one of ser/openser's problems: one script function
can
actually take some more (more or less documented) "atomic" actions
than
its name states (even in cases where otherwise could be done, without
a
performance or complexity impact), which, from a strictly programming point of view is completely wrong.
-Evan
T.R. Missner wrote:
You have the question exactly correct
Now - how can I do this?
-----Original Message----- From: users-bounces@openser.org [mailto:users-bounces@openser.org]
On
Behalf Of Weiter Leiter Sent: Thursday, July 20, 2006 1:31 PM To: Norman Brandinger Cc: users Subject: Re: [Users] provisional response management ( 100 Trying )
Hi,
Norman Brandinger wrote:
> At the top of our ROUTE_INVITE, we have: > > >
#---------------------------------------------------------------------
> - # Let the UA know we are working on their request - # they > shouldn't send retransmissions > >
#---------------------------------------------------------------------
> - > sl_send_reply("100", "Trying"); > > This seems to work and it was adapted from code used during
REGISTER
> processing. > If I got Missner's problem right, he wants to prevent sending
multiple
100 replies back to the uac.
The rfc says - Page 109, paragraph 5 - that "MUST be forwarded immediately [...] Any provisional response other than 100 (Trying)" and later, in same paragraph that "A stateful proxy MUST NOT immediately forward any other [= 101<=x<=299] responses". Now, it's true that
in
this case the proxy would not literally forward a 100 reply back,
but
the uac would still see 2x100.
Now, if he does SL reply at the beginning, the tm module will,
again,
send a 100 on his own, before relaying.
The question is how to prevent this, if I got it right...
WL.
> Regards, > Norm > > Klaus Darilion wrote: > >> AFAI remember there was function t_relay_no_ack or similar. Take a >> lookat the README from TM module. >> >> regards >> klaus >> >> T.R. Missner wrote: >> >>> Hello, >>> >>> >>> >>> I want to send an immediate 100 trying message when an Invite is >>> received, then I do a DB lookup, then I rewrite the RURI and >>> forward >>> >>> the message using t_relay. >>> >>> Since I have already sent a 100 trying manually I'd like to short >>> circuit the 100 t_relay sends so multiple 100 trying messages >>> aren't >>> >>> sent. >>> >>> Does anyone know of a way to do this? >>> >>> >>> >>> Thanks, >>> >>> >>> >>> T.R. >>> >>> >>> >>> >>>
>>> ---- >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users@openser.org >>> http://openser.org/cgi-bin/mailman/listinfo/users >>> >> _______________________________________________ >> Users mailing list >> Users@openser.org >> http://openser.org/cgi-bin/mailman/listinfo/users >> >> >> >> > _______________________________________________ > Users mailing list > Users@openser.org > http://openser.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-
Evan Borgström -
Klaus Darilion -
Norman Brandinger -
samuel -
T.R. Missner -
Weiter Leiter