Yeah, without 100rel it does work without a problem. Is it possible to fix this bug in the near future? If you require more informations to fix this bug I will help you of course!
Am Freitag, den 21.12.2007, 15:06 +0200 schrieb Pekka Pessi: > 2007/12/14, Bernhard Suttner <[EMAIL PROTECTED]>: > > I try to do my best and look after this bug. But I have a another > > question to the structure of sofia sip. > > > > The situation doesn't changed: > > > > NUA Application calls Alice over Broadworks PBX. > > > > The question is, in which function does NUA/NTA add the To Tag to the > > orq->orq_to->a_tag function if > > - the Broadworks does send us a 183 with SDP > > - we get only a SDP in the 200 OK final response. > > > > Would it be possible to delete the To Tag of the 183 SDP in the orq > > structure if we get a different To Tag in the 200 OK or how can I solve > > this bug? > > Well, I think the problem is with the way nua/nta handles 100rel > responses (I assume 183 is indeed a 100rel response). > > You could get away with a case if the PBX did not require 100rel. > > > I dont know if this is a problem with all forked calls, but I think it > > is interessting for the sofia-sip project - so I would be very pleased > > if someone can give me some hints. > > The problem is with the 100rel calls only (or so I hope). > > --Pekka > > > > Am Freitag, den 07.12.2007, 16:07 +0100 schrieb Bernhard Suttner: > > > Can nobody help or give a hint? > > > > > > > > > Am Mittwoch, den 05.12.2007, 09:54 +0100 schrieb Bernhard Suttner: > > > > Hi, > > > > > > > > I have a problem with two different two tags. The application is a NUA > > > > client (Version 1.12.7) which will have a registration on a broadworks > > > > PBX. The scenario is as follows: > > > > > > > > NUA-Application --------> Broadworks PBX ----> Alice > > > > > > > > NUA Application is registered on the Broadworks PBX and calls Alice. On > > > > the Broadworks PBX it is configured that a Custom Ringback is played to > > > > the caller of Alice. Therefore the Broadworks PBX does send a Session > > > > Progress (183) to the NUA Application with SDP (= Media server). The > > > > To-Tag is set to 2126846201-1196843105609 by the Broadworks PBX. > > > > NUA-Application get the SDP and the custom ringback without any trouble. > > > > Alice is ringing. Then Alice accept the call. The PBX sends a 200 OK to > > > > NUA-Application with a different SDP (= Alice) BUT the 200 OK does have > > > > a different To-Tag (241898411-1196843111396). The NUA-Application > > > > doesn't accept the 200 OK because of the different To-Tag. The FROM Tag > > > > and the Call-ID are identical. The inbound call from Alice to > > > > NUA-Application works fine. > > > > > > > > If I set the debug options I get: > > > > nta: 200 OK was discarded. > > > > > > > > In the nta.c source code I have found the line which will fail: else if > > > > (a->a_tag && b->a_tag) (in function addr_match). Therefore the function > > > > will return FALSE and the outgoing_find function will continue with the > > > > next item in the outgong_htable_hash. > > > > > > > > I think it is a Sofia SIP bug but I am not sure. Some documents explains > > > > this behavior, too: > > > > > > > > https://lists.cs.columbia.edu/pipermail/sip-implementors/2007-August/017350.html > > > > http://www1.ietf.org/mail-archive/web/sipping/current/msg12390.html > > > > http://bugs.digium.com/view.php?id=5166 > > > > > > > > > > > > Can someone give me some hints or suggestions? > > > > > > > > Best regards, > > > > Bernhard Suttner > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > > > > SF.Net email is sponsored by: The Future of Linux Business White Paper > > > > from Novell. From the desktop to the data center, Linux is going > > > > mainstream. Let it simplify your IT future. > > > > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > > > > _______________________________________________ > > > > Sofia-sip-devel mailing list > > > > Sofia-sip-devel@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel > > > > > > > > > ------------------------------------------------------------------------- > > > SF.Net email is sponsored by: > > > Check out the new SourceForge.net Marketplace. > > > It's the best place to buy or sell services for > > > just about anything Open Source. > > > http://sourceforge.net/services/buy/index.php > > > _______________________________________________ > > > Sofia-sip-devel mailing list > > > Sofia-sip-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel > > > > > > ------------------------------------------------------------------------- > > SF.Net email is sponsored by: > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services > > for just about anything Open Source. > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > _______________________________________________ > > Sofia-sip-devel mailing list > > Sofia-sip-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel > > > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel