Re: [asterisk-users] SDP bug
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
Re: [asterisk-users] SDP bug
3 apr 2007 kl. 10.04 skrev kjcsb: The call that gets dropped had a retransmission of INVITE from UAC to UAS (and therefore retransmission of 200 OK from UAS to UAC). There is nothing wrong with the re-transmission as such, but I noticed a potential bug in Asterisk in the way it responds to an INVITE retransmission. Asterisk is bumping up the session version number in the retransmitted 200 OK's SDP. This is as if Asterisk is treating the INVITE retransmission as a RE-INVITE. Asterisk sends 200 OK: o=root 16300 16300 IN IP4 203.89.nnn.nnn Asterisk sends 200 OK (retransmission): o=root 16300 16301 IN IP4 203.89.nnn.nnn Ideally, this bug should have nothing to do with why Asterisk is ignoring the ACK (which is why it keeps reatrasmitting the 200 OK and eventually drops the call). However, if you can confirm that all dropped calls have INVITE retransmission then that might give us a clue? Raj, That's an interesting observation. Do you think this will cause any issues? Even though it's not beautiful, I fail to see why a UA would check that. I have run a number of tests and in all cases the calls that fail have a retransmitted INVITE whereas the successfull calls have only one INVITE. I need to see a full SIP debug to check what's going on. /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
Re: [asterisk-users] SDP bug
Olle, Regarding project Pineapple, I'm curious why rewrite (or refactor) the SIP stack instead of using an open-source one. Did your research show that there is nothing viable out there that'll fit well w/in Asterisk? OpenPBX community is talking about using Sofia-SIP stack, for instance. Raj 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. ___ --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
Re: [asterisk-users] SDP bug
5 apr 2007 kl. 13.04 skrev Raj Jain: Regarding project Pineapple, I'm curious why rewrite (or refactor) the SIP stack instead of using an open-source one. Did your research show that there is nothing viable out there that'll fit well w/in Asterisk? OpenPBX community is talking about using Sofia- SIP stack, for instance. Well, tests show that ours isn't that bad from an interoperability standpoint. Two years ago, I was convinced that it was the only way to go. I still haven't ruled it out though. I admit that there are a lot of picky stuff we don't support, but so far we interoperate with most products out there successfully. It's way better now than when I started working with chan_sip. I have been in contact with many SIP stack developers, and there are things we need to do that is hard to do without having to change their stack. And also, many stacks have incompatible licenses, which rules them out. Regardless, pineapple is much more than the lower layer stack. Check http://www.codename-pineapple.org and you will see that it's a lot about changing the concepts and how we interface SIP to the core PBX too. Due to lack of enough sponsors in the community, I have to postpone the project. Hopefully I can get it going later this year, but right now I have to focus on other projects. If there are interested sponsors out there, please send me an e-mail. /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
Re: [asterisk-users] SDP bug
2 apr 2007 kl. 19.32 skrev Raj Jain: I found a subtle difference between the two traces you sent (the call that works and the call that gets dropped). This may or may not be what's causing the problem. The call that gets dropped had a retransmission of INVITE from UAC to UAS (and therefore retransmission of 200 OK from UAS to UAC). There is nothing wrong with the re-transmission as such, but I noticed a potential bug in Asterisk in the way it responds to an INVITE retransmission. Asterisk is bumping up the session version number in the retransmitted 200 OK's SDP. This is as if Asterisk is treating the INVITE retransmission as a RE-INVITE. Asterisk sends 200 OK: o=root 16300 16300 IN IP4 203.89.nnn.nnn Asterisk sends 200 OK (retransmission): o=root 16300 16301 IN IP4 203.89.nnn.nnn Ideally, this bug should have nothing to do with why Asterisk is ignoring the ACK (which is why it keeps reatrasmitting the 200 OK and eventually drops the call). However, if you can confirm that all dropped calls have INVITE retransmission then that might give us a clue? Raj, That's an interesting observation. Do you think this will cause any issues? Even though it's not beautiful, I fail to see why a UA would check that. /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
Re: [asterisk-users] SDP bug
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. Raj Asterisk sends 200 OK: o=root 16300 16300 IN IP4 203.89.nnn.nnn Asterisk sends 200 OK (retransmission): o=root 16300 16301 IN IP4 203.89.nnn.nnn Raj, That's an interesting observation. Do you think this will cause any issues? Even though it's not beautiful, I fail to see why a UA would check that. /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 ___ --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
Re: [asterisk-users] SDP bug
The call that gets dropped had a retransmission of INVITE from UAC to UAS (and therefore retransmission of 200 OK from UAS to UAC). There is nothing wrong with the re-transmission as such, but I noticed a potential bug in Asterisk in the way it responds to an INVITE retransmission. Asterisk is bumping up the session version number in the retransmitted 200 OK's SDP. This is as if Asterisk is treating the INVITE retransmission as a RE-INVITE. Asterisk sends 200 OK: o=root 16300 16300 IN IP4 203.89.nnn.nnn Asterisk sends 200 OK (retransmission): o=root 16300 16301 IN IP4 203.89.nnn.nnn Ideally, this bug should have nothing to do with why Asterisk is ignoring the ACK (which is why it keeps reatrasmitting the 200 OK and eventually drops the call). However, if you can confirm that all dropped calls have INVITE retransmission then that might give us a clue? Raj, That's an interesting observation. Do you think this will cause any issues? Even though it's not beautiful, I fail to see why a UA would check that. I have run a number of tests and in all cases the calls that fail have a retransmitted INVITE whereas the successfull calls have only one INVITE. Regards Cameron ___ Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html ___ --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
