[SIPForum-discussion] urgent 491

Varadharajan K varadharajan.k at tcs.com
Wed Mar 19 11:16:10 UTC 2008


Hi all,

for this 491. UA1 has to send the re-invite based on the timer. The timer 
value should be conffigured based on the below strategy

ref: rfc 3261 chap 14.1
If a UAC receives a 491 response to a re-INVITE, it SHOULD start a
   timer with a value T chosen as follows:

      1. If the UAC is the owner of the Call-ID of the dialog ID
         (meaning it generated the value), T has a randomly chosen value
         between 2.1 and 4 seconds in units of 10 ms.

      2. If the UAC is not the owner of the Call-ID of the dialog ID, T
         has a randomly chosen value of between 0 and 2 seconds in units
         of 10 ms.

   When the timer fires, the UAC SHOULD attempt the re-INVITE once more,
   if it still desires for that session modification to take place.

Thanks,
Varadharajan Krishnamurthy
Tata Consultancy Services
Tidel Park, 11th Floor - A,
BlockNo. 4, Canal Bank Road,
Taramani,
Chennai - 600 113,Tamil Nadu
India
Mailto: varadharajan.k at tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Outsourcing
____________________________________________



"Herve Jourdain" <herve.jourdain at mstarsemi.com> 
Sent by: discussion-bounces at sipforum.org
03/19/2008 03:03 PM

To
"'Roy, Nishant Kishore'" <nishantkr at hp.com>, '雨 陈' 
<chen.yu26 at yahoo.com.cn>, "'group SIP'" <discussion at sipforum.org>
cc

Subject
Re: [SIPForum-discussion] urgent 491






Hi,
 
I agree with most points.
Just for the retransmission after receiving the 491, it’s optional 
(SHOULD), so there is no impact  if it’s not retransmitted…
So if UA fails to retransmit, I don’t think 500 needs to be sent by the 
stack.
 
Regards,
 
Herve
 

From: Roy, Nishant Kishore [mailto:nishantkr at hp.com] 
Sent: mercredi 19 mars 2008 08:33
To: 雨 陈; group SIP; Jourdain Herve
Subject: RE: [SIPForum-discussion] urgent 491
 
Hi all ,
 
here is answer for your question 
 
1) 
the failure of the re-INVITE does not
cause the existing call to fail - the session continues using the 
previously negotiated characteristics so here  NO.2639 INVITE still belong 
to the call flow .......
ref: rfc 3261 chap 14
2) existed session shoud not get terminated ...when ever the UA gets a 491 
for the re-INVITE it start a timer for sending another re-INVITE after 
some time ... the way of having choice u can a look at rfc
ref: rfc 3261 chap 14
its like modification on existing session.. if modification fails means it 
will continue with the existing one .... it is not going to terminate that
"In fact, the RFC3621 have just mentioned the UAC should start a timer 
when it received a 491 response, but not described what will happen, if 
the timer fires and the UAC don’t attempt the re-INVITE once more." 
for this as we see  its a SHOULD condition so in my opinion UA should 
re-transmit the INVITE generally similar behaviour we can observe in the 
session refresh INVITE .... and if UA fails to re-transmit 500 server 
internal error need to send by the stack 
 
 
regards
 Nishant kishore roy 
 
 
 
 

From: discussion-bounces at sipforum.org 
[mailto:discussion-bounces at sipforum.org] On Behalf Of ? ?
Sent: Wednesday, March 19, 2008 12:19 PM
To: group SIP; Jourdain Herve
Subject: [SIPForum-discussion] urgent 491
Hi, Herve and all,
Now I am recording the SIP call flowing, but there is a  problem about the 
response 491 .
The call flowing as follows:
UA1                        UA2     TIME
 
             Both way RTP Media
?==========================è 
[254]INVITE[SDP] 
?--------------------------     09:18:31:052
[255]INVITE[SDP] 
----------------------------è   09:18:31:065
    [256]100
----------------------------è   09:18:31:065
    [257]491
----------------------------è   09:18:31:065
    [259]100
?-------------------------------------       09:18:31:071
    [260]491
?-------------------------------------       09:18:31:071
                    [261] ACK
?----------------------------   09:18:31:071
                    [263]ACK
-----------------------------è   09:18:31:085
          [2639] INVITE [SDP]
---------------------------------------è      09:19:01:092
…………
As we can see, the session has already set up and the entire message in 
this flow have the same dialog-ID. Now both UA1 and UA2 re-invite each 
other just simultaneously, then they get 491 as response from the other 
one. Well, after 30s, the UA1 send a INVITE again which is NO.2639 with 
SDP. My question is :
1.       Since no relevant message during the 30s space time, does the 
NO.2639 INVITE still belong to the call flow ?
2.       Is the response 491 like 487, which means the existed session 
will be terminated? 
 
In fact, the RFC3621 have just mentioned the UAC should start a timer when 
it received a 491 response, but not described what will happen, if the 
timer fires and the UAC don’t attempt the re-INVITE once more.
 
I look forward to the answer urgently,anything is helpful !
 
RE
 
Nora

雅虎邮箱传递新年祝福,个性贺卡送亲朋! 
_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit 
http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org

ForwardSourceID:NT0000342E 

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20080319/2dea87af/attachment-0014.html>


More information about the discussion mailing list