[Home]

Summary:ASTERISK-11268: asterisk 1.6-beta1 destroys cisco 7960 (sip firmware 7.4) outbound calls after 20sec due to no response to 200 OK
Reporter:hmodes (hmodes)Labels:
Date Opened:2008-01-19 23:04:06.000-0600Date Closed:2008-01-29 10:57:18.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Version tag on this report is incorrect as there is no 1.6-beta1 tag yet.

1.6-beta1 appears to have an issue with sip timers that causes cisco 7960 sip firmware 7.4 clients to be disconnected after 20 seconds for not responding to 200 OK (marked as 'critical packet') once call setup is complete.  See debug.  Incoming calls to the client do not experience the disconnect.  This is reproducible on two phones both on the lan with asterisk and at a remote site.

****** ADDITIONAL INFORMATION ******

 == Using SIP RTP TOS bits 184
 == Using SIP RTP CoS mark 5
Sending to 172.27.28.127 : 5068 (no NAT)

<--- Reliably Transmitting (no NAT) to 172.27.28.127:5068 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK1029e56a;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f00044466d09e-419211b5
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as723ed620
Call-ID: 0002fdae-ee6f0008-4bb0cb6c-6de79049@172.27.28.127
CSeq: 101 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="matrix.gs", nonce="22c6c483"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '0002fdae-ee6f0008-4bb0cb6c-6de79049@172.27.28.127' in 32000 ms (Method: INVITE)
Sending to 172.27.28.127 : 5068 (no NAT)
Using INVITE request as basis request - 0002fdae-ee6f0008-4bb0cb6c-6de79049@172.27.28.127
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 18
Found RTP audio format 101
Peer audio RTP is at port 172.27.28.127:16614
Found audio description format PCMU for ID 0
Found audio description format PCMA for ID 8
Found audio description format G729 for ID 18
Found audio description format telephone-event for ID 101
Capabilities: us - 0x4 (ulaw), peer - audio=0x10c (ulaw|alaw|g729)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x4 (ulaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port 172.27.28.127:16614
Looking for 12152223456 in userauth (domain 172.27.28.2)
list_route: hop: <sip:hmodes@172.27.28.127:5068>

<--- Transmitting (no NAT) to 172.27.28.127:5068 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK443433a1;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f00044466d09e-419211b5
To: <sip:12152223456@172.27.28.2;user=phone>
Call-ID: 0002fdae-ee6f0008-4bb0cb6c-6de79049@172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:12152223456@172.27.28.2:51731>
Content-Length: 0


<------------>
   -- Executing [12152223456@userauth:1] SetMusicOnHold("SIP/hmodes-b7712910", "default") in new stack
   -- Executing [12152223456@userauth:2] NoOp("SIP/hmodes-b7712910", "") in new stack
   -- Executing [12152223456@userauth:3] Dial("SIP/hmodes-b7712910", "SIP/12152223456@atlas,60,r") in new stack
 == Using SIP RTP TOS bits 184
 == Using SIP RTP CoS mark 5
   -- Called 12152223456@atlas

<--- Transmitting (no NAT) to 172.27.28.127:5068 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK443433a1;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f00044466d09e-419211b5
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as242dad75
Call-ID: 0002fdae-ee6f0008-4bb0cb6c-6de79049@172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:12152223456@172.27.28.2:51731>
Content-Length: 0


<------------>
   -- SIP/atlas-096cf100 is making progress passing it to SIP/hmodes-b7712910
--- set_address_from_contact host '69.59.227.94'
   -- SIP/atlas-096cf100 answered SIP/hmodes-b7712910
Audio is at 172.27.28.2 port 40824
Adding codec 0x4 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP

<--- Reliably Transmitting (no NAT) to 172.27.28.127:5068 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK443433a1;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f00044466d09e-419211b5
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as242dad75
Call-ID: 0002fdae-ee6f0008-4bb0cb6c-6de79049@172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:12152223456@172.27.28.2:51731>
Content-Type: application/sdp
Content-Length: 263

v=0
o=root 207569133 207569133 IN IP4 172.27.28.2
s=Asterisk PBX 1.6.0-beta1
c=IN IP4 172.27.28.2
t=0 0
m=audio 40824 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

<------------>
   -- Packet2Packet bridging SIP/hmodes-b7712910 and SIP/atlas-096cf100
Retransmitting #1 (no NAT) to 172.27.28.127:5068:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK443433a1;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f00044466d09e-419211b5
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as242dad75
Call-ID: 0002fdae-ee6f0008-4bb0cb6c-6de79049@172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:12152223456@172.27.28.2:51731>
Content-Type: application/sdp
Content-Length: 263

v=0
o=root 207569133 207569133 IN IP4 172.27.28.2
s=Asterisk PBX 1.6.0-beta1
c=IN IP4 172.27.28.2
t=0 0
m=audio 40824 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

---
Retransmitting #2 (no NAT) to 172.27.28.127:5068:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK443433a1;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f00044466d09e-419211b5
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as242dad75
Call-ID: 0002fdae-ee6f0008-4bb0cb6c-6de79049@172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:12152223456@172.27.28.2:51731>
Content-Type: application/sdp
Content-Length: 263

v=0
o=root 207569133 207569133 IN IP4 172.27.28.2
s=Asterisk PBX 1.6.0-beta1
c=IN IP4 172.27.28.2
t=0 0
m=audio 40824 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

---
Retransmitting #3 (no NAT) to 172.27.28.127:5068:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK443433a1;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f00044466d09e-419211b5
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as242dad75
Call-ID: 0002fdae-ee6f0008-4bb0cb6c-6de79049@172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:12152223456@172.27.28.2:51731>
Content-Type: application/sdp
Content-Length: 263

v=0
o=root 207569133 207569133 IN IP4 172.27.28.2
s=Asterisk PBX 1.6.0-beta1
c=IN IP4 172.27.28.2
t=0 0
m=audio 40824 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

---
Retransmitting #4 (no NAT) to 172.27.28.127:5068:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK443433a1;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f00044466d09e-419211b5
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as242dad75
Call-ID: 0002fdae-ee6f0008-4bb0cb6c-6de79049@172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:12152223456@172.27.28.2:51731>
Content-Type: application/sdp
Content-Length: 263

v=0
o=root 207569133 207569133 IN IP4 172.27.28.2
s=Asterisk PBX 1.6.0-beta1
c=IN IP4 172.27.28.2
t=0 0
m=audio 40824 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

---
Retransmitting ASTERISK-1 (no NAT) to 172.27.28.127:5068:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK443433a1;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f00044466d09e-419211b5
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as242dad75
Call-ID: 0002fdae-ee6f0008-4bb0cb6c-6de79049@172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:12152223456@172.27.28.2:51731>
Content-Type: application/sdp
Content-Length: 263

v=0
o=root 207569133 207569133 IN IP4 172.27.28.2
s=Asterisk PBX 1.6.0-beta1
c=IN IP4 172.27.28.2
t=0 0
m=audio 40824 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

---
Retransmitting ASTERISK-2 (no NAT) to 172.27.28.127:5068:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK443433a1;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f00044466d09e-419211b5
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as242dad75
Call-ID: 0002fdae-ee6f0008-4bb0cb6c-6de79049@172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:12152223456@172.27.28.2:51731>
Content-Type: application/sdp
Content-Length: 263

v=0
o=root 207569133 207569133 IN IP4 172.27.28.2
s=Asterisk PBX 1.6.0-beta1
c=IN IP4 172.27.28.2
t=0 0
m=audio 40824 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

---
[Jan 19 23:51:04] WARNING[15775]: chan_sip.c:2688 retrans_pkt: Maximum retries exceeded on transmission 0002fdae-ee6f0008-4bb0cb6c-6de79049@172.27.28.127 for seqno 102 (Critical Response)
[Jan 19 23:51:04] WARNING[15775]: chan_sip.c:2715 retrans_pkt: Hanging up call 0002fdae-ee6f0008-4bb0cb6c-6de79049@172.27.28.127 - no reply to our critical packet.
 == Spawn extension (userauth, 12152223456, 3) exited non-zero on 'SIP/hmodes-b7712910'
Really destroying SIP dialog '0002fdae-ee6f0008-4bb0cb6c-6de79049@172.27.28.127' Method: INVITE

Comments:By: hmodes (hmodes) 2008-01-20 11:35:05.000-0600

Confirmed that this behavior also occurs with the latest 7960 firmware (sip v8.8) just for good measure.
By: hmodes (hmodes) 2008-01-20 21:07:55.000-0600

More info on this.  I went back and looked at a tethereal dump at the phone between 1.4.0 and 1.6.0-beta1 with the same configuration and same phone, and it appears that in 1.4.0, the 7960 does ACK the 200 OK, but it doesn't in 1.6.0-beta1

1.4.0:
427.901661 172.27.28.127 -> 172.27.28.2  SIP/SDP Request: INVITE sip:12152223456@172.27.28.2;user=phone, with session description
427.902660  172.27.28.2 -> 172.27.28.127 SIP Status: 407 Proxy Authentication Required
427.991555 172.27.28.127 -> 172.27.28.2  SIP Request: ACK sip:12152223456@172.27.28.2;user=phone
428.058475 172.27.28.127 -> 172.27.28.2  SIP/SDP Request: INVITE sip:12152223456@172.27.28.2;user=phone, with session description
428.059474  172.27.28.2 -> 172.27.28.127 SIP Status: 100 Trying
428.063467  172.27.28.2 -> 172.27.28.127 SIP Status: 180 Ringing
430.137626  172.27.28.2 -> 172.27.28.127 SIP/SDP Status: 200 OK, with session description
430.304460 172.27.28.127 -> 172.27.28.2  SIP Request: ACK sip:12152223456@172.27.28.2:5066
443.796524  172.27.28.2 -> 172.27.28.127 SIP Request: BYE sip:hmodes@172.27.28.127:5068;transport=udp

With sip_state debug enabled on the phone, it reports the following when receiving 1.6.0-beta1's 200 OK:

[21:35:34:19959] sip_sm_determine_ccb: Matched to_tag
[21:35:34:19959] sip_sm_ccb_match_branch_cseq: Method index not found
[21:35:34:19960] SIPTaskProcessSIPMessage: Error: sip_sm_determine_ccb(): bad response. Dropping message.

As far as I can tell, the likely candidate for why the phone is dropping the 200 OK is the port in the Contact: field.  I spent some time comparing the 1.4 200 OK and 1.6 200 OK and ruled out differences in the Supported: (1.6 includes timer, 1.4 only has replaces) and s= (1.4 sets session, 1.6 sets Asterisk PBX 1.6.0-beta1)  Below is the 1.4 200 OK followed by the 1.6 200 OK (after changing the mentioned differences to match 1.4's).  I have _NO_ idea where 1.6 is getting port 51731 for in the contact field.  The phone is transmitting from port 50750 for this transaction (<--- SIP read from UDP://172.27.28.127:50750 --->)...

#### 1.4.0 200 OK

<--- Reliably Transmitting (no NAT) to 172.27.28.127:5068 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK3e4b42ba;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f09f40a923727-2ca7742d
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as7738c114
Call-ID: 0002fdae-ee6f000a-12a7ddcc-25320b0f@172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:12152223456@172.27.28.2:5066>
Content-Type: application/sdp
Content-Length: 236

v=0
o=root 8875 8875 IN IP4 172.27.28.2
s=session
c=IN IP4 172.27.28.2
t=0 0
m=audio 44702 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

<------------>

##### 1.6.0-beta1 200 OK

<--- Reliably Transmitting (no NAT) to 172.27.28.127:5068 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK3728f458;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f00394f1cea50-1f4aa646
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as02b797d7
Call-ID: 0002fdae-ee6f000b-14a62878-104c655e@172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:12152223456@172.27.28.2:51731>
Content-Type: application/sdp
Content-Length: 248

v=0
o=root 2055288498 2055288498 IN IP4 172.27.28.2
s=session
c=IN IP4 172.27.28.2
t=0 0
m=audio 46746 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

<------------>



Incidentally, changing XMIT_CRITICAL to XMIT_RELIABLE in sip_answer() functions as a temporary workaround to this bug.  The 200 OK is still ignored by the 7960 but asterisk does not destroy the call as a result.
By: Joshua C. Colp (jcolp) 2008-01-21 11:14:20.000-0600

Could you please provide a sip debug with *both* sides of the dialog? That would be incredibly useful.
By: hmodes (hmodes) 2008-01-21 11:57:25.000-0600

Huh, looks like sip debug peer is only displaying the outgoing messages.  Here's the same call w/ debug ip and everything reverted back to the vanilla tarball.

<--- SIP read from UDP://172.27.28.127:50718 --->
INVITE sip:12152223456@172.27.28.2;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK270f21cf
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f057f0ac8fb0d-275aa1c1
To: <sip:12152223456@172.27.28.2;user=phone>
Call-ID: 0002fdae-ee6f000f-262c94c0-1bfbee42@172.27.28.127
Max-Forwards: 70
Date: Mon, 21 Jan 2008 17:53:49 GMT
CSeq: 101 INVITE
User-Agent: Cisco-CP7960G/8.0
Contact: <sip:hmodes@172.27.28.127:5068;transport=udp>
Expires: 180
Accept: application/sdp
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE
Supported: replaces,join,norefersub
Content-Length: 277
Content-Type: application/sdp
Content-Disposition: session;handling=optional

v=0
o=Cisco-SIPUA 5885 0 IN IP4 172.27.28.127
s=SIP Call
t=0 0
m=audio 16610 RTP/AVP 0 8 18 101
c=IN IP4 172.27.28.127
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

<------------->
--- (17 headers 13 lines) ---
 == Using SIP RTP TOS bits 184
 == Using SIP RTP CoS mark 5
Sending to 172.27.28.127 : 5068 (no NAT)
Using INVITE request as basis request - 0002fdae-ee6f000f-262c94c0-1bfbee42@172.27.28.127
Found user 'hmodes' for 'hmodes'

<--- Reliably Transmitting (no NAT) to 172.27.28.127:5068 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK270f21cf;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f057f0ac8fb0d-275aa1c1
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as01fdc2db
Call-ID: 0002fdae-ee6f000f-262c94c0-1bfbee42@172.27.28.127
CSeq: 101 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="matrix.gs", nonce="6a066103"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '0002fdae-ee6f000f-262c94c0-1bfbee42@172.27.28.127' in 32000 ms (Method: INVITE)

<--- SIP read from UDP://172.27.28.127:50782 --->
ACK sip:12152223456@172.27.28.2;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK270f21cf
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f057f0ac8fb0d-275aa1c1
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as01fdc2db
Call-ID: 0002fdae-ee6f000f-262c94c0-1bfbee42@172.27.28.127
Date: Mon, 21 Jan 2008 17:53:49 GMT
CSeq: 101 ACK
Content-Length: 0


<------------->
--- (8 headers 0 lines) ---

<--- SIP read from UDP://172.27.28.127:50718 --->
INVITE sip:12152223456@172.27.28.2;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK7afb1e94
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f057f0ac8fb0d-275aa1c1
To: <sip:12152223456@172.27.28.2;user=phone>
Call-ID: 0002fdae-ee6f000f-262c94c0-1bfbee42@172.27.28.127
Max-Forwards: 70
Date: Mon, 21 Jan 2008 17:53:49 GMT
CSeq: 102 INVITE
User-Agent: Cisco-CP7960G/8.0
Contact: <sip:hmodes@172.27.28.127:5068;transport=udp>
Authorization: Digest username="hmodes",realm="matrix.gs",uri="sip:12152223456@172.27.28.2;user=phone",response="b379158727f2be3a5c60a82730c03b39",nonce="6a066103",algorithm=MD5
Expires: 180
Accept: application/sdp
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE
Supported: replaces,join,norefersub
Content-Length: 277
Content-Type: application/sdp
Content-Disposition: session;handling=optional

v=0
o=Cisco-SIPUA 5885 0 IN IP4 172.27.28.127
s=SIP Call
t=0 0
m=audio 16610 RTP/AVP 0 8 18 101
c=IN IP4 172.27.28.127
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

<------------->
--- (18 headers 13 lines) ---
Sending to 172.27.28.127 : 5068 (no NAT)
Using INVITE request as basis request - 0002fdae-ee6f000f-262c94c0-1bfbee42@172.27.28.127
Found user 'hmodes' for 'hmodes'
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 18
Found RTP audio format 101
Peer audio RTP is at port 172.27.28.127:16610
Found audio description format PCMU for ID 0
Found audio description format PCMA for ID 8
Found audio description format G729 for ID 18
Found audio description format telephone-event for ID 101
Capabilities: us - 0x4 (ulaw), peer - audio=0x10c (ulaw|alaw|g729)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x4 (ulaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port 172.27.28.127:16610
Looking for 12152223456 in userauth (domain 172.27.28.2)
list_route: hop: <sip:hmodes@172.27.28.127:5068;transport=udp>

<--- Transmitting (no NAT) to 172.27.28.127:5068 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK7afb1e94;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f057f0ac8fb0d-275aa1c1
To: <sip:12152223456@172.27.28.2;user=phone>
Call-ID: 0002fdae-ee6f000f-262c94c0-1bfbee42@172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:12152223456@172.27.28.2:51731>
Content-Length: 0


<------------>
   -- Executing [12152223456@userauth:1] SetMusicOnHold("SIP/hmodes-083e0188", "default") in new stack
   -- Executing [12152223456@userauth:2] NoOp("SIP/hmodes-083e0188", "") in new stack
   -- Executing [12152223456@userauth:3] Dial("SIP/hmodes-083e0188", "SIP/12152223456@atlas,60,r") in new stack
 == Using SIP RTP TOS bits 184
 == Using SIP RTP CoS mark 5
   -- Called 12152223456@atlas

<--- Transmitting (no NAT) to 172.27.28.127:5068 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK7afb1e94;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f057f0ac8fb0d-275aa1c1
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as2aca97e5
Call-ID: 0002fdae-ee6f000f-262c94c0-1bfbee42@172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:12152223456@172.27.28.2:51731>
Content-Length: 0


<------------>
   -- SIP/atlas-084186e0 is making progress passing it to SIP/hmodes-083e0188
--- set_address_from_contact host '69.59.227.94'
   -- SIP/atlas-084186e0 answered SIP/hmodes-083e0188
Audio is at 172.27.28.2 port 49324
Adding codec 0x4 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP

<--- Reliably Transmitting (no NAT) to 172.27.28.127:5068 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK7afb1e94;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f057f0ac8fb0d-275aa1c1
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as2aca97e5
Call-ID: 0002fdae-ee6f000f-262c94c0-1bfbee42@172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:12152223456@172.27.28.2:51731>
Content-Type: application/sdp
Content-Length: 248

v=0
o=root 1900596219 1900596219 IN IP4 172.27.28.2
s=session
c=IN IP4 172.27.28.2
t=0 0
m=audio 49324 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

<------------>
   -- Packet2Packet bridging SIP/hmodes-083e0188 and SIP/atlas-084186e0
Retransmitting #1 (no NAT) to 172.27.28.127:5068:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK7afb1e94;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f057f0ac8fb0d-275aa1c1
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as2aca97e5
Call-ID: 0002fdae-ee6f000f-262c94c0-1bfbee42@172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:12152223456@172.27.28.2:51731>
Content-Type: application/sdp
Content-Length: 248

v=0
o=root 1900596219 1900596219 IN IP4 172.27.28.2
s=session
c=IN IP4 172.27.28.2
t=0 0
m=audio 49324 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

---
Retransmitting #2 (no NAT) to 172.27.28.127:5068:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK7afb1e94;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f057f0ac8fb0d-275aa1c1
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as2aca97e5
Call-ID: 0002fdae-ee6f000f-262c94c0-1bfbee42@172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:12152223456@172.27.28.2:51731>
Content-Type: application/sdp
Content-Length: 248

v=0
o=root 1900596219 1900596219 IN IP4 172.27.28.2
s=session
c=IN IP4 172.27.28.2
t=0 0
m=audio 49324 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

---
Retransmitting #3 (no NAT) to 172.27.28.127:5068:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK7afb1e94;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f057f0ac8fb0d-275aa1c1
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as2aca97e5
Call-ID: 0002fdae-ee6f000f-262c94c0-1bfbee42@172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:12152223456@172.27.28.2:51731>
Content-Type: application/sdp
Content-Length: 248

v=0
o=root 1900596219 1900596219 IN IP4 172.27.28.2
s=session
c=IN IP4 172.27.28.2
t=0 0
m=audio 49324 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

---
Retransmitting #4 (no NAT) to 172.27.28.127:5068:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK7afb1e94;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f057f0ac8fb0d-275aa1c1
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as2aca97e5
Call-ID: 0002fdae-ee6f000f-262c94c0-1bfbee42@172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:12152223456@172.27.28.2:51731>
Content-Type: application/sdp
Content-Length: 248

v=0
o=root 1900596219 1900596219 IN IP4 172.27.28.2
s=session
c=IN IP4 172.27.28.2
t=0 0
m=audio 49324 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

---
Retransmitting ASTERISK-1 (no NAT) to 172.27.28.127:5068:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK7afb1e94;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f057f0ac8fb0d-275aa1c1
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as2aca97e5
Call-ID: 0002fdae-ee6f000f-262c94c0-1bfbee42@172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:12152223456@172.27.28.2:51731>
Content-Type: application/sdp
Content-Length: 248

v=0
o=root 1900596219 1900596219 IN IP4 172.27.28.2
s=session
c=IN IP4 172.27.28.2
t=0 0
m=audio 49324 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

---
Retransmitting ASTERISK-2 (no NAT) to 172.27.28.127:5068:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.27.28.127:5068;branch=z9hG4bK7afb1e94;received=172.27.28.127
From: "hmodes" <sip:hmodes@172.27.28.2>;tag=0002fdaeee6f057f0ac8fb0d-275aa1c1
To: <sip:12152223456@172.27.28.2;user=phone>;tag=as2aca97e5
Call-ID: 0002fdae-ee6f000f-262c94c0-1bfbee42@172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:12152223456@172.27.28.2:51731>
Content-Type: application/sdp
Content-Length: 248

v=0
o=root 1900596219 1900596219 IN IP4 172.27.28.2
s=session
c=IN IP4 172.27.28.2
t=0 0
m=audio 49324 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

---
[Jan 21 12:54:12] WARNING[19363]: chan_sip.c:2688 retrans_pkt: Maximum retries exceeded on transmission 0002fdae-ee6f000f-262c94c0-1bfbee42@172.27.28.127 for seqno 102 (Critical Response)
[Jan 21 12:54:12] WARNING[19363]: chan_sip.c:2715 retrans_pkt: Hanging up call 0002fdae-ee6f000f-262c94c0-1bfbee42@172.27.28.127 - no reply to our critical packet.
 == Spawn extension (userauth, 12152223456, 3) exited non-zero on 'SIP/hmodes-083e0188'
Really destroying SIP dialog '0002fdae-ee6f000f-262c94c0-1bfbee42@172.27.28.127' Method: INVITE
By: Olle Johansson (oej) 2008-01-22 08:58:18.000-0600

The contact in the 200 OK is obviously wrong. It specifies a port that Asterisk normally doesn't listen to and the phone is supposed to send the ACK there. I don't know if the addition of TCP/TLS stuff changed the contact process or not, but it certainly looks weird.

Please upload SIP debugs as attachments in the future to make it easier to work with the bug tracker. Thanks.
By: Joshua C. Colp (jcolp) 2008-01-25 08:50:12.000-0600

And one last thing... the general section of sip.conf
By: hmodes (hmodes) 2008-01-25 08:59:07.000-0600

sip.conf general section follows.

[general]
context=default                 ; Default context for incoming calls
recordhistory=yes               ; Record SIP history by default
realm=matrix.gs         ; Realm for digest authentication
bindport=5066           ; UDP Port to bind to (SIP standard port is 5060)
bindaddr=0.0.0.0                ; IP address to bind to (0.0.0.0 binds to all)
srvlookup=yes                   ; Enable DNS SRV lookups on outbound calls
tos_audio=184
videosupport=no         ; Turn on support for SIP video
sdpsession=session
allow=all
useragent=matrix.gs asterisk            ; Allows you to change the user agent string
externip = *my external ip here*
localnet=172.27.28.0/255.255.255.0; All RFC 1918 addresses are local networks
By: Joshua C. Colp (jcolp) 2008-01-25 09:03:21.000-0600

are you running this on a strange platform or just plain x86?
By: hmodes (hmodes) 2008-01-25 09:12:54.000-0600

The system in question is running Redhat AS4 update 4 on x86 (2.6.9-42.EL #1 Wed Jul 12 23:16:43 EDT 2006 i686) on a pretty vanilla p4 workstation.  The only mentionably weird thing about the machine is it has some nasty clock drift, but that hasn't effected asterisk 1.4 in the past.
By: Digium Subversion (svnbot) 2008-01-28 07:55:20.000-0600

Repository: asterisk
Revision: 100549

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r100549 | file | 2008-01-28 07:55:18 -0600 (Mon, 28 Jan 2008) | 4 lines

Don't do a network byte order conversion when setting the socket's port variable to that of bindaddr's. It is already in the correct network byte order.
(closes issue ASTERISK-11268)
Reported by: hmodes

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=100549
By: Digium Subversion (svnbot) 2008-01-29 10:57:18.000-0600

Repository: asterisk
Revision: 100881

_U  team/murf/bug11210/
U   team/murf/bug11210/apps/app_voicemail.c
U   team/murf/bug11210/build_tools/menuselect-deps.in
U   team/murf/bug11210/channels/Makefile
U   team/murf/bug11210/channels/chan_h323.c
U   team/murf/bug11210/channels/chan_iax2.c
U   team/murf/bug11210/channels/chan_local.c
U   team/murf/bug11210/channels/chan_mgcp.c
U   team/murf/bug11210/channels/chan_misdn.c
U   team/murf/bug11210/channels/chan_sip.c
A   team/murf/bug11210/channels/chan_vpb.cc
U   team/murf/bug11210/channels/chan_zap.c
A   team/murf/bug11210/configs/vpb.conf.sample
U   team/murf/bug11210/configure
U   team/murf/bug11210/configure.ac
U   team/murf/bug11210/doc/tex/channelvariables.tex
U   team/murf/bug11210/include/asterisk/autoconfig.h.in
U   team/murf/bug11210/include/asterisk/channel.h
U   team/murf/bug11210/include/asterisk/sched.h
U   team/murf/bug11210/main/cdr.c
U   team/murf/bug11210/main/channel.c
U   team/murf/bug11210/main/dnsmgr.c
U   team/murf/bug11210/main/features.c
U   team/murf/bug11210/main/file.c
U   team/murf/bug11210/main/logger.c
U   team/murf/bug11210/main/pbx.c
U   team/murf/bug11210/main/rtp.c
U   team/murf/bug11210/makeopts.in
U   team/murf/bug11210/pbx/pbx_dundi.c

------------------------------------------------------------------------
r100881 | murf | 2008-01-29 10:57:16 -0600 (Tue, 29 Jan 2008) | 213 lines

Merged revisions 100488,100497,100514,100532-100533,100549,100565,100582,100625,100627-100628,100630-100632,100671,100674,100676-100679 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r100488 | tilghman | 2008-01-27 15:35:29 -0700 (Sun, 27 Jan 2008) | 19 lines

Merged revisions 100465 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r100465 | tilghman | 2008-01-27 15:59:53 -0600 (Sun, 27 Jan 2008) | 11 lines

When deleting a task from the scheduler, ignoring the return value could
possibly cause memory to be accessed after it is freed, which causes all
sorts of random memory corruption.  Instead, if a deletion fails, wait a
bit and try again (noting that another thread could change our taskid
value).
(closes issue ASTERISK-10897)
Reported by: flujan
Patches:
      20080124__bug11386.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76, flujan, stuarth`

........

................
r100497 | tilghman | 2008-01-27 16:14:48 -0700 (Sun, 27 Jan 2008) | 5 lines

With the switch to the ast_sched_replace* API in trunk, we lose the correction
that was just merged from 1.4, so this is a changeover to those APIs to use the
macro versions, so that we properly detect errors from ast_sched_del, instead
of simply ignoring the return values.

................
r100514 | russell | 2008-01-27 17:56:14 -0700 (Sun, 27 Jan 2008) | 5 lines

These readlocks always fail for me on my mac, and I saw it happen again
today on another mac.  We ignore the return value of locking operations almost
everywhere in Asterisk.  So, ignore these, as well, so Asterisk will actually
work on systems where this is occurring while I look into what the issue is.

................
r100532 | russell | 2008-01-27 21:30:44 -0700 (Sun, 27 Jan 2008) | 3 lines

- Simplify a line with ARRAY_LEN()
- Make a few little formatting changes

................
r100533 | russell | 2008-01-27 21:43:14 -0700 (Sun, 27 Jan 2008) | 2 lines

Make a couple more uses of ARRAY_LEN, and convert some spaces to tabs

................
r100549 | file | 2008-01-28 06:57:38 -0700 (Mon, 28 Jan 2008) | 4 lines

Don't do a network byte order conversion when setting the socket's port variable to that of bindaddr's. It is already in the correct network byte order.
(closes issue ASTERISK-11268)
Reported by: hmodes

................
r100565 | russell | 2008-01-28 07:27:28 -0700 (Mon, 28 Jan 2008) | 2 lines

Clean up some formatting, and simplify a bit of code using ast_str

................
r100582 | russell | 2008-01-28 10:21:24 -0700 (Mon, 28 Jan 2008) | 17 lines

Merged revisions 100581 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r100581 | russell | 2008-01-28 11:15:41 -0600 (Mon, 28 Jan 2008) | 9 lines

Make some deadlock related fixes.  These bugs were discovered and reported
internally at Digium by Steve Pitts.
- Fix up chan_local to ensure that the channel lock is held before the local
  pvt lock.
- Don't hold the channel lock when executing the timing function, as it can
  cause a deadlock when using chan_local.  This actually changes the code back
  to be how it was before the change for issue ASTERISK-10339.  But, I added some other
  locking that I think will prevent the problem reported there, as well.

........

................
r100625 | qwell | 2008-01-28 11:24:40 -0700 (Mon, 28 Jan 2008) | 9 lines

Merged revisions 100624 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r100624 | qwell | 2008-01-28 12:23:09 -0600 (Mon, 28 Jan 2008) | 1 line

Correct a comment which made little/no sense.
........

................
r100627 | russell | 2008-01-28 11:27:08 -0700 (Mon, 28 Jan 2008) | 15 lines

Merged revisions 100626 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r100626 | russell | 2008-01-28 12:26:31 -0600 (Mon, 28 Jan 2008) | 7 lines

Fix a crash in ast_masq_park_call()

(issue ASTERISK-10856)
Reported by: DEA
Patches:
     res_features-park.txt uploaded by DEA (license 3)

........

................
r100628 | tilghman | 2008-01-28 11:27:29 -0700 (Mon, 28 Jan 2008) | 3 lines

Normalize the detection for execinfo, so that Linux (glibc) and other platforms
with libexecinfo will generate inline stack backtraces correctly.

................
r100630 | russell | 2008-01-28 11:38:56 -0700 (Mon, 28 Jan 2008) | 13 lines

Merged revisions 100629 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r100629 | russell | 2008-01-28 12:34:20 -0600 (Mon, 28 Jan 2008) | 5 lines

For some reason, the use of this strdupa() is leading to memory corruption on
freebsd sparc64.  This trivial workaround fixes it.

(closes issue ASTERISK-9956, closes issue ASTERISK-11316, reported by mattias04 and Home-of-the-Brave)

........

................
r100631 | russell | 2008-01-28 11:41:23 -0700 (Mon, 28 Jan 2008) | 3 lines

Merge rev 100626 from Asterisk 1.4.  The svnmerge of this commit was a NoOp, since
res_features doesn't exist in trunk.  Thanks to qwell for pointing it out!

................
r100632 | file | 2008-01-28 12:04:53 -0700 (Mon, 28 Jan 2008) | 2 lines

Fix up two scheduling issues. In one instance a scheduled item was not deleted when it should have been and in the other it was scheduled again when it shouldn't have been.

................
r100671 | file | 2008-01-28 13:40:08 -0700 (Mon, 28 Jan 2008) | 6 lines

Fix up some T38 state change issues.
(closes issue ASTERISK-11106)
Reported by: dimas
Patches:
     v2-sip-t38state.patch uploaded by dimas (license 88)

................
r100674 | mmichelson | 2008-01-28 13:58:12 -0700 (Mon, 28 Jan 2008) | 10 lines

Blocked revisions 100673 via svnmerge

........
r100673 | mmichelson | 2008-01-28 14:55:56 -0600 (Mon, 28 Jan 2008) | 3 lines

Undoing the deprecation of chan_vpb. It is alive and well.


........

................
r100676 | qwell | 2008-01-28 14:02:11 -0700 (Mon, 28 Jan 2008) | 16 lines

Merged revisions 100672 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

(closes issue ASTERISK-11263)
........
r100672 | qwell | 2008-01-28 14:42:43 -0600 (Mon, 28 Jan 2008) | 7 lines

When using ODBC_STORAGE, make sure we put greeting files into the database like we do with the others.

Issue ASTERISK-11263
Reported by: dimas
Patches:
     vmgreet.patch uploaded by dimas (license 88)

........

................
r100677 | tilghman | 2008-01-28 14:05:29 -0700 (Mon, 28 Jan 2008) | 10 lines

Merged revisions 100675 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r100675 | tilghman | 2008-01-28 15:02:02 -0600 (Mon, 28 Jan 2008) | 2 lines

WaitExten didn't handle AbsoluteTimeout properly (went to 't' instead of 'T')

........

................
r100678 | mmichelson | 2008-01-28 14:07:18 -0700 (Mon, 28 Jan 2008) | 3 lines

Re-inserting chan_vpb into trunk.


................
r100679 | qwell | 2008-01-28 14:11:24 -0700 (Mon, 28 Jan 2008) | 1 line

Reintroduce more chan_vpb stuff that was removed in r100421 and r100422
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=100881