Hi, RFC 6141 updates RFC 3261 and addresses some of the re-INVITE failure handling ambiguities. However, I'm not sure if it specifically addresses the topic.
RFC 3261 section 14.1: "If a UA receives a non-2xx final response to a re-INVITE, the session parameters MUST remain unchanged, as if no re-INVITE had been issued." > -----Original Message----- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > implementors-boun...@lists.cs.columbia.edu] On Behalf Of Andrea Rizzi > Sent: Tuesday, September 15, 2015 5:40 AM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] m lines after after SDP offer/answer exchange > failure > > Let’sassume a session is in place, established through an offer/answer > exchange witha single media stream (i.e. a single m line). > > Then, theUAC A sends a reINVITE containing an SDP offer having two m > lines, > and theoffer is rejected by the UAS B (let say with a 488). > > Thequestion is about the number of m lines needed in the following SDP > offer. According to RFC3264: > > ‘’ If anSDP is offered, which is different from the previous SDP, the > > new SDP MUST have a matching media stream for each media stream in > > the previous SDP. In other words, if the previous SDP had N"m=" > > lines, the new SDP MUST have at least N "m=" lines ‘’ > > From the Bperspective, it may be considered allowed sending a single m > line, > as it neversent two m lines nor it accepted them. From the A perspective, > RFC3264 says itshould send two m lines. A, on the other hand, should be > ready > also to accept asingle m line. > > The RFC isclear in case of successful O/A exchange, but not so much in > case > of failure. > > Any opinionor fact about? > > Andrea _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors