<div>
<div>Olle,</div>
<div> </div>
<div>It depends on how strictly the UA adheres to the offer/answer model. The issue would be that a RE-INVITE from Asterisk will have the version number incremented by more than one, which will break the following rule.</div>
<div> </div>
<div>Quoting from RFC 3264 Section 8:</div>
<div> </div>
<div> When issuing an offer that modifies the session,<br> the "o=" line of the new SDP MUST be identical to that in the<br> previous SDP, except that the version in the origin field MUST<br> increment by one from the previous SDP.
</div>
<div> </div>
<div>That said, I agree that most UAs do not check this. What's a bit more alarming fundamentally is that Asterisk is creating a new answer SDP to respond to an INVITE retransmission. An RFC 3261 compliant implementation MUST send an exact copy of the previous SIP response. Anyway, I realize that Asterisk is not inherently RFC 3261 compliant.
</div>
<div> </div>
<div>Raj</div>
<div> </div>
<div> </div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">><br>> Asterisk sends 200 OK:<br>> o=root 16300 16300 IN IP4 203.89.nnn.nnn<br>><br>> Asterisk sends 200 OK (retransmission):
<br>> o=root 16300 16301 IN IP4 203.89.nnn.nnn<br>><br> <br>Raj,<br>That's an interesting observation. Do you think this will cause any<br>issues? Even though it's not<br>beautiful, I fail to see why a UA would check that.
<br><br>/O<br>_______________________________________________<br>--Bandwidth and Colocation provided by <a href="http://Easynews.com">Easynews.com</a> --<br><br>asterisk-users mailing list<br>To UNSUBSCRIBE or update options visit:
<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br></blockquote></div><br>