Summary:ASTERISK-20238: Registering SIP user from JavaScript sipML5 client fails when random ".invalid" domain sent in Contact header
Reporter:James Mortensen (james.mortensen)Labels:
Date Opened:2012-08-15 16:12:05Date Closed:2012-08-17 14:58:07
Versions:11.0.0-beta1 Frequency of
is related toASTERISK-19716 Don't validate Contact URI hostpart when nat=yes
Environment:Attachments:( 0) sip_call_attempt.txt
Description:According to the spec, the JavaScript SIP client should send a random ".invalid" domain in the Contact header, since the JavaScript implementation has no way to determine the IP address or the port to send.

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.