Subject: [sipcore] Need Clarification on UAS behaviour

From: "NAVEEN S-RHVG46" <[email-masked]>
Date: Thu, 8 Apr 2010 12:47:04 +0800

Hi,
 
In Section 14.2 UAS Behaviour, we have requirement stating as below
 
   A UAS that receives a second INVITE before it sends the final
   response to a first INVITE with a lower CSeq sequence number on the
   same dialog MUST return a 500 (Server Internal Error) response to the
   second INVITE and MUST include a Retry-After header field with a
   randomly chosen value of between 0 and 10 seconds.
 
Above requirement is valid when we receive INVITE, before sending 2xx
response... we are responding with 500 in our implementation...

What's the UAS behaviour ?
 
If we receive INVITE, after sending final response, before getting ACK. 

 
Regards,
Naveen

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Thu, 8 Apr 2010 13:30:37 +0800

Hi Naveen
 
The UAS should send 500 response to the INVITE - because the earlier
INVITE transaction is not yet complete. .
 
Also I feel this question is more appropriate in sip-implementors list
rather than sipcore

Regards 
Ranjit 

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of NAVEEN S-RHVG46
Sent: Thursday, April 08, 2010 10:17 AM
To: [email-masked]
Subject: [sipcore] Need Clarification on UAS behaviour

Hi,

 

 

Regards,
Naveen

---

From: [email-masked]
Date: Thu, 8 Apr 2010 15:57:53 +0800

Hi,

It depends on implementation. I know these kinds of implementation:

1. 500 + retry after;
2. Buffer the new request, and handle it after ACK;
3. Handle the new request before ACK, if there is not violation of other 
rules(such as O/A rules).

And there's one variation of the second one: Just discarding the new 
request, and handle it's retransmitting copy after ACK.

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

"NAVEEN S-RHVG46" <[email-masked]> 
发件人:  [email-masked]
2010-04-08 12:47

收件人
<[email-masked]>
抄送

主题
[sipcore] Need Clarification on UAS behaviour

Hi,

 

 

Regards,
Naveen
 _______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
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. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "NAVEEN S-RHVG46" <[email-masked]>
Date: Thu, 8 Apr 2010 16:34:52 +0800

Hi,
 
If we handle the new request before the ACK. 
 
What is the behaviour if we don't receive the ACK for the first INVITE. 
Should we close the call or should we proceed with the Re-Invite or not.
 
Regards
Naveen.S

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, April 08, 2010 1:28 PM
To: NAVEEN S-RHVG46
Cc: [email-masked]
Subject: Re: [sipcore] Need Clarification on UAS behaviour

Hi, 

1. 500 + retry after; 
2. Buffer the new request, and handle it after ACK; 
3. Handle the new request before ACK, if there is not violation of other rules(such as O/A rules). 

And there's one variation of the second one: Just discarding the new request, and handle it's retransmitting copy after ACK. 

Gao 

2010-04-08 12:47 

收件人
<[email-masked]> 
抄送
主题

Hi, 

  
Above requirement is valid when we receive INVITE, before sending 2xx response... we are responding with 500 in our implementation... 

  

Regards, 
Naveen

---

From: [email-masked]
Date: Thu, 8 Apr 2010 16:57:00 +0800

Terminate the session(call), and it is normative. As in RFC3261's 
13.3.1.4: 

If the server retransmits the 2xx response for 64*T1 seconds without
   receiving an ACK, the dialog is confirmed, but the session SHOULD be
   terminated.  This is accomplished with a BYE, as described in Section
   15.

If the UAS do retransmitting right and the UAC handle the next process 
OK(such as UAS has gotten Re-INVITE's ACK), mostly the UAS should get the 
Ini-INVITE's ACK. But if it really did not receive the Ini-INVITE's ACK, 
the UAS should terminate the call.

2010-04-08 16:34

收件人
<[email-masked]>, <[email-masked]>
抄送

主题
Re: [sipcore] Need Clarification on UAS behaviour

Hi,

 
Regards
Naveen.S

Hi, 

1. 500 + retry after; 

Gao 

收件人
<[email-masked]> 
抄送

主题

Hi, 

  

  

Regards, 
Naveen 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
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. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore