Thanks for your responese:
2007/11/7, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > 1) Sip spiral: > > > > Asterisk chan_sip doesn't allow SIP spiral (not a loop). This is: > > > > - Asterisk calls a user of a SIP proxy. > > - This SIP proxy has a forwarding for this user that correspond with a PSTN > > number, so the INVITE is URI modified and sent back to Asterisk (the PSTN > > gateway). > > - Asterisk receives the same INVITE it sent before (same fromt and to tags > > and > > call-id, but different URI so NOT the same INVITE) and rejects it with "482 > > Loop Detected". > > > > This is a pain since it could be a really cool feature that Asterisk makes > > impossible. > > > > There is a related bug and patch not accepted and updated to trunk version: > > http://bugs.digium.com/view.php?id=7403 > > > > Since Callweaver uses Sofia SIP I hope this stack understands "482" and > > accept > > SIP spiral. Does it? > > Why don't you send Asterisk instead a 3xx message say a 302 moved > temporarily? A forwarding doesn't need to be a 3XX redirect. RFC 3261 talks clear about the difference between Loop and spiral, it's a problem of Asterisk/CallWeaver if they detect spiral as loop. More people is interesting in this issue so it seems important. In fact, in my case is not possible to receive a 3XX. A forwarding can be done in parallel, for example: - User [EMAIL PROTECTED] has a parallel forwarding in its OpenSer to [EMAIL PROTECTED] - asterisk.domain is an Asterisk uses as PSTN gateway (incoming and outgoing calls). - Asterisk receives an incoming call and the dialplan calls to [EMAIL PROTECTED] - OpenSer does a parallel forking calling to [EMAIL PROTECTED] and [EMAIL PROTECTED] - This second branch returns to Asterisk to go to PSTN. This INVITE has different URI (so it's not a Loop). - Asterisk rejects because "Loop detected" ¿?¿ > > > 2) Native transfer and direct RTP: > > > > Asterisk allows native transfer with options "t" and/or "T" in "Dial" > > command. > > This native transfer is done by DTMF and Asterisk remains in the media path > > in order to get those DTMF's even if "canreinvite=yes" for both callee and > > callee. > > > > But using "dtmfmode=info" the DTMF goes as SIP INFO messages (not in the > > RTP) > > so there is no reason Asterisk to remain into the media path. Anyway > > Asterisk > > remains in it :( > > > > Reported bug in Asterisk: > > http://bugs.digium.com/view.php?id=11172 > > (I reported it today and it seems fixed now !!!) > > I don't like native transfers and anyways I disagree with your logic. I neither like native transfer, sure, but many SIP devices can't do attended transfer, or have a buggy SIP transfer implementation. Anyway, in which points of my logic do you disagree? > > > > 3) Multidomain support - Virtual hosts: > > > > Asterisk support for multidomain is really limited, just by asignig context > > to > > incoming calls based on the domain, no more. > > > > Is there more about it in CallWeaver? > > > > Do your multi-domain support in SER Yes, I use OpenSer in multidomain, but I need an Asterisk/Callweaver for each domain because Asterisk/Callweaver don't allow multidomain (playing too much with context as "domains" in not very secure at all). > > 5) Support for outbound proxy in [general]: > > > > Asterisk doesn't allow using a outbound proxy for ALL outgoing calls, just > > for > > peers. Does CallWeaver allow it? > I was not aware, please explain. Imagine I want ALL the SIP outgoing calls from Asterisk go through an OpenSer. It could be great an option in sip.conf [general]: outboundproxy: openser.domain.com but this option just exist inside of a peer, not in "general". > > 6) Big vulnerability with native transfer: > > Explained here: > > http://bugs.digium.com/view.php?id=10198 > > > Native transfer is a hack. It behaves like a hack, doesn't it? Yes, it's ;) Best regards. -- Iñaki Baz Castillo <[EMAIL PROTECTED]> _______________________________________________ Callweaver-users mailing list [email protected] http://lists.callweaver.org/mailman/listinfo/callweaver-users
