Subject: [Sipping] 422 response with Session-Expires header.

From: [email-masked]
Date: Wed, 14 Nov 2007 16:57:30 +0530

Hi,
  I have a query related to the Session-Expires Header. Though the RFC 
4028 limits the presence of 
Session-expires to INVITE/UPDATE or 2xx of INVITE/UPDATE, my UA is 
receiving the 422 response 
with Session-expires header. Now can you please clarify which of the 
following is valid: 

1. Can I Re-try the Request in this scenario.
2. Can I make use of the Session-Expires value received in 422, or we need 
to drop this header value.
3. In case I make use of the Session-Expires values say 
   [ I receive the Session-Expires: 120 and Min-Se: 90] can I use this 120 
while I retry the Request.

Thanks and Regards,
 Preethi..
------------------------------------------------------------------------------
Preethi Sadasivan,
Software Engineer,
ARICENT ,
Bangalore.
------------------------------------------------------------------------------

***********************  Aricent-Restricted   ***********************
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of 
the individual to whom it is addressed. It may contain privileged or confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: <[email-masked]>
Date: Wed, 14 Nov 2007 17:04:40 +0530

Comments inline...

Regards, 
Nataraju A B 
________________________________

From: [email-masked]
[mailto:[email-masked]] 
Sent: Wednesday, November 14, 2007 4:58 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Sipping] 422 response with Session-Expires header.

	Hi, 
	  I have a query related to the Session-Expires Header. Though
the RFC 4028 limits the presence of 
	Session-expires to INVITE/UPDATE or 2xx of INVITE/UPDATE, my UA
is receiving the 422 response 
	with Session-expires header. Now can you please clarify which of
the following is valid: 
	
	1. Can I Re-try the Request in this scenario. 
	[ABN] yes you can retry. 
	2. Can I make use of the Session-Expires value received in 422,
or we need to drop this header value. 
	[ABN] you should drop this information... 
	3. In case I make use of the Session-Expires values say 
	   [ I receive the Session-Expires: 120 and Min-Se: 90] can I
use this 120 while I retry the Request. 
	[ABN] here Min-SE is meaningful and SE is meaning less. 
		You can refer Table 1:  in rfc.4028 for complete details
about headers and their applicability in requests/responses

	Thanks and Regards,
	Preethi..
	
------------------------------------------------------------------------
------
	Preethi Sadasivan,
	Software Engineer,
	ARICENT ,
	Bangalore.
	
------------------------------------------------------------------------
------

	***********************  Aricent-Restricted
*********************** 
		"DISCLAIMER: This message is proprietary to Aricent and
is intended solely for the use of 
	the individual to whom it is addressed. It may contain
privileged or confidential information and should not be 
	circulated or used for any purpose other than for what it is
intended. If you have received this message in error, 
	please notify the originator immediately. If you are not the
intended recipient, you are notified that you are strictly
	prohibited from using, copying, altering, or disclosing the
contents of this message. Aricent accepts no responsibility for 
	loss or damage arising from the use of the information
transmitted by this email including damage from virus."

---

From: [email-masked]
Date: Fri, 16 Nov 2007 16:09:13 +0530

Hi,
 Thank you for the prompt response, I need one more clarification 
regarding the 422 response.
I found some contradictory behavior from RFC 4028 after receiving the 422 
response.

|     INVITE  (Session-Expire: 90)  |
|  ------------------------------------------>  |
|               180             |
|  <------------------------------------------  |
|     200OK(Session-Expire: 90)         |
| < ------------------------------------------  |(Start the Session-timer)
|                         ACK                             | 
| ------------------------------------------>   |
                 .
                  .                     (Session-expires)
|     Refresh INVITE  (Session-Expire: 90)  |
|  ------------------------------------------>  |
|               180             |
|  <------------------------------------------  |
|               422             |
| < ------------------------------------------  |(Received just before the 
Expiry) 
|                                                       |

Suppose here if I receive the 422, and the UA decides to retry the INVITE 
request and mean while the 
Session-Expires and UAC knows that its peer supports the UPDATE and in 
this case here if it wishes to 
make use of UPDATE do I need to send Retry-Request (INVITE) or send the 
Refresh Request(UPDATE):
Which need to be prioritized??

10. Performing Refreshes
The side generating a refresh does so according to the UAC procedures 
defined in Section 7. 
Note that only a 2xx response to a session refresh request extends the 
session expiration. 
This means that a UA could attempt a refresh, and receive a 422 response 
with a Min-SE 
header field that contains a value much larger than the current session 
interval. 
The UA will still need to send an session refresh request before the 
session 
expiration (which has not changed), even though this request will contain 
a value of the Session-Expires that is much larger than the current 
session interval.

7.3.  Processing a 422 Response

   If the response to a session refresh request is a 422 (Session
   Interval Too Small) response message, then the UAC MAY retry the
   request.  The procedures for retrying are described in Section 7.4.
   This new request constitutes a new transaction and SHOULD have the
   same value as the Call-ID, To, and From of the previous request, but
   the CSeq should contain a new sequence number that is one higher than
   the previous.

7.4.  Generating Subsequent Session Refresh Requests

A re-INVITE generated to refresh the session is a normal re-INVITE,
and an UPDATE generated to refresh a session is a normal UPDATE.  If
a UAC knows that its peer supports the UPDATE method, it is
RECOMMENDED that UPDATE be used instead of a re-INVITE.

Thanks and Regards,
 Preethi..
tel: +91-80-41069118

<[email-masked]> 
11/14/2007 05:04 PM

To
Preethi Sadasivan/BLR/HSS@HSS, <[email-masked]>
cc

Subject
RE: [Sipping] 422 response with Session-Expires header.

Comments inline...

Regards, 
Nataraju A B 

                 Hi, 
                   I have a query related to the Session-Expires Header. 
Though
the RFC 4028 limits the presence of 
                 Session-expires to INVITE/UPDATE or 2xx of INVITE/UPDATE, 
my UA
is receiving the 422 response 
                 with Session-expires header. Now can you please clarify 
which of
the following is valid: 
 
                 1. Can I Re-try the Request in this scenario. 
                 [ABN] yes you can retry. 
                 2. Can I make use of the Session-Expires value received 
in 422,
or we need to drop this header value. 
                 [ABN] you should drop this information... 
                 3. In case I make use of the Session-Expires values say 
                    [ I receive the Session-Expires: 120 and Min-Se: 90] 
can I
use this 120 while I retry the Request. 
                 [ABN] here Min-SE is meaningful and SE is meaning less. 
                                 You can refer Table 1:  in rfc.4028 for 
complete details
about headers and their applicability in requests/responses

                 Thanks and Regards,
                 Preethi..

                 ***********************  Aricent-Restricted
*********************** 
                                 "DISCLAIMER: This message is proprietary 
to Aricent and
is intended solely for the use of 
                 the individual to whom it is addressed. It may contain
privileged or confidential information and should not be 
                 circulated or used for any purpose other than for what it 
is
intended. If you have received this message in error, 
                 please notify the originator immediately. If you are not 
the
intended recipient, you are notified that you are strictly
                 prohibited from using, copying, altering, or disclosing 
the
contents of this message. Aricent accepts no responsibility for 
                 loss or damage arising from the use of the information
transmitted by this email including damage from virus."

---

From: <[email-masked]>
Date: Fri, 16 Nov 2007 18:31:32 +0530

Comments inline..
 
Regards, 
Nataraju A B 

From: [email-masked]
[mailto:[email-masked]] 
Sent: Friday, November 16, 2007 4:09 PM
To: Nataraju Alilughatta basavaraju (WT01 - TES-Mobility & Carrier
Infrastructure)
Cc: [email-masked]
Subject: RE: [Sipping] 422 response with Session-Expires header.

	Hi, 
	 Thank you for the prompt response, I need one more
clarification regarding the 422 response. 
	I found some contradictory behavior from RFC 4028 after
receiving the 422 response. 
	
	| < ------------------------------------------        |(Start
the Session-timer) 
	|                         ACK                             |

	| ------------------------------------------>   | 
	                 . 
	                  .                     (Session-expires) 
	|     Refresh INVITE  (Session-Expire: 90)  | 
	|  ------------------------------------------>        | 
	|                    180                | 
	|  <------------------------------------------        | 
	|                     422                 | 
	| < ------------------------------------------        |(Received
just before the Expiry)         
	|                                                              |

	Suppose here if I receive the 422, and the UA decides to retry
the INVITE request and mean while the 
	Session-Expires and UAC knows that its peer supports the UPDATE
and in this case here if it wishes to 
	make use of UPDATE do I need to send Retry-Request (INVITE) or
send the Refresh Request(UPDATE): 
	Which need to be prioritized?? 
	[ABN] The scenario appear to be incorrect from UAS respect. if
interval is small, it should have replied with 422 for the initial
INVITE itself.  Also the refresher need to send the refresh request even
before Min-SE timer expires. 
	 
	The requirement is with in the Min-SE timer expiration the other
peer need to receive the refresh request. otherwise the session would be
terminated. 
	
	[ABN] if the UAS published support for UPDATE in 200-INV,
refresher can use UPDATE/re-INVITE, without any re-INVITE transaction...

	In this particular case, upon receiving the 422, the
UPDATE/re-INVITE would sent with Min-SE received in 422 response, and
session-timer duration would not be extended till 200OK for
session-refresh request received.
	
	10. Performing Refreshes 
	The side generating a refresh does so according to the UAC
procedures defined in Section 7. 
	Note that only a 2xx response to a session refresh request
extends the session expiration. 
	This means that a UA could attempt a refresh, and receive a 422
response with a Min-SE 
	header field that contains a value much larger than the current
session interval. 
	The UA will still need to send an session refresh request before
the session 
	expiration (which has not changed), even though this request
will contain 
	a value of the Session-Expires that is much larger than the
current session interval. 

	  If the response to a session refresh request is a 422 (Session
	  Interval Too Small) response message, then the UAC MAY retry
the
	  request.  The procedures for retrying are described in Section
7.4.
	  This new request constitutes a new transaction and SHOULD have
the
	  same value as the Call-ID, To, and From of the previous
request, but
	  the CSeq should contain a new sequence number that is one
higher than
	  the previous. 

	A re-INVITE generated to refresh the session is a normal
re-INVITE,
	and an UPDATE generated to refresh a session is a normal UPDATE.
If
	a UAC knows that its peer supports the UPDATE method, it is
	RECOMMENDED that UPDATE be used instead of a re-INVITE.

	Thanks and Regards,
	Preethi..

	

11/14/2007 05:04 PM 

To

	Comments inline...
	
	Regards, 
	Nataraju A B 

	                Hi, 
	                  I have a query related to the Session-Expires
Header. Though
	the RFC 4028 limits the presence of 
	                Session-expires to INVITE/UPDATE or 2xx of
INVITE/UPDATE, my UA
	is receiving the 422 response 
	                with Session-expires header. Now can you please
clarify which of
	the following is valid: 
	                
	                1. Can I Re-try the Request in this scenario. 
	                [ABN] yes you can retry. 
	                2. Can I make use of the Session-Expires value
received in 422,
	or we need to drop this header value. 
	                [ABN] you should drop this information... 
	                3. In case I make use of the Session-Expires
values say 
	                   [ I receive the Session-Expires: 120 and
Min-Se: 90] can I
	use this 120 while I retry the Request. 
	                [ABN] here Min-SE is meaningful and SE is
meaning less. 
	                                 You can refer Table 1:  in
rfc.4028 for complete details
	about headers and their applicability in requests/responses
	
	                Thanks and Regards,
	                Preethi..

	                ***********************  Aricent-Restricted
	*********************** 
	                                 "DISCLAIMER: This message is
proprietary to Aricent and
	is intended solely for the use of 
	                the individual to whom it is addressed. It may
contain
	privileged or confidential information and should not be 
	                circulated or used for any purpose other than
for what it is
	intended. If you have received this message in error, 
	                please notify the originator immediately. If you
are not the
	intended recipient, you are notified that you are strictly
	                prohibited from using, copying, altering, or
disclosing the
	contents of this message. Aricent accepts no responsibility for 
	                loss or damage arising from the use of the
information
	transmitted by this email including damage from virus."

	_______________________________________________
	Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping
	This list is for NEW development of the application of SIP
	Use [email-masked] for questions on current
sip
	Use [email-masked] for new developments of core SIP

	***********************  Aricent-Restricted
*********************** 
"DISCLAIMER: This message is proprietary to Aricent and is intended
solely for the use of 
the individual to whom it is addressed. It may contain privileged or
confidential information and should not be 
circulated or used for any purpose other than for what it is intended.
If you have received this message in error, 
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of
this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by
this email including damage from virus."

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Nov 2007 12:40:19 -0500

I don't think I fully understand what Nataraju is saying, but I think I 
don't agree.

The RFC is not as clear as it might be. Of special note is its use of 
the term "session refresh request", as if this was some special kind of 
request. It would be clearer if it instead used "request that refreshes 
the session".

The difference is that a request may both refresh the session timer and 
do other things, such as put the call on hold. A request may *cancel* a 
session timer and also possibly do other things. Every reINVITE or 
UPDATE is *either* a session (timer) refresh request or else a session 
timer cancel request.

For instance, suppose Alice calls Bob and they negotiate a session timer 
with an expiration of 10 minutes, and that Alice is negotiated to be the 
refresher. After three minutes Bob sends a reinvite to put the call on 
hold. That reinvite *will* affect the session timer one way or another. 
The possibilities are:
- it may specify Session-Expires:10. If it does, and if the request
   succeeds, then the session will be set to expire 13 minutes from the
   beginning of the original call. The refresher will also be
   renegotiated by this exchange, so it may end up being Alice or Bob.
   Alice should cancel her previously planned refresh. If she is still
   the refresher then she should schedule a new one. If she is no longer
   the refresher then she should schedule none.

- it may not specifiy Session-Expires at all. In this case, if the
   request succeeds, then the session timer is canceled. Alice should
   no longer plan to send a refresh.

Take the same initial call setup by Alice and Bob. After three minutes 
(before she was scheduled to refresh) Alice sends a reinvite to put the 
call on hold. Again this will either contain a Session-Expires or not, 
and so will either refresh the session timer or cancel it. The reinvite 
for hold has preempted the scheduled refresh request, which should be 
canceled, possibly to be replaced by another based on the new 
session-expires value.

	Paul

[email-masked] wrote:
> *Regards,*
> *Nataraju A B*
> *From:* [email-masked] 
> *Sent:* Friday, November 16, 2007 4:09 PM
> *To:* Nataraju Alilughatta basavaraju (WT01 - TES-Mobility & Carrier 
> Infrastructure)
> *Cc:* [email-masked]
> *Subject:* RE: [Sipping] 422 response with Session-Expires header.
> 
> 
>     Hi,
>     I found some contradictory behavior from RFC 4028 after receiving
>     the 422 response.
> 
>     Suppose here if I receive the 422, and the UA decides to retry the
>     INVITE request and mean while the
>     Session-Expires and UAC knows that its peer supports the UPDATE and
>     in this case here if it wishes to
>     make use of UPDATE do I need to send Retry-Request (INVITE) or send
>     the Refresh Request(UPDATE):
>     INVITE itself.  Also the refresher need to send the refresh
>     request even before Min-SE timer expires. 
>      
>     peer need to receive the refresh request. otherwise the session
>     would be terminated. 
> 
>     [ABN] if the UAS published support for UPDATE in 200-INV, refresher
>     can use UPDATE/re-INVITE, without any re-INVITE transaction... 
>      
>     UPDATE/re-INVITE would sent with Min-SE received in 422 response,
>     and session-timer duration would not be extended till 200OK for
>     Note that only a 2xx response to a session refresh request extends
>     the session expiration.
>     *The UA will still need to send an session refresh request before
>     the session *
>     *expiration (which has not changed), even though this request will
>     contain *
>     *a value of the Session-Expires that is much larger than the current
>     session interval.*
> 
> 
>       Interval Too Small) response message, then the *UAC MAY retry the
>       request.*  The procedures for retrying are described in Section 7.4.
>     *<[email-masked]>*
> 
>     11/14/2007 05:04 PM
> 
>     	
>     To

---

From: <[email-masked]>
Date: Sat, 17 Nov 2007 10:39:18 +0530

Paul, 

I agree with your comments. It clearly makes it explicit about session
refresh.

In fact, I was in the same lines, but with some complex statements
creating bit of confusion. 

Regards,
Nataraju A B

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, November 16, 2007 11:10 PM
To: Nataraju Alilughatta basavaraju (WT01 - TES-Mobility & Carrier
Infrastructure)
Cc: [email-masked]; [email-masked]
Subject: Re: [Sipping] 422 response with Session-Expires header.

	Paul

>     |     INVITE  (Session-Expire: 90)  |
and
>     make use of UPDATE do I need to send Retry-Request (INVITE) or
send
>     [ABN] if the UAS published support for UPDATE in 200-INV,
refresher
the
re-INVITE,
If
values say
Min-Se:
>     90] can I
rfc.4028
>     for complete details
contain
>                     please notify the originator immediately. If you
are
>     not the
information
***********************
>     the individual to whom it is addressed. It may contain privileged
or confidential information and should not be 
>     loss or damage arising from the use of the information transmitted
by this email including damage from virus."