1. Brekeke Product Name and Version: BSS Standard 3.8.3.4/490
2. Java version: 1.8.0_144
3. OS type and the version: Linux 3.16.0-11-amd64
4. UA (phone), gateway or other hardware/software involved:
5. Your problem:
We get an Invite from a SBC of a partner A.
This call is forwarded to partner B who respond 503.
This 503 is send back to A.
A send second INVITE with the same Call ID.
BSS send back strange INVITE to A even if there is no such route.
Strange think is that First and Second INVITE from A have the same Call ID
Any Idea ?
First INVITE
=============================================
INVITE sip:0041786208997@46.174.56.146:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 85.162.2.37:5060;branch=z9hG4bK64an5d3048knni0btcr0.1
To: <sip:0041786208997@46.174.56.146;user=phone>
From: <sip:008801720000834@85.162.2.37;user=phone>;tag=SDbktp701-uk4f3es799
Call-ID: SDbktp701-020bdca29e2cd8bc35e7622182fc1043-v300g00090
CSeq: 1 INVITE
Max-Forwards: 62
Contact: <sip:85.162.2.37:5060;lr;transport=udp>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER
Content-Type: application/sdp
P-Asserted-Identity: <sip:008801720000834@85.162.2.37;user=phone>
Supported: 100rel
MIME-Version: 1.0
User-Agent: Huawei SoftX3000 V300R011
Content-Length: 334
v=0
o=- 403621271 403621272 IN IP4 85.162.2.37
s=SBC call
c=IN IP4 85.162.2.37
t=0 0
m=audio 27080 RTP/AVP 18 4 2 98 99 97
a=rtpmap:18 G729/8000
a=rtpmap:4 G723/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:98 G726-40/8000
a=rtpmap:99 G726-32/8000
a=rtpmap:97 telephone-event/8000
a=ptime:20
a=fmtp:97 0-15
a=fmtp:18 annexb=no
Second INVITE
==================================================
INVITE sip:0041786208997@46.174.56.146:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 85.162.2.5:5060;branch=z9hG4bKisehes10dogknmq1mtb0.1
To: <sip:0041786208997@46.174.56.146;user=phone>
From: <sip:008801720000834@85.162.2.5;user=phone>;tag=SDbktp701-vp4f3es799
Call-ID: SDbktp701-020bdca29e2cd8bc35e7622182fc1043-v300g00090
CSeq: 1 INVITE
Max-Forwards: 62
Contact: <sip:85.162.2.5:5060;lr;transport=udp>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER
Content-Type: application/sdp
P-Asserted-Identity: <sip:008801720000834@85.162.2.5;user=phone>
Supported: 100rel
MIME-Version: 1.0
User-Agent: Huawei SoftX3000 V300R011
Content-Length: 332
v=0
o=- 403621271 403621272 IN IP4 85.162.2.5
s=SBC call
c=IN IP4 85.162.2.5
t=0 0
m=audio 44954 RTP/AVP 18 4 2 98 99 97
a=rtpmap:18 G729/8000
a=rtpmap:4 G723/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:98 G726-40/8000
a=rtpmap:99 G726-32/8000
a=rtpmap:97 telephone-event/8000
a=ptime:20
a=fmtp:97 0-15
a=fmtp:18 annexb=no
Response of BSS to second INVITE
===============================
INVITE sip:85.162.2.37:5060;lr;transport=udp SIP/2.0
Via: SIP/2.0/UDP 46.174.56.146;branch=z9hG4bKcc837e2e2ab6-1bbb3ae7-2e7b5b
To: <sip:008801720000834@85.162.2.37;user=phone>
From: <sip:0041786208997@46.174.56.146;user=phone>;tag=bd9308bfbs
Call-ID: SDbktp701-020bdca29e2cd8bc35e7622182fc1043-v300g00090
CSeq: 1 INVITE
Max-Forwards: 61
Contact: <sip:46.174.56.146;lr>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER
P-Asserted-Identity: <sip:008801720000834@85.162.2.5;user=phone>
Supported: 100rel
MIME-Version: 1.0
User-Agent: Huawei SoftX3000 V300R011
Content-Type: application/sdp
Content-Length: 338
v=0
o=- 403621271 403621272 IN IP4 46.174.56.146
s=SBC call
c=IN IP4 46.174.56.146
t=0 0
m=audio 22990 RTP/AVP 18 4 2 98 99 97
a=rtpmap:18 G729/8000
a=rtpmap:4 G723/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:98 G726-40/8000
a=rtpmap:99 G726-32/8000
a=rtpmap:97 telephone-event/8000
a=ptime:20
a=fmtp:97 0-15
a=fmtp:18 annexb=no
Strange response of BSS
Moderator: Brekeke Support Team
According to these packets, From's tag and Via's branch parameter are different between the First INVITE and the Second INVITE, so it seems the Second INVITE is not re-transmitted packet of the First-INVITE. But the CSeq in the Second INVITE is still "CSeq: 1 INVITE". It is the problem. It should be "CSeq: 2 INVITE".
If the issue still persists, you might have a misconfiguration in DialPlan.
If the issue still persists, you might have a misconfiguration in DialPlan.
-
- Posts: 22
- Joined: Tue Feb 19, 2013 5:23 pm