GitLab

darcs-hash:20070919173214-65a35-38c445b5eb19a369f3ed0068ce2a62498e106a68.gz

darcs-hash:20070919172950-65a35-a615d7ceeb0e83266c8c8bd28424b6c4fb3b422e.gz

darcs-hash:20070919165001-65a35-b33bb671ea8969de929d5d26a74e698a17c17d6e.gz

darcs-hash:20070917185028-65a35-71d49fa2ce9c84ce6816c773c72662bfc9df6da1.gz

darcs-hash:20070917185018-65a35-e9ceb29b6843795a157336af374831164b083237.gz

darcs-hash:20070917185004-65a35-7b31a22d9c45917dc8799e20bd30cff3ddd6d6f0.gz

darcs-hash:20070919144814-65a35-edfc6565ce30d6de42efad913bd19487c01797d9.gz

Thanks for Martin Drasar for hunting down the bug.

darcs-hash:20070919142853-65a35-00b019aa0775201b0ce8a8a53432b47144281400.gz

darcs-hash:20070919142729-65a35-e6bf5e6145af7b745c0d6230126386f9096c48a9.gz

Thanks for Russell McConnachie for reporting this problem.

darcs-hash:20070919131923-65a35-f87664357b6970425cd25e073cd3d5d557b44454.gz

darcs-hash:20070917201851-65a35-d382f8819061268743b4447641bd16554bfd0a61.gz

Sheesh.

darcs-hash:20070917142756-65a35-309275d5d126a0b11dc1a0313c4d02bbb6c7c3e5.gz

darcs-hash:20070917141600-65a35-867c1a061fc13d90df55e7f411115dc6a536f0f9.gz

Added tags NUTAG_INITIAL_ROUTE() and NUTAG_INITIAL_ROUTE_STR() that can be
used to determine the route set included in the request initiating dialogs
or outside them. They can be used instead or in addition to the
NUTAG_PROXY() when determining the outbound proxy.

The URL in NUTAG_PROXY() is not added to the requests, and it affects all
the requests, including in-dialog requests. The route set in
NUTAG_INITIAL_ROUTE{_STR}() is explictly added to the requests and it is
visible in the requests, and it affects only routing of the initial
requests.

TODO: interaction with service route set returned by registrar in the
Service-Route header.

darcs-hash:20070917141542-65a35-b7e7a38d4fbcc86ed156bfe5e353d91b37a8588d.gz

Used by external tags containing SIP header objects.

darcs-hash:20070917140829-65a35-1cc62133ad41244afde4f85f8a4e305b9183df1d.gz

Updated gruu parameter (now pub-gruu). Should figure out when to use
temp-gruu.

darcs-hash:20070917115427-65a35-fdbf3f27f2fbe1660f60229725600129a9a3cf19.gz

the Via header parameters suggest otherwise in nua_handle_contact_by_via().

darcs-hash:20070914160610-5b6ca-620ea19342aed9689a63a2387fb1580ccf8afb3b.gz

darcs-hash:20060504193836-65a35-c2e214d4a95069a395db6806158b14dec78ecfe6.gz

darcs-hash:20070913134752-65a35-fed28f0d2a3e53bc5b96e643b28faaed92021f0e.gz

darcs-hash:20070913134725-65a35-9edacf7a24bede48aa76221def6b873d4d041b0f.gz

darcs-hash:20070913134422-65a35-2d85f89f2931f95c48c192bd56269c8b256adafc.gz

darcs-hash:20070906142337-65a35-819b9e4cb2843ec60402402ce7b7de25113dbe85.gz

Save the Contact header which the application has added to the target
refresh requests or responses and use the saved contact in subsequent target
refresh requests or responses.

Previously the application had no way of specifying the Contact included in
the automatic responses to target refresh requests.

Thanks for Anthony Minessale for reporting this problem.

darcs-hash:20070910162753-65a35-5d7e4b1312164aa849546b360079b74c5b58cb87.gz

darcs-hash:20070906211318-65a35-8a651a1e8cdea88224f8e542efdee2159fe3e8d3.gz

darcs-hash:20070906175648-65a35-1c55281562bb1916598b853219e89b381cee0d79.gz

darcs-hash:20070906163353-65a35-bf7c9c864d5bd2d4c6409b09401b05af7df61d1f.gz

darcs-hash:20070906162304-65a35-712ed6451447aaa74a990655a0b31bca27ee7916.gz

darcs-hash:20070906161920-65a35-50c5184d893d57246ff66e37897266413c9dbee3.gz

darcs-hash:20070906161503-65a35-d91113bf02b8afdb7b94bf485b434e037c30378e.gz

darcs-hash:20070906160125-65a35-507322edb7907b488832d65891263465a27519c2.gz

darcs-hash:20070723205948-65a35-9f05bad048c4a75556483ba838880df5bdb4294e.gz

darcs-hash:20070723205948-65a35-b1087fa43f5773dfffef1380df26ca13b2926ac2.gz

darcs-hash:20070906175304-65a35-0e1c3e85dcde849f53c67adea73d39fb96b979f9.gz

darcs-hash:20070906100250-5b6ca-9a6b02ae6bdd1c70e8d73fb58ebc0698436b1d27.gz

darcs-hash:20070906150519-65a35-6e6aab20b50be79278780d826d8ce8389c9ada62.gz

C is now challenged every time.

darcs-hash:20070725164357-65a35-ff1a6a123263ba7e3cd93805315c5b0ecf4783a3.gz

darcs-hash:20070725164833-65a35-1cb6607a660a41cdfc3bb12f8eb949dc003fd047.gz

darcs-hash:20070725164251-65a35-ea48adb350c2de048816d9c06b5bbee3bd38dd1d.gz

darcs-hash:20070725162246-65a35-2a22a4db55b8efd7431397256c5fc857ee59c881.gz

Delay sending ACK and subsequent transition of call to the ready state when
the 200 OK response to the INVITE is received if the SDP Offer/Answer
exchange using UPDATE/PRACK was still incomplete.

Previously, if the O/A using UPDATE or PRACK was incomplete and an 200 OK
was received, the call setup logic regarded this as a fatal error and
terminated the call.

Thanks for Mike Jerris for detecting and reporting this bug.

darcs-hash:20070723152956-65a35-36d194e38ec4ded0f20342489d55f2ab5594e2a5.gz