|Reporter:||James Mortensen (james.mortensen)||Labels:|
|Date Opened:||2012-08-15 16:12:05||Date Closed:||2012-08-17 14:58:07|
|Environment:||Attachments:||( 0) sip_call_attempt.txt|
It seems that the Asterisk server should instead use the existing port 8088 to send WebSocket responses back to the client; however, the end result is a 400 Bad Request.
If I send my hard-coded IP address, I see a 200 OK message. I've also tried seeing the nat=no setting in sip.conf.
|Comments:||By: James Mortensen (james.mortensen) 2012-08-15 18:10:44.154-0500|
I've attached the DEBUG information from a call attempt. I can register with nat=yes option and the nat=yes, force_rport options. However, the call attempt from sipML5 results in a 488 Status code.
It sounds like it could be an encoding problem, but I'm not 100% sure.
By: Joshua C. Colp (jcolp) 2012-08-17 14:53:38.037-0500
I've fixed the underlying issue here in subversion for 11 as of revision 371482 and trunk as of revision 371483. One other thing you will need is "avpf=yes" in the entry in sip.conf for the client. Putting this all together though still has things not working properly. Unfortunately while the Chrome team have made progress in further conforming to the official ICE specification they still have a little ways to go. The produced SDP is now close enough to what it should be to be parsed by us, but the actual outgoing packets to Chrome are ignored by it. It doesn't even return an error.
Additionally I will be working on documenting things on the wiki.