[SIPForum-discussion] urgent 491

Herve Jourdain herve.jourdain at mstarsemi.com
Wed Mar 19 09:33:00 UTC 2008


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

  _____  

 
<http://cn.mail.yahoo.com/gc/index.html?entry=5&souce=mail_mailletter_taglin
e> 雅虎邮箱传递新年祝福,个性贺卡送亲朋! 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20080319/585ca22a/attachment-0008.html>


More information about the discussion mailing list