9 Apr
2017
9 Apr
'17
4:28 a.m.
Apologies for the false alarm here - Kamailio was not to blame.
There was a code change in a recent version of PJSIP that resulted in the
second Via header not including the src port that the request originated
from. Effectively this meant that the Via header was not an exact match for
the invite, which caused the transaction to not match. Through some
configuration changes in PJSIP I was able to work around this.
Best,
Colin
On Sat, Apr 8, 2017 at 7:56 PM, Colin Morelli <colin.morelli(a)gmail.com>
wrote:
Hey all,
Trying to debug an issue with canceling an invite. I have two different
types of clients. On one client, canceling an invite works correctly. With
the other client, it t_check_trans fails.
Both clients show the same request/responses:
On Client A:
-> INVITE
<- 183
-> PRACK
<- 200
-> UPDATE (from successful STUN binding)
<- 200
-> CANCEL
<- 200
On Client B:
-> INVITE
<- 183
-> PRACK
<- 200
-> UPDATE (from successful STUN binding)
<- 200
-> CANCEL
<- 481 (this is sent from my kamailio script when t_check_trans fails)
I can't see much that's different between the leading requests/responses
of each. They seem to be virtually identical (with the exception of IP
addresses and tag values, of course). This makes sense, since they're both
based on PJSIP (albeit different versions of PJSIP, but not off by much)
Is there anything in particular I should be looking out for that might be
obvious? I could provide more detailed logs and traces if required.
Best,
Colin