Hi,
Got a bit further with this, reason that the 200OK ( to INVITE) is being
discarded is because of this code :
static int nua_invite_client_preliminary(nua_client_request_t *cr,
int status, char const *phrase,
sip_t const *sip)
{
nua_handle_t *nh = cr->cr_owner;
nua_dialog_usage_t *du = cr->cr_usage;
nua_session_usage_t *ss = nua_dialog_usage_private(du);
assert(sip);
if (ss && sip && sip->sip_rseq) {
/* Handle 100rel responses */
sip_rseq_t *rseq = sip->sip_rseq;
/* Establish early dialog - we should fork here */
if (!nua_dialog_is_established(nh->nh_ds)) {
nta_outgoing_t *tagged;
nua_dialog_uac_route(nh, nh->nh_ds, sip, 1, 1);
nua_dialog_store_peer_info(nh, nh->nh_ds, sip);
/* Tag the INVITE request */
tagged = nta_outgoing_tagged(cr->cr_orq,
nua_client_orq_response, cr,
sip->sip_to->a_tag, sip->sip_rseq);
if (tagged) {
nta_outgoing_destroy(cr->cr_orq), cr->cr_orq = tagged;
}
else {
cr->cr_graceful = 1;
ss->ss_reason = "SIP;cause=500;text=\"Cannot Create Early Dialog\"";
}
}
When we get a 183 reliable response Sofia creates an early dialog and creates a
new tagged INVITE request
if (tagged) {
nta_outgoing_destroy(cr->cr_orq)
It looks like it marks the original request for destruction, the problem is
when a 200OK comes in with a different tag, it looks as if its matched against
the original transaction which is marked for destruction and so is discarded by
the code I posted initially in outgoing_recv in nta.c
We are handling all media (SDP) ourselves and have set PRACK to be one of the
methods our app handles. We are using the nua API.
Can Pekka or someone say whether PRACK and forking is supported with the way
we are using the Stack. We've seen some posts saying there are various bugs.
When PRACK is not used the first 200OK received is passed to the application
with cancel sent to the others. This is the behaviour we would like even when
PRACK is used. However it seems that when the first 183 reliable is received
this results in subsequent 200OK from other forks to be discarded. We just want
the first 200OK final response to be passed to our application irrespective of
which fork its from and are happy for CANCEL to be sent to others.
Any comments most appreciated.
Thanks
--- On Wed, 29/6/11, Nauman Sulaiman <[email protected]> wrote:
> From: Nauman Sulaiman <[email protected]>
> Subject: [Sofia-sip-devel] PRACK and 200 OK(INVITE) forking issue
> To: [email protected]
> Date: Wednesday, 29 June, 2011, 23:06
> Hi, using Sofia 1.12.11
>
> We have the following flow
>
>
> UAC
> UAS
> ------------------>
> INVITE
> <------------------
> 183 rel
> ------------------->
> PRACK
> <-------------------
> 200OK
>
> <-------------------
> 200 OK (different To tag to 183
> above)
>
> ------------------->
> ACK
> ------------------->
> BYE
>
>
> On the 200 OK to the Invite, if it has different To tag to
> the 183
> Sofia thinks its orphan 200 final response and discards.
> This is the code
> that causes this. This only happens when PRACK is involved.
> If the INVITE is sent without support for 100 rel all is ok
>
>
> if (orq->orq_destroyed && 200 <= status
> && status < 300) {
> if (orq->orq_uas &&
> su_strcasecmp(sip->sip_to->a_tag, orq->orq_tag) !=
> 0) {
> /* Orphan 200 Ok to INVITE. ACK
> and BYE it */
> SU_DEBUG_5(("nta: Orphan 200 Ok
> send ACK&BYE\n"));
> return nta_msg_ackbye(sa,
> msg);
> }
> return -1; /* Proxy statelessly
> (RFC3261 section 16.11) */
> }
>
>
> It looks like the orq_destroyed bit is set which is causing
> this. Is the fork of the 200OK not regarded as existing
> INVITE transaction. Any pointers
> to help solve this most appreciated.
>
> Thanks
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is
> seriously valuable.
> Why? It contains a definitive record of application
> performance, security
> threats, fraudulent activity, and more. Splunk takes this
> data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Sofia-sip-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
>
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Sofia-sip-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
