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

Reply via email to