Hi All.
If I include a session-expires header using append_hf(), do I have to do anything else to my ser.cfg script?
Also, will this cause re-INVITEs to happen or is there something else needed?
Regards, Paul
On Tuesday 08 March 2005 00:52, Java Rockx wrote:
If I include a session-expires header using append_hf(), do I have to do anything else to my ser.cfg script?
Also, will this cause re-INVITEs to happen or is there something else needed?
UA's which support Session-Timer?!
Nils
Nils,
Pardon me for asking such simple questions, but is the answer for generating re-INIVITE messages to simply use SIP clients that support the header in its configuration?
Regards, Paul
On Tue, 8 Mar 2005 22:20:06 +0100, Nils Ohlmeier lists@ohlmeier.org wrote:
On Tuesday 08 March 2005 00:52, Java Rockx wrote:
If I include a session-expires header using append_hf(), do I have to do anything else to my ser.cfg script?
Also, will this cause re-INVITEs to happen or is there something else needed?
UA's which support Session-Timer?!
Nils
On Tuesday 08 March 2005 22:54, Java Rockx wrote:
Pardon me for asking such simple questions, but is the answer for generating re-INIVITE messages to simply use SIP clients that support the header in its configuration?
Both UA's have to support the Session-Timer draft, otherwise the inserted Session-Expires Header will simply be ignored and you will never see any re-INVITE's. But if both UA's support the Session-Timer they should normaly agree on using automatically by looking at the Supported header. So in my opinion there is no extra value in adding a Session-Expires header to a request at a proxy.
Nils
Regards, Paul
On Tue, 8 Mar 2005 22:20:06 +0100, Nils Ohlmeier lists@ohlmeier.org wrote:
On Tuesday 08 March 2005 00:52, Java Rockx wrote:
If I include a session-expires header using append_hf(), do I have to do anything else to my ser.cfg script?
Also, will this cause re-INVITEs to happen or is there something else needed?
UA's which support Session-Timer?!
Nils
Yes, you do need UA supporting this header.
According to section 8 of the draft, draft-ietf-sip-session-timer-14: Session timers are mostly of interest to call stateful proxy servers (that is, servers that maintain the state of calls and dialogs established through them). However, a stateful proxy server (that is, a server which is aware of transaction state, but does not retain call or dialog state) MAY also follow the rules described here. Stateless proxies MUST NOT attempt to request session timers. Proxies that ask for session timers SHOULD record-route, since they won't receive refreshes if they don't.
Here, SER is not a call stateful proxy but transaction stateful proxy. It will not maintain the state of the call. So, even if you insert the header, it will not change anything from SER's perspective.
However, if as least one of the UA support this header, you may see a BYE request, which is good for accounting. If neither UA support the header, no re-INVITE or UPDATE will be generated and that doesn't help you more than what you have at the moment.
So, until SER becomes call stateful (which is similar to B2BUA, but not the same), your best hope will be UA that support this header.
Zeus
-----Original Message----- From: serusers-bounces@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Nils Ohlmeier Sent: Wednesday, 9 March 2005 9:04 AM To: Java Rockx Cc: serusers@lists.iptel.org Subject: Re: [Serusers] Session-Expires Header
On Tuesday 08 March 2005 22:54, Java Rockx wrote:
Pardon me for asking such simple questions, but is the answer for generating re-INIVITE messages to simply use SIP clients
that support
the header in its configuration?
Both UA's have to support the Session-Timer draft, otherwise the inserted Session-Expires Header will simply be ignored and you will never see any re-INVITE's. But if both UA's support the Session-Timer they should normaly agree on using automatically by looking at the Supported header. So in my opinion there is no extra value in adding a Session-Expires header to a request at a proxy.
Nils
Regards, Paul
On Tue, 8 Mar 2005 22:20:06 +0100, Nils Ohlmeier
wrote:
On Tuesday 08 March 2005 00:52, Java Rockx wrote:
If I include a session-expires header using
append_hf(), do I have
to do anything else to my ser.cfg script?
Also, will this cause re-INVITEs to happen or is there
something
else needed?
UA's which support Session-Timer?!
Nils
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
At 12:14 AM 3/9/2005, Zeus Ng wrote:
Yes, you do need UA supporting this header.
According to section 8 of the draft, draft-ietf-sip-session-timer-14: Session timers are mostly of interest to call stateful proxy servers (that is, servers that maintain the state of calls and dialogs established through them). However, a stateful proxy server (that is, a server which is aware of transaction state, but does not retain call or dialog state) MAY also follow the rules described here. Stateless proxies MUST NOT attempt to request session timers. Proxies that ask for session timers SHOULD record-route, since they won't receive refreshes if they don't.
Here, SER is not a call stateful proxy but transaction stateful proxy. It will not maintain the state of the call. So, even if you insert the header, it will not change anything from SER's perspective.
However, if as least one of the UA support this header, you may see a BYE request, which is good for accounting. If neither UA support the header, no re-INVITE or UPDATE will be generated and that doesn't help you more than what you have at the moment.
So, until SER becomes call stateful (which is similar to B2BUA, but not the same), your best hope will be UA that support this header.
since the case you are raising is accounting accuracy, a pstn gateway is typically invoivled and it then fair to assume that >=1 UA supports ST. If not, junk the gateway :)
-jiri
Zeus Ng writes:
So, until SER becomes call stateful (which is similar to B2BUA, but not the same), your best hope will be UA that support this header.
how about using uac module for session-timer support in ser?
nils asked abut UAs supporting session timer. i think that cisco gws do support it.
-- juha
At 05:50 AM 3/9/2005, Juha Heinanen wrote:
Zeus Ng writes:
So, until SER becomes call stateful (which is similar to B2BUA, but not the same), your best hope will be UA that support this header.
how about using uac module for session-timer support in ser?
I don't think you need to do it -- you will be able to introduce it with basic textual operations. I'm currently having poor connectitivity and can't easily lookup a good config example but I do have such and will try to post later.
nils asked abut UAs supporting session timer. i think that cisco gws do support it.
indeed.
-jiri
Jiri,
Did you ever get a chance to post a good config for the session-timer?
Regards, Paul
On Wed, 09 Mar 2005 16:09:08 +0100, Jiri Kuthan jiri@iptel.org wrote:
At 05:50 AM 3/9/2005, Juha Heinanen wrote:
Zeus Ng writes:
So, until SER becomes call stateful (which is similar to B2BUA, but not the same), your best hope will be UA that support this header.
how about using uac module for session-timer support in ser?
I don't think you need to do it -- you will be able to introduce it with basic textual operations. I'm currently having poor connectitivity and can't easily lookup a good config example but I do have such and will try to post later.
nils asked abut UAs supporting session timer. i think that cisco gws do support it.
indeed.
-jiri
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
At 11:04 PM 3/8/2005, Nils Ohlmeier wrote:
On Tuesday 08 March 2005 22:54, Java Rockx wrote:
Pardon me for asking such simple questions, but is the answer for generating re-INIVITE messages to simply use SIP clients that support the header in its configuration?
Both UA's have to support the Session-Timer draft, otherwise the inserted Session-Expires Header will simply be ignored and you will never see any re-INVITE's. But if both UA's support the Session-Timer they should normaly agree on using automatically by looking at the Supported header. So in my opinion there is no extra value in adding a Session-Expires header to a request at a proxy.
That's actually not correct. It is sufficient in one UA supports ST. It is up to proxy server to handle the case correctly. We do that and there are reasonable use cases.
-jiri
Hi!
Jiri Kuthan wrote:
At 11:04 PM 3/8/2005, Nils Ohlmeier wrote:
On Tuesday 08 March 2005 22:54, Java Rockx wrote:
Pardon me for asking such simple questions, but is the answer for generating re-INIVITE messages to simply use SIP clients that support the header in its configuration?
Both UA's have to support the Session-Timer draft, otherwise the inserted Session-Expires Header will simply be ignored and you will never see any re-INVITE's. But if both UA's support the Session-Timer they should normaly agree on using automatically by looking at the Supported header. So in my opinion there is no extra value in adding a Session-Expires header to a request at a proxy.
That's actually not correct. It is sufficient in one UA supports ST. It is up to proxy server to handle the case correctly. We do that and there are reasonable use cases.
How does the proxy behave in this case? Are there any things the proxy has to do to support session timer?
klaus
On Wednesday 09 March 2005 02:17, Jiri Kuthan wrote:
At 11:04 PM 3/8/2005, Nils Ohlmeier wrote:
Both UA's have to support the Session-Timer draft, otherwise the inserted Session-Expires Header will simply be ignored and you will never see any re-INVITE's. But if both UA's support the Session-Timer they should normaly agree on using automatically by looking at the Supported header. So in my opinion there is no extra value in adding a Session-Expires header to a request at a proxy.
That's actually not correct. It is sufficient in one UA supports ST. It is up to proxy server to handle the case correctly. We do that and there are reasonable use cases.
I did not wanted to write down this special case, but I feared that someone will come up with it :-) But in this special case you will also have to watch out for the replies, if they contain a Session-Expires header. The draft gives a fairly good overview what a new SER module would have to do ;-) (although it should also be doable in the script itself).
Greetings Nils
On 09-03 11:04, Nils Ohlmeier wrote:
On Wednesday 09 March 2005 02:17, Jiri Kuthan wrote:
At 11:04 PM 3/8/2005, Nils Ohlmeier wrote:
Both UA's have to support the Session-Timer draft, otherwise the inserted Session-Expires Header will simply be ignored and you will never see any re-INVITE's. But if both UA's support the Session-Timer they should normaly agree on using automatically by looking at the Supported header. So in my opinion there is no extra value in adding a Session-Expires header to a request at a proxy.
That's actually not correct. It is sufficient in one UA supports ST. It is up to proxy server to handle the case correctly. We do that and there are reasonable use cases.
I did not wanted to write down this special case, but I feared that someone will come up with it :-) But in this special case you will also have to watch out for the replies, if they contain a Session-Expires header. The draft gives a fairly good overview what a new SER module would have to do ;-) (although it should also be doable in the script itself).
It can be done in the script, there is no need for a new module, we have been using it with cisco gateways, they do support session timer, so the proxy server inserts the headers into requests and replies.
You can test for an INVITE coming from cisco and set an onreply_route. In the onreply_route you can do something like:
if (status =~ "2[0-9][0-9]") { remove_hf("Session-Expires"); append_hf("Session-Expires: 120;refresher=UAC\r\n"); };
which "emulates" session-timer support in the user agent that sent 200 OK. After receiving such a reply, the cisco gateway would keep sending re-INVITEs.
Jan.
On Wednesday 09 March 2005 14:24, Jan Janak wrote:
On 09-03 11:04, Nils Ohlmeier wrote:
I did not wanted to write down this special case, but I feared that someone will come up with it :-) But in this special case you will also have to watch out for the replies, if they contain a Session-Expires header. The draft gives a fairly good overview what a new SER module would have to do ;-) (although it should also be doable in the script itself).
It can be done in the script, there is no need for a new module, we have been using it with cisco gateways, they do support session timer, so the proxy server inserts the headers into requests and replies.
I think in many cases new modules only add more comfortable "high level" functions, which could also be achieved by writing your own script code.
You can test for an INVITE coming from cisco and set an onreply_route. In the onreply_route you can do something like:
if (status =~ "2[0-9][0-9]") { remove_hf("Session-Expires"); append_hf("Session-Expires: 120;refresher=UAC\r\n"); };
But that is actually a vialoation of the Session-Timer draft: the proxy is not allowed to change (or add) the refresher in the Session-Expires header. Just adding a Session-Expires header to the reply, if it is not present, should be sufficient for any implementation which is fully compliant to the latest Session-Timer draft.
Greetings Nils
which "emulates" session-timer support in the user agent that sent 200 OK. After receiving such a reply, the cisco gateway would keep sending re-INVITEs.
On 09-03 14:59, Nils Ohlmeier wrote:
You can test for an INVITE coming from cisco and set an onreply_route. In the onreply_route you can do something like:
if (status =~ "2[0-9][0-9]") { remove_hf("Session-Expires"); append_hf("Session-Expires: 120;refresher=UAC\r\n"); };
But that is actually a vialoation of the Session-Timer draft: the proxy is not allowed to change (or add) the refresher in the Session-Expires header. Just adding a Session-Expires header to the reply, if it is not present, should be sufficient for any implementation which is fully compliant to the latest Session-Timer draft.
As I said this is the approach that works with cisco gateways. I have no idea what is the latest revision of the draft and I do not think it really matters here, becuase the communication between the proxy and the gateway is all internal.
This is one particular example that works with cisco, nothing less nothing more.
Jan.
Greetings Nils
which "emulates" session-timer support in the user agent that sent 200 OK. After receiving such a reply, the cisco gateway would keep sending re-INVITEs.
At 03:21 PM 3/9/2005, Jan Janak wrote:
On 09-03 14:59, Nils Ohlmeier wrote:
You can test for an INVITE coming from cisco and set an onreply_route. In the onreply_route you can do something like:
if (status =~ "2[0-9][0-9]") { remove_hf("Session-Expires"); append_hf("Session-Expires: 120;refresher=UAC\r\n"); };
But that is actually a vialoation of the Session-Timer draft: the proxy is not allowed to change (or add) the refresher in the Session-Expires header. Just adding a Session-Expires header to the reply, if it is not present, should be sufficient for any implementation which is fully compliant to the latest Session-Timer draft.
As I said this is the approach that works with cisco gateways.
Other gateway with which it is known to work is Sonus.
-jiri
At 11:04 AM 3/9/2005, Nils Ohlmeier wrote:
On Wednesday 09 March 2005 02:17, Jiri Kuthan wrote:
At 11:04 PM 3/8/2005, Nils Ohlmeier wrote:
Both UA's have to support the Session-Timer draft, otherwise the inserted Session-Expires Header will simply be ignored and you will never see any re-INVITE's. But if both UA's support the Session-Timer they should normaly agree on using automatically by looking at the Supported header. So in my opinion there is no extra value in adding a Session-Expires header to a request at a proxy.
That's actually not correct. It is sufficient in one UA supports ST. It is up to proxy server to handle the case correctly. We do that and there are reasonable use cases.
I did not wanted to write down this special case, but I feared that someone will come up with it :-)
As a matter of fact, it is actually the regular case whcih we deployed in production networks. It was just a script thing. I'm currently having difficulties accessing my home server to send out some examples but there are such.
-jiri
-
Jan Janak -
Java Rockx -
Jiri Kuthan -
Juha Heinanen -
Klaus Darilion -
Nils Ohlmeier -
Zeus Ng