[asterisk-bugs] [JIRA] (ASTERISK-26490) res_pjsip: sends 481 Call/Transaction Does Not Exist when transaction branch parameter contains "_"

[Friendly Automation (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234116#comment-234116 ] 

Friendly Automation commented on ASTERISK-26490:
------------------------------------------------

Change 4567 merged by Joshua Colp:
Bundled pjproject:  Fix finding SIP transactions.

[https://gerrit.asterisk.org/4567|https://gerrit.asterisk.org/4567]

> res_pjsip: sends 481 Call/Transaction Does Not Exist when transaction branch parameter contains "_"
> ---------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-26490
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26490
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: pjproject/pjsip, Resources/res_pjsip
>    Affects Versions: 13.11.2
>         Environment: Linux 4.4.19-1-pve #1 SMP x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Juris Breicis
>            Assignee: Richard Mudgett
>         Attachments: 2_mss_smex_capture.log.pcap, asterisk_log.txt, extensions.conf, extensions.conf, MSS_SIP_TRACE_ISSUES.txt, PJPROJECT-trace-03112016.txt, pjsip.conf
>
>
> In this particular setup asterisk 13.11.2 [10.40.6.100] is connected to NSN MSS through SIP trunk [212.210.2.2:5060]. The calls are received and routed back through the same trunk. Randomly the PJSIP will reply 481 Call/Transaction Does Not Exist to the trunk's CANCEL request of ongoing call in Ringing state. And sometimes (for no apparent reason) it just processes CANCEL request as expected.
> I have attached console dump with: 
> core set debug 10 
> core set verbose 10
> pjsip set logging on
> and corresponding sections of pjsip.conf and extensions.conf
> Please note although it looks like internal network 10.X.X.X is communicating through nat with public one 212.X.X.X - the routers are configured so, that this communication happens without NAT directly machine to machine. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)