On 12/5/14 7:47 AM, ankur bansal wrote:
Hi
Reinvite acting as session modification request here so its behavior
should be atomic.
And reinvite failed in the end reason could be any error response or
offer answer failure.but uac should try to restore session state sending
update request to get session back in sync as recommended in rfc 6337
section 3.4.as <http://3.4.as>
In the case of reINVITE failure with rollback, both ends know that there
has been a failure, and so both can rollback to the same state.
In this case the UAC believes there has been a failure, but the UAS
thinks (mistakenly) that there has been success. So the UAS won't be
rolling back - it will retain whatever that it thinks it should now be
in. That is a formula for failure.
Certainly the UAC *could* try to recover the session by sending another
reINVITE. But at this point should it have any confidence in how that
will turn out?
i believe you didnt get any media failure
for session parameters established with pre reinvite .if there is media
failure then bye can be sent.
BYE can be sent for any reason!
Also would like to understand what made uas to send 200ok no sdp.is
<http://sdp.is> it just misbehaviour or uas sent any 183sdp before.plz
share full call flow to understand uas behaviour in better way
Yes - if there is more to the call flow then we need to see it all to
really understand.
Thanks,
Paul
On Dec 4, 2014 10:45 PM, "Paul Kyzivat" <pkyzi...@alum.mit.edu
<mailto:pkyzi...@alum.mit.edu>> wrote:
On 12/4/14 2:20 AM, Tarun2 Gupta wrote:
Hi
Our implementation is clearing the call on receiving no SDP
(answer) in 200 OK for a ReINVITE with SDP (offer) sent. Is this
(call clearing) the recommended behavior?
I am not able to find any normative RFC references to support
this. Can you please help here?
Is this a typical simple reINVITE:
-> reINVITE w/SDP (offer)
<- 200 OK without SDP
Or were there some other messages involved?
I agree that if the above is the case, then you are in an
inconsistent state relative to the other UA and it is probably hard
to continue the call.
Thanks,
Paul
_________________________________________________
Sip-implementors mailing list
sip-implement...@lists.cs.__columbia.edu
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/__mailman/listinfo/sip-__implementors
<https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
