On 10/29/13 11:39 AM, Sourav Dhar Chaudhuri wrote: > Hi, > Thanks for your response. > > In this case UAS has received UPDATE request before receiving the ACK > for the INVITE. > > > In my case UAS is not sending any response for that UPDATE.
That is totally wrong. Every request must get a final response. > So my question is that What will be the response for this UPDATE? I have > found one testcase in the link > https://www.cisco.com/en/US/docs/ios-xml/ios/voice/sip/configuration/15-mt/voi-sip-rfc.html#GUID-0C33CD1F-D738-481D-BC59-34A782986D4A This is just Cisco's opinion. > I have not found any supported link in any RFC the behavior mentioned in > that link. > > > Error Responses to UPDATE Request Processing Before the Call Is Active There is no error! So you shouldn't be looking for an error response. I'm not sure what "Call Is Active" means above. But UPDATE *can* be used before the call is *answered*. (But not in this case. It can be used to send a subsequent offer once an answer has been received in a reliable provisional response.) You already sent a 200 response to an identical offer earlier. So I presume it is still acceptable to you. So you should probably be sending a 200 response. What you put in the answer is up to you. The most obvious is to include the same answer you did before. But you may answer differently if you wish. > In other scenarios, additional rules apply to processing an UPDATE request > with an offer when the gateway has sent a 200 OK response to an INVITE > request but has not yet received an ACK. The following scenarios generate an > error response and are shown in the figure below: > * If the initial INVITE request contains an offer but does not require > provisional responses be sent reliably, then the SDP in the 200 OK is treated > like an answer. If the UAS then receives an UPDATE request before an ACK > response to the 200 OK, the UAS sends a 500 Server Internal error response > with a Retry-After header. You certainly MAY do this if you wish. > * If the initial INVITE does not contain an offer and does not require > provisional responses be sent reliably, then the SDP in the 200 OK is treated > like an offer. If the UAS then receives an UPDATE request before receiving an > ACK to the 200 OK, the UAS sends a 491 Request Pending response. This doesn't apply to the case you have described. > Figure 5. Error Cases for UPDATE Requests > > > > > > Due to that UAC is retransmitting UPDATE continuously and finally it is > terminating the dialog on not receiving any final response that UPDATE. This > is as per RFC 3311. Of course the UAC is retransmitting the UPDATE, since you haven't responded to it. Do you receive the ACK somewhere in here? (If you don't then the UAC is probably broken.) Thanks, Paul > On Tuesday, 29 October 2013 7:53 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> > wrote: > > On 10/29/13 9:55 AM, Sourav Dhar Chaudhuri wrote: >> Hi, >> I need the expected response for the Call scenario mentioned below >> >> 1) UAC sends INVITE request with SDP >> >> 2) UAS sends 180 ringing to UAC >> >> 3) Then UAS sends 200 OK fo with SDP response INVITE . >> >> 4) Now after receiving 200 OK response by UAC. it generates UPDATE request >> with same SDP mentioned in STEP 1 towards UAS. Is it a valid behavior? >> >> 5) Now what should be the response from UAS for that UPDATE request ?? >> >> After sending the UPDATE request UAC has also also ACK request for 200 >> OK response. > > The UAS is receiving the UPDATE before the ACK? > > The UPDATE seems silly, but not *wrong*. > > The UAS receiving the UPDATE before the ACK isn't proof that they were > sent in that order. And even if they were it isn't really wrong as long > as the ACK is sent in a timely way. > > As far as what the UAS should respond, this is a new offer. All the same > rules apply as if it were sent long after the INVITE transaction completed. > > Thanks, > Paul > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
