Forums Read-only archive

BSS Does Not propagate the ACK for 200 from UAC to UAS

12 posts · Brekeke SIP Server Forum

skb007 Original post
1. Brekeke Product Name and Version:3.8

2. Java version:1.8

3. OS type and the version:RHEL 7.6

4. UA (phone), gateway or other hardware/software involved:NA

5. Your problem:BSS Does Not propagate the ACK for 200 from UAC to UAS







We have 4 interfaces configured on the BSS.
em1:192.168.10.10 : This interface/ip address is used to communicate the SIP signalling with the UAC.
em2:192.168.10.100 : This interface/ip is used to communicate rtp/media with UAC.


em3:192.168.20.20 : This interface/ip address is used to communicate the SIP signalling with the UAS.
em4:192.168.20.200 : This interface/ip is used to communicate rtp/media with UAS.


Call Flow:

UAC(10.10.10.10)------------------>BSS:em1<>BSS:em3----------------->UAS(1.1.1.1/2.2.2.2/3.3.3.3)


Matching Patterns
$request = ^INVITE
$addr = ^10\.10\.10\.10$
To = sip:1234(.+)@
From = sip:(.+)@


Deploy Patterns
To = sip:112233%1@1.1.1.1
From = sip:%2@192.168.20.20
$session = failover %1@2.2.2.2 %1@3.3.3.3
$b2bua = true
$rtp = true
$ifsrc = 192.168.10.10
&net.rtp.ifsrc = 192.168.10.100
&net.rtp.bindsrc = 192.168.10.100
$ifdst = 192.168.20.20
&net.rtp.ifdst = 192.168.20.200
&net.rtp.binddst = 192.168.20.200


Call Setup:
1. UAC sends call to BSS:em1 and BSS:em3 sends the call to UAS at 1.1.1.1
2. UAS 1.1.1.1 sends 488 and BSS failover the call to UAS at 2.2.2.2.
2. UAS 2.2.2.2 sends 500 and BSS failover the call to UAS at 3.3.3.3.
3. UAS 3.3.3.3 sends 200OK to BSS:em3 and BSS:em1 passes on the 200OK to UAC.
4. UAC sends the ACK for 200 to BSS:em1 and BSS DOES NOT send the ACK to UAS.
skb007
I have changed the ip addreses in my post for privacy reasons.
janP
Does the same issue happen even if you use another SIP client as UAC?

Check the [Status] field at [Active Session] page.
Is it "Ringing" , "Accepted" or "Talking"?
skb007
We have not tested with other UAC client. Customer is usinig Mitel PBX.

Did did not check the status of the session. But my wireshark trace was showing UAC-BSS leg "in-call" an BSS-UAS leg status was Call-Setup.
janP
Let you check the status of the session at the SIP Server. It shows whether the SIP Server accepted ACK or not.
skb007
Hi janP,

Unfortunately, customer is not available to test again so I am not able to check the session status.

Wireshark trace shows that ACK came to BSS.
Is there any way to check in the BSS logs to see if ACK was accepted by BSS?

CDR's has been generated by BSS with "Success" and talk status as "Talking"
skb007
BSS definately received the ACK, it shows up on the BSS logs, it also

From the CDR's I know that the session ID for the test calls was 22 so I am pasting the relevant portion of the log to show that it received the ACK from UAC




==============================================
session.22: receive: from=UAC:10.10.10.10:5060(UDP) at 06/05/19 22:11:26.397
==============================================
ACK sip:18005551212@192.168.10.10 SIP/2.0
Via: SIP/2.0/UDP 10.10.10.10;branch=z9hG4bK_AI2019Jun054116257123418005551212177;rport=5060
To: sip:123418005551212@mycustomer.com;tag=be469ad56s
From: <sip:8005551313@mycustomer.com>;tag=AI7217D4E8C7BA533D
Call-ID: AIEA665487771DC93A_00:08:5d:9a:42:f4
CSeq: 1 ACK
Route: <sip:192.168.10.10:5060;lr>
Route: <sip:192.168.10.10:5060;lr>
Allow-Events: presence,dialog,message-summary,refer
Max-Forwards: 70
User-Agent: Aastra 400
Content-Length: 0


==============================================

session.22: pkt#=8 dp=1 st=0 sip:8005551313@mycustomer.com(10.10.10.10:5060) --> sip:18005551212@3.3.3.3(192.168.10.10:5060)
send="ACK sip:18005551212@3.3.3.3:5060 SIP/2.0"

session.22: phase=5: Talking
session.22: processtime=1

session.22: send: to=UAS:192.168.10.10:5060(UDP) at 06/05/19 22:11:26.397
==============================================
ACK sip:18005551212@3.3.3.3:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.10.10:5060;branch=z9hG4bK96c237830dcc-30-1ac00d
To: sip:18005551212@3.3.3.3;tag=sbc0902959029
From: <sip:8005551313@192.168.10.10>;tag=b709cba85s
Call-ID: be056e9b-d48f7c24-5d2e4638-9f15990
CSeq: 1 ACK
Route: <sip:192.168.10.10:5060;lr>
Allow-Events: presence,dialog,message-summary,refer
Max-Forwards: 69
User-Agent: Aastra 400
Route: <sip:3.3.3.3:5060;transport=udp;lr>
Content-Length: 0


==============================================

session.22: stat: result=undefined(6) close=false
> +--------------+--------------+--------------+--------------+
> | | | | |
> +--------------+--------------+--------------+--------------+
> 0/1 0/0 0/1 0/0
> UAS-route: <sip:3.3.3.3:5060;transport=udp;lr>,

svlistener: debug: remote=192.168.10.10:5060 at 06/05/19 22:11:26.398
==============================================
ACK sip:18005551212@3.3.3.3:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.10.10:5060;branch=z9hG4bK96c237830dcc-30-1ac00d
To: sip:18005551212@3.3.3.3;tag=sbc0902959029
From: <sip:8005551313@192.168.10.10>;tag=b709cba85s
Call-ID: be056e9b-d48f7c24-5d2e4638-9f15990
CSeq: 1 ACK
Route: <sip:192.168.10.10:5060;lr>
Allow-Events: presence,dialog,message-summary,refer
Max-Forwards: 69
User-Agent: Aastra 400
Route: <sip:3.3.3.3:5060;transport=udp;lr>
Content-Length: 0


==============================================
svlistener: debug: remote=3.3.3.3:5060 at 06/05/19 22:11:27.097
==============================================
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.10.10:5060;branch=z9hG4bK96c2bf3eaeb6-30-1ac00d;received=180.178.75.30
Record-Route: <sip:3.3.3.3:5060;transport=udp;lr>
Call-ID: be056e9b-d48f7c24-5d2e4638-9f15990
From: <sip:8005551313@192.168.10.10>;tag=b709cba85s
To: <sip:18005551212@3.3.3.3>;tag=sbc0902959029
CSeq: 1 INVITE
Contact: <sip:18005551212@3.3.3.3:5060>
Supported: 100rel
Allow: INVITE,ACK,BYE,CANCEL,INFO,PRACK,REFER,SUBSCRIBE,NOTIFY,UPDATE
Content-Length: 308
Content-Type: application/sdp

v=0
o=- 288365568 1559743879 IN IP4 3.3.3.3
s=SBC call
c=IN IP4 3.3.3.3
t=0 0
m=audio 31678 RTP/AVP 8 9 18 101
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=maxptime:30

==============================================
session.22: receive: from=UAS:3.3.3.3:5060(UDP) at 06/05/19 22:11:27.097
==============================================
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.10.10:5060;branch=z9hG4bK96c2bf3eaeb6-30-1ac00d;received=180.178.75.30
Record-Route: <sip:3.3.3.3:5060;transport=udp;lr>
Call-ID: be056e9b-d48f7c24-5d2e4638-9f15990
From: <sip:8005551313@192.168.10.10>;tag=b709cba85s
To: <sip:18005551212@3.3.3.3>;tag=sbc0902959029
CSeq: 1 INVITE
Contact: <sip:18005551212@3.3.3.3:5060>
Supported: 100rel
Allow: INVITE,ACK,BYE,CANCEL,INFO,PRACK,REFER,SUBSCRIBE,NOTIFY,UPDATE
Content-Type: application/sdp
Content-Length: 308

v=0
o=- 288365568 1559743879 IN IP4 3.3.3.3
s=SBC call
c=IN IP4 3.3.3.3
t=0 0
m=audio 31678 RTP/AVP 8 9 18 101
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=maxptime:30

==============================================

session.22: RTPparam: IN=0 OUT=0
session.22: content-type=application/sdp plugin=com.brekeke.net.content.application.Sdp

session.22: pkt#=9 dp=2 st=0 sip:18005551212@3.3.3.3(3.3.3.3:5060) --> sip:8005551313@mycustomer.com(10.10.10.10:5060)
send="SIP/2.0 200 OK"

session.22: processtime=1

session.22: send: to=UAC:10.10.10.10:5060(UDP) at 06/05/19 22:11:27.098
==============================================
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.10.10;branch=z9hG4bK_AI2019Jun054107936123418005551212176;rport=5060
Call-ID: AIEA665487771DC93A_00:08:5d:9a:42:f4
From: <sip:8005551313@mycustomer.com>;tag=AI7217D4E8C7BA533D
To: sip:123418005551212@mycustomer.com;tag=be469ad56s
CSeq: 1 INVITE
Contact: <sip:18005551212@192.168.10.10>
Supported: 100rel
Allow: INVITE,ACK,BYE,CANCEL,INFO,PRACK,REFER,SUBSCRIBE,NOTIFY,UPDATE
Content-Type: application/sdp
Content-Length: 310

v=0
o=- 288365568 1559743879 IN IP4 192.168.10.10
s=SBC call
c=IN IP4 192.168.10.10
t=0 0
m=audio 32794 RTP/AVP 8 9 18 101
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=maxptime:30

==============================================

session.22: stat: result=undefined(6) close=false
> +--------------+--------------+--------------+--------------+
> | | 200 | | 200 |
> +--------------+--------------+--------------+--------------+
> 0/1 0/0 0/1 0/0
> UAS-route: <sip:3.3.3.3:5060;transport=udp;lr>,

svlistener: debug: remote=10.10.10.10:5060 at 06/05/19 22:11:27.167
==============================================
ACK sip:18005551212@192.168.10.10 SIP/2.0
Via: SIP/2.0/UDP 10.10.10.10;branch=z9hG4bK_AI2019Jun05411728123418005551212178;rport
To: sip:123418005551212@mycustomer.com;tag=be469ad56s
From: <sip:8005551313@mycustomer.com>;tag=AI7217D4E8C7BA533D
Call-ID: AIEA665487771DC93A_00:08:5d:9a:42:f4
CSeq: 1 ACK
Route: <sip:192.168.10.10:5060;lr>
Route: <sip:192.168.10.10:5060;lr>
Allow-Events: presence,dialog,message-summary,refer
Max-Forwards: 70
User-Agent: Aastra 400
Content-Length: 0


==============================================
session.22: receive: from=UAC:10.10.10.10:5060(UDP) at 06/05/19 22:11:27.167
==============================================
ACK sip:18005551212@192.168.10.10 SIP/2.0
Via: SIP/2.0/UDP 10.10.10.10;branch=z9hG4bK_AI2019Jun05411728123418005551212178;rport=5060
To: sip:123418005551212@mycustomer.com;tag=be469ad56s
From: <sip:8005551313@mycustomer.com>;tag=AI7217D4E8C7BA533D
Call-ID: AIEA665487771DC93A_00:08:5d:9a:42:f4
CSeq: 1 ACK
Route: <sip:192.168.10.10:5060;lr>
Route: <sip:192.168.10.10:5060;lr>
Allow-Events: presence,dialog,message-summary,refer
Max-Forwards: 70
User-Agent: Aastra 400
Content-Length: 0


==============================================

session.22: pkt#=10 dp=1 st=0 sip:8005551313@mycustomer.com(10.10.10.10:5060) --> sip:18005551212@3.3.3.3(192.168.10.10:5060)
send="ACK sip:18005551212@3.3.3.3:5060 SIP/2.0"

session.22: processtime=1

session.22: send: to=UAS:192.168.10.10:5060(UDP) at 06/05/19 22:11:27.168
==============================================
ACK sip:18005551212@3.3.3.3:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.10.10:5060;branch=z9hG4bK96c2edf2b24-30-1ac00d
To: sip:18005551212@3.3.3.3;tag=sbc0902959029
From: <sip:8005551313@192.168.10.10>;tag=b709cba85s
Call-ID: be056e9b-d48f7c24-5d2e4638-9f15990
CSeq: 1 ACK
Route: <sip:192.168.10.10:5060;lr>
Allow-Events: presence,dialog,message-summary,refer
Max-Forwards: 69
User-Agent: Aastra 400
Route: <sip:3.3.3.3:5060;transport=udp;lr>
Content-Length: 0


==============================================

session.22: stat: result=undefined(6) close=false
> +--------------+--------------+--------------+--------------+
> | | | | |
> +--------------+--------------+--------------+--------------+
> 0/1 0/0 0/1 0/0
> UAS-route: <sip:3.3.3.3:5060;transport=udp;lr>,

svlistener: debug: remote=192.168.10.10:5060 at 06/05/19 22:11:27.168
==============================================
ACK sip:18005551212@3.3.3.3:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.10.10:5060;branch=z9hG4bK96c2edf2b24-30-1ac00d
To: sip:18005551212@3.3.3.3;tag=sbc0902959029
From: <sip:8005551313@192.168.10.10>;tag=b709cba85s
Call-ID: be056e9b-d48f7c24-5d2e4638-9f15990
CSeq: 1 ACK
Route: <sip:192.168.10.10:5060;lr>
Allow-Events: presence,dialog,message-summary,refer
Max-Forwards: 69
User-Agent: Aastra 400
Route: <sip:3.3.3.3:5060;transport=udp;lr>
Content-Length: 0
janP
It seems ACK was routed based on Route: header what UAC announced.

Add the line below at Deploy Patterns.

Code: 

&net.sip.fixed.addrport.uas = true
skb007
Thanks for your response.

UAC sent the ACK with ROUTE: <IP_ADDRESS>, that IP address belongs to BSS. Then BSS should take the ACK and send it to UAS, inst it?

I have add the "&net.sip.fixed.addrport.uas = true" in the deploy pattern and schedule the testing with customer for tomorrow. I will provide my feedback after the testing.
janP
> UAC sent the ACK with ROUTE: <IP_ADDRESS>, that IP address belongs to BSS. Then BSS should take the ACK and send it to UAS, inst it?

It is true.
Do you know why the UAC puts the same Route header twice? It should be one.
Route: <sip:192.168.10.10:5060;lr>
Route: <sip:192.168.10.10:5060;lr>
skb007
I am sorry, I don't know why UAC(Mitel) is putting the ROUTE header twice. Do you think, it is causing the issue?
janP
Are there any Route header in INIVTE sent from the same UAC? If yes, how many Route headers are they? and are they pointing the SIP Server's IP address?

> Do you think, it is causing the issue?

I think one Route header for pointing the SIP Server's IP address is no problem. But two.. it might cause an issue.

If you use another SIP client instead of Aastra/Mitel as UAC, does the same issue happen?