[SIPForum-discussion] What happen in this scenario?

[Sumeet Bhardwaj]

Hi,

I think, B2BUA is special kind of USC/UAS. Expire header is not a mandatory parameter. It will depend on the design of B2BUA to use the Expire header field. If it is getting use then it should follow according to the answers mentioned below by Karthic. It is not expected from other entity to send the value as zero and if it's happened then B2BUA should behave as per the RFC.

Thanks
-Sumeet

From: discussion-bounces at sipforum.org [mailto:discussion-bounces at sipforum.org] On Behalf Of JEEVANANDHAM KARTHIC KUMAR
Sent: Friday, January 22, 2010 12:08 PM
To: lakhan patel
Cc: discussion at sipforum.org
Subject: Re: [SIPForum-discussion] What happen in this scenario?

Hi ,

Please find my answer inline.

Thanks
Karthic kumar J

________________________________
From: discussion-bounces at sipforum.org [mailto:discussion-bounces at sipforum.org] On Behalf Of lakhan patel
Sent: Wednesday, January 20, 2010 9:13 PM
To: discussion at sipforum.org
Subject: [SIPForum-discussion] What happen in this scenario?
Hi All,

SIDE-A                  B2BUA                  SIDE-B
   |                             |                             |
   |        INVITE           |                             |
   |--------------------------->|(with Expire=0)       |
   |     100 Trying         |                             |
   |<---------------------------|                             |
   |                             |                             |


My questions are:

1. Is the B2BUA respond with "487 Request terminated"?
[karthic]YES
2. If YES/NO then why? Please give me the explanation.
[karthic]In RFC3261 section  13.3.1 Processing of the INVITE, explains.
  "--
    1. If the request is an INVITE that contains an Expires header
         field, the UAS core sets a timer for the number of seconds
         indicated in the header field value.  When the timer fires, the
         invitation is considered to be expired.  If the invitation
         expires before the UAS has generated a final response, a 487
         (Request Terminated) response SHOULD be generated.
--"
 According to this statement, It is valid to reject INVITE by 487.

3. How Expire header works in this case?
[karthic]In my point of view, there is no sense in setting value in Expire header.
 It seems not compliant to RFC321 section 20.19 Expires
" The value of this field is an integral number of seconds (in decimal)
   between 0 and (2**32)-1, measured from the receipt of the request".

So "0" is not valid for Expire header.
 I too expecting that why such a case exist. Is it a some test case? Is any product behaving like that
4. How the Timers and Expire header are related?
[karthic]Ref. question 2
5. Does the B2BUA ignore the Expire Header in INVITE?
[karthic] Instead of ignoring, I feel it is better to reject by 487 to compliant with RFC.
But it is up to your local policy/requirement to make decision.


--
Thanks & Regards
Shivlakhan Patel
Email: lakhan.p at gmail.com<mailto:lakhan.p at gmail.com>, lakhan.p at hotmail.com<mailto:lakhan.p at hotmail.com>
IBM India Private Ltd. Bangalore
Contact: +91-9902791177



--
Thanks & Regards
Shivlakhan Patel
Email: lakhan.p at gmail.com<mailto:lakhan.p at gmail.com>, lakhan.p at hotmail.com<mailto:lakhan.p at hotmail.com>
IBM India Private Ltd. Bangalore
Contact: +91-9902791177

DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20100125/fe7cbd7e/attachment-0002.html>