Asterisk 1.4.21
We are getting a disconnect from our SIP peer (10.140.132.3 who are originating the call) due to a new SDP session version being sent when no new version should be assigned.
Here is the relavent part of the call:
<------------>
– Executing [+61712345678@vodafone-fiji:1] Dial(“SIP/10.140.132.3-083349a0”, “SIP/61712345678@nyc-nextone”) in new stack
– Called 61712345678@nyc-nextone
– SIP/nyc-gateway-08322ca0 is making progress passing it to SIP/10.140.132.3-083349a0
Audio is at 69.70.71.72 port 19858
Adding codec 0x100 (g729) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
bx-0098*CLI>
<— Transmitting (no NAT) to 10.140.132.3:5060 —>
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 10.140.132.3:5060;branch=z9hG4bK199739889;received=10.140.132.3
From: sip:+6787654321@10.140.132.3;user=phone;tag=1482818682
To: sip:+61712345678@69.70.71.72;user=phone;tag=as172afa60
Call-ID: uYeW7774805161001@10.140.132.3
CSeq: 19905 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: sip:+61712345678@69.70.71.72
Content-Type: application/sdp
Content-Length: 256
v=0
o=root 2907 2907 IN IP4 69.70.71.72
s=session
c=IN IP4 69.70.71.72
t=0 0
m=audio 19858 RTP/AVP 18 96
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
<------------>
– SIP/nyc-gateway-08322ca0 answered SIP/10.140.132.3-083349a0
Audio is at 69.70.71.72 port 19858
Adding codec 0x100 (g729) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
bx-0098*CLI>
<— Reliably Transmitting (no NAT) to 10.140.132.3:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.140.132.3:5060;branch=z9hG4bK199739889;received=10.140.132.3
From: sip:+6787654321@10.140.132.3;user=phone;tag=1482818682
To: sip:+61712345678@69.70.71.72;user=phone;tag=as172afa60
Call-ID: uYeW7774805161001@10.140.132.3
CSeq: 19905 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: sip:+61712345678@69.70.71.72
Content-Type: application/sdp
Content-Length: 256
v=0
o=root 2907 2908 IN IP4 69.70.71.72
s=session
c=IN IP4 69.70.71.72
t=0 0
m=audio 19858 RTP/AVP 18 96
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
<------------>
– Packet2Packet bridging SIP/10.140.132.3-083349a0 and SIP/nyc-gateway-08322ca0
bx-0098*CLI>
<— SIP read from 10.140.132.3:5060 —>
ACK sip:+61712345678@69.70.71.72 SIP/2.0
From: sip:+6787654321@10.140.132.3;user=phone;tag=1482818682
To: sip:+61712345678@69.70.71.72;user=phone;tag=as172afa60
Max-Forwards: 70
Via: SIP/2.0/UDP 10.140.132.3:5060;branch=z9hG4bK187707336
Call-ID: uYeW7774805161001@10.140.132.3
CSeq: 19905 ACK
Content-Length: 0
<------------->
— (8 headers 0 lines) —
bx-0098*CLI>
<— SIP read from 10.140.132.3:5060 —>
BYE sip:+61712345678@69.70.71.72 SIP/2.0
From: sip:+6787654321@10.140.132.3;user=phone;tag=1482818682
To: sip:+61712345678@69.70.71.72;user=phone;tag=as172afa60
Max-Forwards: 70
Via: SIP/2.0/UDP 10.140.132.3:5060;branch=z9hG4bK143720389
Call-ID: uYeW7774805161001@10.140.132.3
CSeq: 19906 BYE
Content-Length: 0
<------------->
In SIP/2.0 183 Session Progress o=root 2907 2907 IN IP4 69.70.71.72
and
in SIP/2.0 200 OK o=root 2907 2908 IN IP4 69.70.71.72
Ericsson, the manufacturers of the equipment that is refusing our SIP/2.0 200 OK have this to say:
As per RFC2327, the session version is only increased if a modification is made to the session data. In this case, the call is only being answered, no new session is being established and neither is the SDP being modified, hence it is expected that the same session number 2907 is used for 200 OK.
Our sip.conf entry is:
[test]
type=friend
host=10.140.132.3
context=test
canreinvite=no
insecure=very
qualify=3000
dtmfmode=rfc2833
disallow=all
allow=g729
So:
is this a bug in Asterisk 1.4.21 ?
has it been fixed in a later version (upgrading atm to test) ?
should the equipment at the other end accept it anyway?