To header tag missing in ACK

[janasle]

Hi all,

I've been trying to create a servlet which operates in both uas and
uac mode. When operating as uas, everything works as expected and I'm
able to receive calls. However, when operating in uac mode I see some
strange behavior when trying to ACK the call.
Every now and then it seems like the sip session haven't been
updated(?) to include the To tag when I try to send my ACK. Hence, the
callee won't accept the call as connected.

Here's some pseudo code showing how I create the invite, handle the
response and create the ack:

createInvite() {
appSession = sipFactory.createApplicationSession();
invite = sipFactory.createRequest(appSession, "INVITE", from,
to);
}

doSuccessResponse(){
if (method == "INVITE")
storeResponseInAppSession();
sendNotificationToSubsystemAndReturn();
}

onReadyToAckFromSubsystem() {
getResponseFromAppSession();
response.createAck().send();
}

Any ideas on what might be going wrong?

The logs tell me that the To tag is in fact included in every 200 OK I
receive from my test client. I would guess about 4 out of 10 ACKs fail
to include the To tag.

Thanks,
Jan Asle

[Thomas]

Hi Jan Asle,

There has been a fix on a similar issue. Do you have the possibility to test with the latest version from the trunk ?

Regards,

Thomas

> --
> You received this message because you are subscribed to the Google Groups "cipango-users" group.
> To post to this group, send email to cipang...@googlegroups.com.
> To unsubscribe from this group, send email to cipango-user...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cipango-users?hl=en.
>

[Jan Asle Kroknes]

Cool!

I'll give it a shot tomorrow.

Thanks,
Jan Asle

[Thomas]

Ok, great. If not better, let us know, we'll fix it.

Regards,

Thomas

[janasle]

Hi,

The problem is present in trunk as well. It might seem like there is a
timing issue/race condition between transaction handling and the
session handling.
If the TransactionManager gets to process the 200 OK prior to Session
everything works out just fine. If Session gets to execute before the
TransactionManager we get the error.

From my logs:

Success case:
16:21:46.966 [qtp3278971-58] DEBUG o.c.server.transaction.Transaction
- z9hG4bKb26475dbfe5d/INVITE/Calling -> Proceeding
16:21:46.966 [qtp3278971-58] DEBUG
o.c.s.transaction.TransactionManager - response SIP/2.0 200 OK
16:21:46.966 [qtp3278971-58] DEBUG o.c.server.transaction.Transaction
- z9hG4bKb26475dbfe5d/INVITE/Proceeding -> Accepted
16:21:46.967 [qtp3278971-58] DEBUG org.cipango.server.session.Session
- added client invite context with cseq 1
16:21:46.967 [qtp3278971-58] DEBUG org.cipango.server.session.Session
- [513c530a,state=INITIAL, _role = UAC] -> CONFIRMED
...
16:21:47.110 [pool-2-thread-1] DEBUG
org.cipango.server.session.Session - _remoteparty =
<sip:mo...@127.0.0.1:9000;transport=tcp>;tag=e09d5098

Error case:
16:21:12.500 [qtp18686494-59] DEBUG o.c.server.transaction.Transaction
- z9hG4bKdf7217aeb20a/INVITE/Calling -> Proceeding
16:21:12.501 [qtp18686494-59] DEBUG org.cipango.server.session.Session
- [30336243,state=INITIAL, _role = UAC] -> EARLY
16:21:12.503 [qtp18686494-59] DEBUG
o.c.s.transaction.TransactionManager - response SIP/2.0 200 OK
16:21:12.503 [qtp18686494-59] DEBUG o.c.server.transaction.Transaction
- z9hG4bKdf7217aeb20a/INVITE/Proceeding -> Accepted
16:21:12.504 [qtp18686494-59] DEBUG org.cipango.server.session.Session
- added client invite context with cseq 1
16:21:12.504 [qtp18686494-59] DEBUG org.cipango.server.session.Session
- [30336243,state=EARLY, _role = UAC] -> CONFIRMED
..
16:21:12.644 [pool-2-thread-1] DEBUG
org.cipango.server.session.Session - _remoteparty =
<sip:mo...@127.0.0.1:9000;transport=tcp>

Jan Asle

> >>> For more options, visit this group athttp://groups.google.com/group/cipango-users?hl=en.

>
> >> --
> >> You received this message because you are subscribed to the Google Groups "cipango-users" group.
> >> To post to this group, send email to cipang...@googlegroups.com.
> >> To unsubscribe from this group, send email to cipango-user...@googlegroups.com.

> >> For more options, visit this group athttp://groups.google.com/group/cipango-users?hl=en.

[Thomas]

Hi Jan Asle,

Thanks for the info. Actually, messages are always serialized and handling chain could not change so race conditions should not occur. However, the fact that in the failed case, session is in early state whereas it is in initial state in the successful one might indicate something went wrong.
Could you send us a log with the message details (message.log would be perfect) ?

Thanks,

Thomas

[Thomas]

I've open: http://jira.cipango.org/browse/CIPANGO-174 to follow the issue.

Le 9 déc. 2011 à 01:55, janasle a écrit :

[janasle]

I've attached message logs and wireshark traces to the bug.

Thanks!
Jan Asle
On Dec 9, 12:06 am, Thomas <tho...@cipango.org> wrote:
> I've open:http://jira.cipango.org/browse/CIPANGO-174to follow the issue.

[Thomas]

Thanks, we've found out the issue from the logs. A 180 is sent by the "movi" server without a To tag. This is non-compliant with RFC3261 since a 180 creates a (early) dialog and must then have a To tag.
As a result, the dialog is created in cipango with a null To tag.
We'll add a sanity check to prevent this issue. Meanwhile, if you can add a To tag in the 180 (or remove the 180), it should work as well.

Regards,

Thomas

[Jan Asle Kroknes]

Great!

Thank you very much for your help!

Jan

[Thomas]

Hi Jan, 

We've committed a fix in the trunk to check whether responses contain dialog information. Could you give it a try ? 

Regards, 

Thomas

[Jan Asle Kroknes]

Yeah, it works perfectly!

Thanks!

Jan