On Sat, 2004-02-21 at 11:48, Olle E. Johansson wrote: > canreinvite has yes|no|update as keywords. > with UPDATE a SIP method UPDATE is initiated to change the media path. > with YES, a new INVITE is issued within the current call. (a "re-invite") > with NO, the call stays within asterisk.
Any ideas on when UPDATE would be better than the standard re-invite? > >>>callerid= ; U- caller id of the user: "Name <number>". > >>Have to check this one. Been working a bit on this problem in the > >>chan_sip2 channel. > > I have submitted two bug reports. One includes a patch to chan_sip.c that > > fixes the problem. See: > > http://bugs.digium.com/bug_view_page.php?bug_id=0001074 > > Another is about CALLERIDNUM. This variable seems to strip the dots from > > the domain without practical reason (also SetCIDNum and the like do this). > > See: > > http://bugs.digium.com/bug_view_page.php?bug_id=0001075 > I'll add comments to the bug reports. We really need to think about how > we steer the SIP channel forward. Asterisk is a multi-protocol PBX, so > there's no sense in making the SIP channel a stand-alone SIP proxy that > doesn't work with the rest of the PBX. If you don't want a PBX in the core > of your SIP network, use a SIP proxy there and use Asterisk where it fits > in. This way of reasoning means there are things that will never happen in > the Asterisk SIP channel because of the multi-protocol architecture. We need > to be clear on that while moving the channel forward. Could different options be used in different channels? i.e. if the SIP user is calling a Zap channel, then you'd use only standard numerical CallerIDs. However, if the SIP user is calling another SIP user, then these new patches would kick in & you'd be able to have full SIP URLs viewable :) > Having said that, > there's a lot of things to do to make the SIP client and server within > Asterisk more compliant and functional with the rest of the SIP world. Yes, please :) > I do want Asterisk to be in the forefront in preventing > use of Asterisk as a open SIP spam relay to use mail terms. Mail servers are > picky of which domains they server for inbound and outbound messages, in some > cases also on what domain is used for outbound messages. We need to have > configuration that follows this line of thinking for SIP. If someone is using > our domain for outbound calls - authenticate. If someone is randomly placing > calls to extensions in any domain they invent *into* our PBX, don't answer. This is good thinking - the idea of VoIP spam fills one with horror! > >>As I stated earlier, I'm highly suspicious to the "in order of > >>preference" > >>part. Since I got no comments or replies on that mail, I suspect I'm > >>right > >>:-) > > What do you mean? Is the order of preference not working? > I've checked into this since no one else bothered... :-) > Allow/deny codecs in the [general] section have an order of preference, it is > correct. Allow/deny codecs for peers/users have no order of preference, it's > just a matrix of codecs we can use for calling them. This looks like a BUG to me! Is it only evident in the SIP channel, or in others (such as IAX) as well? I can't find it in the BugTracker - is it there? Sounds easy to fix, but that's easy for me to say, since I'm not a coder ;) > > A new question: > > Is chan_sip2 ready for production? > I'm using it in my production servers, but I wouldn't recommend it to anyone else > for more than testing at this time. > It's beta and I'm adding new stuff constantly, propably new bugs as well. > Have got some very useful feedback (thank you, Fran!) but need much more from > testers. > It adds a lot of features, like templates and MYSQL authentication. Adding features > is dangerous without testing, so please help me test this little creature. I'm testing Asterisk in a SIP-only environment using this version of the channel. I don't yet run a full Production system, but test this with X-Lite, ATAs & 7960s....works great so far :) F _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
