[reSIProcate] Open issues for 1.3 release
Karlsson
boost.regex at gmail.com
Fri Mar 21 20:52:32 CDT 2008
You can check this at
http://list.resiprocate.org/archive/resiprocate-devel/msg06478.html
Thanks
2008/3/22, Karlsson <boost.regex at gmail.com>:
>
> Hi Byron, it's possible to adding a new fucntion for DialogSetId ?
>
> + size_t DialogSetId::hash2() const
> + {
> + return mCallId.hash();
> + }
>
>
>
> ---------------------------------------------
>
>
>
>
>
>
>
> DialogSetID is not same between onNewSession and onRefer
>
>
> Hi, I want to use the DialogSetID to identifies a Dialog.
>
> When I received a call, I do it:
>
> void UserAgent::onNewSession(ServerInviteSessionHandle h,
> InviteSession::OfferAnswerType oat, const SipMessage & msg)
> {
> DialogSetId inviteID(msg);
> long callID = (long)inviteID.hash();
> }
>
> After I answered this call, the remote side send a REFER to me:
>
> void UserAgent::onRefer(InviteSessionHandle h, ServerSubscriptionHandle
> ssh, const SipMessage& msg)
> {
> DialogSetId inviteID(msg);
> long callID = (long)inviteID.hash();
> }
>
> but these two callID do not same, the callID of onNewSession != callID of
> the onRefer, did I missed something?
>
> thanks
>
>
>
>
>
>
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
>
>
> The INVITE that you get will not have a local-tag (ie; a To-tag) in
> it. This is part of the keying info in the DialogSetId. When you
> respond to the INVITE, DUM will randomly choose a local-tag (the
> remote end needs to choose part of the keying info because of
> forking), and this local-tag will come back in the REFER, making the
> DialogSetId different. Your best bet is to just use CallId + remote-
> tag in this case (hash each, and xor the hashes, since that's what
> DialogSetId does anyway).
>
> Best regards,
> Byron Campen
>
>
>
>
>
> -------------------------------------------------------------------------
>
>
>
> Thanks
>
>
>
>
> 2008/3/22, Byron Campen <bcampen at estacado.net>:
> >
> > Here's the latest rundown:
> >
> > resip 1.3 open issues
> >
> > 2. [reSIProcate] DUM process loop crashes on TCP connection close
> > initiated by peer (still not sure what was going on here)
> > 3. [reSIProcate] outbound message decorators (maybe they're seeing
> > multiple decorator calls on DNS failover?)
> > 5. [reSIProcate] problem with local DNS server (not sure what's going
> > on here)
> > 6. [reSIProcate] Datatype Misalignment exception in resiprocate.lib
> > on a PocketPC device (not sure what is going on here)
> > 11. [reSIProcate] server subscription expires (doesn't look like
> > patch was ever applied, following up with Scott)
> > 13. [reSIProcate] Helper::advancedAuthenticateRequest() and old
> > nonces (looks like there is community support for fixing this, put
> > there is some pushback also)
> > 14. [reSIProcate-users] get version of resip (should we have a
> > function-call that indicates the version of the resip lib?)
> > 16. Tons and tons of stuff in Ruslan's b-ruslan-repro-enh-20081116
> > 17. Assert in ConnectionManager caused by reciprocal SYN.
> >
> > resolved:
> > 1. [reSIProcate] Memory leak when using Asynch challenge decision
> > (leak in ServerAuthManager, fixed in main)
> > 4. [reSIProcate] Issue with contact URI of 200 OK for OPTIONS (don't
> > think there is a problem here; contact without user-part is perfectly
> > valid)
> > 7. Need to fix sigcomp, or make it clear it isn't supported. (adam
> > has recommended disabling support in the configure script for now,
> > this has been done in main)
> > 8. [reSIProcate] Privacy header parsing (have contacted Jon, will
> > just have to wait on this)
> > 9. [reSIProcate] Blacklist result to DNS lookup causes 503 response
> > to be sent to ACK (fixed in main)
> > 10. [reSIProcate] STUN Error (someone tripping on an assert in
> > TransportSelector, fixed in main)
> > 12. [reSIProcate] Missing #include <signal.h> in resip/stack/test/
> > dumpTls.cxx (fixed in main)
> > 15. [reSIProcate-users] help with resiprocate log (logging was ok
> > after all, probably doesn't need anything)
> >
> > Best regards,
> > Byron Campen
> >
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel at resiprocate.org
> > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20080322/fb15d531/attachment.htm>
More information about the resiprocate-devel
mailing list