< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate-users] Issues building WebRTC branch





On 21/03/13 19:40, Nathan Stratton wrote:
> I went back and tried resiprocate 9737 with the original webrtc patch and
> don't have any issues, however with the latest resiprocate b-webrtc branch
> I am still seeing issues with contact length.
> 


The original webrtc patch against r9737 had a number of hacks to
suppress some problems like these.

I've removed all code that masks these issues, and we need to develop
proper solutions to support things like the `*.invalid' URIs that appear
in a webrtc session.

I posted an email on the list with my observations:

http://list.resiprocate.org/archive/resiprocate-devel/msg08208.html

I haven't observed the same crash that you have below.  Which client are
you using?  Can you post the full SIP messages (both the request and the
response)?

> INFO | 20130321-183833.863 | repro | RESIP | 47440478557952 |
> SipMessage.cxx:931 | Content Length (4419) is 3461 bytes larger than body
> (958)! (We are supposed to 400 this)
> DEBUG | 20130321-183833.863 | repro | RESIP:TRANSPORT | 47440478557952 |
> Transport.cxx:382 | incoming from: [ V4 75.148.206.241:58290 WS target
> domain=unspecified mFlowKey=34 ]
> DEBUG | 20130321-183833.863 | repro | RESIP:TRANSPORT | 47440478557952 |
> Connection.cxx:401 | Connection::performReads()  read=1448
> INFO | 20130321-183833.863 | repro | RESIP:TRANSPORT | 47440478557952 |
> TcpConnection.cxx:42 | No data ready to read
> DEBUG | 20130321-183833.863 | repro | RESIP | 47440476456704 |
> Helper.cxx:373 | Helper::makeResponse(SipReq:  INVITE
> 1000@204.117.64.121tid=5431563 cseq=9253 INVITE
> contact=7hiindve@sfj5jrha5fb4.invalid/ 9253 from(wire) code=400
> reason=
> Segmentation fault (core dumped)
> 
> 
> 
> On Mon, Mar 18, 2013 at 8:18 PM, Nathan Stratton <nathan@xxxxxxxxxxxx>wrote:
> 
>> I am seeing errors with the r-webrtc branch that I am not seeing when I
>> test with the old patch:
>>
>> INFO | 20130319-010544.924 |  | RESIP:TRANSPORT | 140582035765312 |
>> Connection.cxx:38 | Connection::Connection: new connection created to who:
>> [ V4 75.148.206.241:42039 WS target domain=unspecified mFlowKey=45 ]
>> INFO | 20130319-010545.024 |  | RESIP:TRANSPORT | 140582035765312 |
>> TcpConnection.cxx:42 | No data ready to read
>> INFO | 20130319-010545.625 |  | RESIP:TRANSPORT | 140582035765312 |
>> TcpConnection.cxx:72 | Connection closed by remote CONN: 0x11f7ae0 45 [ V4
>> 75.148.206.241:42039 WS target domain=unspecified mFlowKey=45 ]
>> INFO | 20130319-010545.826 |  | RESIP:TRANSPORT | 140582035765312 |
>> Connection.cxx:38 | Connection::Connection: new connection created to who:
>> [ V4 75.148.206.241:42046 WS target domain=unspecified mFlowKey=45 ]
>> INFO | 20130319-010545.926 |  | RESIP:TRANSPORT | 140582035765312 |
>> TcpConnection.cxx:42 | No data ready to read
>> INFO | 20130319-010614.189 |  | RESIP | 140582035765312 |
>> SipMessage.cxx:931 | Content Length (4641) is 1023 bytes larger than body
>> (3618)! (We are supposed to 400 this)
>>
>> I also saw the same issue with repro as well as:
>>
>> DEBUG | 20130319-011554.667 | repro | RESIP:TRANSPORT | 140585077786368 |
>> TcpBaseTransport.cxx:263 | Processing write for [ V4 75.148.206.241:43312WS 
>> target domain=unspecified mFlowKey=33 ]
>> DEBUG | 20130319-011554.667 | repro | RESIP:TRANSPORT | 140585077786368 |
>> ConnectionManager.cxx:59 | Found fd 33
>> INFO | 20130319-011554.668 | repro | RESIP:TRANSPORT | 140585077786368 |
>> TcpConnection.cxx:58 | buf is outside your accessible address space.
>> INFO | 20130319-011554.668 | repro | RESIP:TRANSPORT | 140585077786368 |
>> TcpConnection.cxx:65 | Failed read on 33 Bad address
>> INFO | 20130319-011554.668 | repro | RESIP:TRANSPORT | 140585077786368 |
>> Transport.cxx:101 | buf is outside your accessible address space : Bad
>> address
>>
>>
>> On Mon, Mar 18, 2013 at 6:09 PM, Nathan Stratton <nathan@xxxxxxxxxxxx>wrote:
>>
>>> So sorry man...... I need to sleep more.
>>>
>>
>> --
>>> <>
>> Nathan Stratton
>> nathan at robotics.net
>> http://www.robotics.net
>>
> 
> 
>