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

Reply via email to