REFER throwing `481 Call Leg/Transaction Does Not Exist`

[kingster]

Here is my Call Sequence

Softphone ----> B2BUA -----> PBX

Now when PBX Sends a REFER b2bua is sending 481 Call Leg/Transaction Does Not Exist instead of accepting the REFER message and creating a new call leg.

I am running it as ./b2bua_simple -p 5060 -n 172.16.72.61:5060 -l 172.16.177.148

Transaction Logs : https://pastebin.com/raw/SdHGmxPK

Can you please help!

[kingster]

Just now checked, even simple call end with bye throws the same error

[bambyster]

You have CSeq discrepancies for both REFER and BYE. The INVITE from caller had CSeq: 1 and the REFER has CSeq: 1. The INVITE to the callee had CSeq: 200 but BYE had CSeq: 1

[kingster]

Hi

Here is the simple BYE scenario

INVITE sip:8002@172.16.176.65:5080 SIP/2.0
Via: SIP/2.0/UDP 172.16.72.240:5060;rport;branch=z9hG4bK822f943c79204763fa8cf910685c2d6a
Max-Forwards: 70
From: <sip:kinshuk@172.16.72.240>;tag=8add3c5c6e1110e743a01681a785a047
To: <sip:8002@172.16.176.65>
Call-ID: 87460NzRlMGQ4NTIwZDRmOTkzM2VmNzc0MzBlN2NmZTRkZmY
CSeq: 200 INVITE
Contact: Anonymous <sip:kinshuk@172.16.72.240:5060>
Expires: 300
User-Agent: Sippy B2BUA (Simple)
Max-Forwards: 70
Content-Length: 354
Content-Type: application/sdp

v=0
o=- 1576681670823989 1 IN IP4 172.16.72.240
s=Bria 5 release 5.0.2  stamp 87460
c=IN IP4 172.16.72.240
t=0 0
m=audio 64898 RTP/AVP 8 18 120 0 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:120 opus/48000/2
a=fmtp:120 useinbandfec=1; usedtx=1; maxaveragebitrate=64000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.72.240:5060;rport=5060;branch=z9hG4bK822f943c79204763fa8cf910685c2d6a
From: <sip:kinshuk@172.16.72.240>;tag=8add3c5c6e1110e743a01681a785a047
To: <sip:8002@172.16.176.65>;tag=8687FpU6NSXgr
Call-ID: 87460NzRlMGQ4NTIwZDRmOTkzM2VmNzc0MzBlN2NmZTRkZmY
CSeq: 200 INVITE
Contact: <sip:8002@172.16.176.65:5080;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.6.20-37-987c9b9~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 222
Remote-Party-ID: "8002" <sip:8002@172.16.176.65>;party=calling;privacy=off;screen=no

v=0
o=FreeSWITCH 1576660846 1576660847 IN IP4 172.16.176.65
s=FreeSWITCH
c=IN IP4 172.16.176.65
t=0 0
m=audio 20824 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

BYE sip:kinshuk@172.16.72.240:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.176.65:5080;rport;branch=z9hG4bK01cyH5tX1gXKK
Max-Forwards: 70
From: <sip:8002@172.16.176.65>;tag=8687FpU6NSXgr
To: <sip:kinshuk@172.16.72.240>;tag=8add3c5c6e1110e743a01681a785a047
Call-ID: 87460NzRlMGQ4NTIwZDRmOTkzM2VmNzc0MzBlN2NmZTRkZmY
CSeq: 13787056 BYE
User-Agent: FreeSWITCH-mod_sofia/1.6.20-37-987c9b9~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Reason: Q.850;cause=16;text="NORMAL_CLEARING"
Content-Length: 0

SIP/2.0 481 Call Leg/Transaction Does Not Exist
Via: SIP/2.0/UDP 172.16.176.65:5080;rport=5080;branch=z9hG4bK01cyH5tX1gXKK
From: <sip:8002@172.16.176.65>;tag=8687FpU6NSXgr
To: <sip:kinshuk@172.16.72.240>;tag=8add3c5c6e1110e743a01681a785a047
Call-ID: 87460NzRlMGQ4NTIwZDRmOTkzM2VmNzc0MzBlN2NmZTRkZmY
CSeq: 13787056 BYE
Content-Length: 0

The BYE CSeq > INVITE which is correct IMHO, can you correct me if I am wrong ? PS: On the 2nd side I have a FreeSwitch Server.

[bambyster]

https://tools.ietf.org/html/rfc3261#section-12.2.1.1

Requests within a dialog MUST contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one)

[kingster]

Hi @bambyster

As I understand, It says that applies for UAC and not UAS, the UAS may generate any CSeq and send it back. CSeq from each side should be (increasing-by-one). There is no correlation between the CSeq of UAC and UAS.

Please correct me if I am wrong.

[bambyster]

You are wrong.

[kingster]

Hi

Okay, then is there any way I can handle this ? The other party is AvayaMPP / FreeSwitch which I can't control and I am using b2bua to handle REFER scenario.

https://tools.ietf.org/html/rfc3261#section-12.2.2

Accepting the request for acceptable To tags provides robustness, so that dialogs can persist even through crashes. UAs wishing to support this capability must take into consideration some issues such as choosing monotonically increasing CSeq sequence numbers even across reboots, reconstructing the route set, and accepting out-of-range RTP timestamps and sequence numbers. . ... It is possible for the CSeq sequence number to be higher than the remote sequence number by more than one. This is not an error condition, and a UAS SHOULD be prepared to receive and process requests with CSeq values more than one higher than the previous received request. The UAS MUST then set the remote sequence number to the value of the sequence number in the CSeq header field value in the request.

This I didn't understand though completely. Does it mean mismatch is possible?

Please guide. Is there any code change that I can do so that this can be handled?

[bambyster]

Thank you. I was wrong about CSeq.

I confirm that there is a bug in the library which affects processing BYEs from the callee. Most probably it affects the REFER functionality too.

Sorry for misunderstanding and thank you for reporting!

[bambyster]

A fix has been applied. Please re-test from your side.

[kingster]

Hi

BYE now works but Refer throws a different error.

SIP log : https://pastebin.com/raw/tP3FKxn3

Running b2bua as ./b2bua_simple -p 5060 -n 172.16.176.65:5080 -l 172.16.177.148

Softphone ----> Proxy ----> B2BUA -----> PBX

I was hoping when PBX sends a REFER, B2BUA should send Invite to new destination and join with existing call, but it instead send the REFER towards Upstream which doesn't work.

[bambyster]

Hi,

Well, the REFER scenario you showed is exactly the way the b2bua_simple is designed to behave. It lets the caller UA to decide if it trusts the REFER and do appropriate actions. This is the simplest and the safest approach for such a simplistic b2bua.

It's possible to develop your own custom b2bua logic to process REFER in a different manner. For example the b2bua can send INVITE to a different callee and send re-INVITE to the caller to re-negotiate the media parameters. Which in turn requires to determine if the REFER from the callee can be trusted, which media offer/answer model to use, how to limit and charge this new call leg, etc. But anyway it's up to the code of your own custom b2bua.

[kingster]

Hi

Can you please guide how to make such changes? Any guide would be helpful.

[bambyster]

Hi,

Unfortunately there is no documentation for the library. However I added a simple example on how your scenario can be implemented using the sippy library. Please check the examples/call_transfer directory.

[kingster]

Thanks a lot, I was able to write the scenario that I wanted.