3 apr 2007 kl. 09.07 skrev Raj Jain:
Olle,
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.
Quoting from RFC 3264 Section 8:
When issuing an offer that modifies the session,
the "o=" line of the new SDP MUST be identical to that in the
previous SDP, except that the version in the origin field MUST
increment by one from the previous SDP.
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.
Well, the whole retransmit engine is flawed in Asterisk, something I
will try to fix in pineapple, the
project I'm trying to start as a major rework of the SIp channel. See
http://www.codename-pineapple.com.
The project is stalled due to lack of funding. I have a few sponsors
- thank you! - but not enough to
dedicate my time for it.
However, this thing about the SDP seems like something that doesn't
really disturb communication today,
even though I admit we're doing it wrong. At this point, we need to
focus on fixing bugs that make
communication and interoperability impossible, after that we can fix
issues like this that are wrong,
but isn't proved to have an affect on interoperability or communication.
Gotta focus :-)
/O
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
