And also, since its not UA1's fault to not to support timers, and its between Proxy's UAC and UA2 .. I would say option (2) ( i.e. retry with another INVITE ) would be better.
Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -----Original Message----- From: Somesh S. Shanbhag Sent: Wed 2/18/2009 12:45 PM To: Radha krishna; [email protected] Subject: RE: [Sip-implementors] Sending 422 Its implementation dependent for the proxy .. I think there is absolutely no harm in proxying 422 back to UA1 because anyways UA1 would interpret it as 400, if it cannot understand. But if the proxy takes into consideration the fact that UA1 doesn't support timers, it has two choices. (1) It *may* map the 422 to something like 480 or 503 and send it back to UA1. (2) It *may* even try another INVITE to UA2 with the Session-Expires value of greater than or equal to Min-SE which you receive in 422. ( I believe Min-SE is MUST in 422 ) -Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -----Original Message----- From: Radha krishna [mailto:[email protected]] Sent: Wed 2/18/2009 12:42 PM To: Somesh S. Shanbhag; [email protected] Subject: Re: [Sip-implementors] Sending 422 Thanks somesh, it can do but in RFC section 9 explicitly says when UAS can send 422 If an incoming request contains a Supported header field with a value 'timer' and a Session Expires header field, the UAS MAY reject the INVITE request with a 422 (Session Interval Too Small) response if the session interval in the Session-Expires header field is smaller than the minimum interval defined by the UAS' local policy Regards S.Radha krishna ________________________________ From: Somesh S. Shanbhag <[email protected]> To: Radha krishna <[email protected]>; [email protected] Sent: Wednesday, February 18, 2009 12:16:31 PM Subject: RE: [Sip-implementors] Sending 422 RE: [Sip-implementors] Sending 422 Proxy can forward 422 to UA1. If UA1 doesn't understand 422, it will treat it as 400 and process it. * Please do not take print out of this e-mail unless its absolutely necessary * -----Original Message----- From: Radha krishna [mailto:[email protected]] Sent: Wed 2/18/2009 11:44 AM To: Somesh S. Shanbhag; [email protected] Subject: Re: [Sip-implementors] Sending 422 But proxy cannot forward the 422 to UA1 since it is not supporting right? Also it cannot retry with new INVITE if it is not a B2BUA. Regards S.Radha krishna ________________________________ From: Somesh S. Shanbhag <[email protected]> To: Radha krishna <[email protected]>; [email protected] Sent: Wednesday, February 18, 2009 10:27:16 AM Subject: RE: [Sip-implementors] Sending 422 RE: [Sip-implementors] Sending 422 Since the proxy is call stateful, the INVITE which goes to UA2 shall have Sesssion-Expires field and hence UA2 can reject with 422. Somesh * Please do not take print out of this e-mail unless its absolutely necessary * -----Original Message----- From: [email protected] on behalf of Radha krishna Sent: Wed 2/18/2009 8:18 AM To: [email protected] Subject: [Sip-implementors] Sending 422 Hi Consider the following topology UA1 ----- Call-stateful-proxy ------ UA2 UA1 does not support session timer, Make a call to UA2. Call-stateful-proxy adds Session-Expires:100 header and forwards to UA2. UA2 minimum session expires is 900. But in this case INVITE will not contain "support: timer". According section 9, UAS can reject with 422 only if there is a timer tag in supported header <Snip from RFC> If an incoming request contains a Supported header field with a value 'timer' and a Session Expires header field, the UAS MAY reject the INVITE request with a 422 (Session Interval Too Small) response if the session interval in the Session-Expires header field is smaller than the minimum interval defined by the UAS' local policy. When sending the 422 response, the UAS MUST include a Min-SE header field with the value of its minimum interval. This minimum interval MUST NOT be lower than 90 seconds. </Snip from RFC> Also UAS cannot increase the session expires duration <Snip from RFC> The UAS MUST NOT increase the value of the Session-Expires header field. </Snip from RFC> What should be the behavior of UAS here? 1) accept the call with 100 seconds? 2) Increase the duration to 900 seconds while sending 200 Ok? Note: Session timer should not be turned-off Regards S.Radha krishna _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ________________________________ EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. ________________________________ EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract. Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
