hi, all

I want to known if where is some progress in this forking bug. 
I met this problem too because of proxy forking, and i got a SDP from 183 
response , then a SDP in 200 OK finally response was received, 
i have to use the SDP in the finally response but sofia-sip stack does not give 
it to me 

If there is already a fix, please give me a hint , thanks

Regards,


2008-02-22 



Liang 



发件人: Pekka Pessi 
发送时间: 2008-01-11  22:20:27 
收件人: Bernhard Suttner 
抄送: sofia-sip-devel@lists.sourceforge.net 
主题: Re: [Sofia-sip-devel] Different To-Tags in Session Progress 183 and200 OK 
 
2007/12/21, Bernhard Suttner  <[EMAIL PROTECTED] >:
> 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!

I'll try to get some time for fixing the forking, I think Misha also
needs the fix...

--Pekka

> 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
>  >  >
>  >
>  >
>
>


-- 
Pekka.Pessi mail at nokia.com

-------------------------------------------------------------------------
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

<<15.gif>>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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