InnovateAsterisk / Browser-Phone

A fully featured browser based WebRTC SIP phone for Asterisk
https://www.innovateasterisk.com
GNU Affero General Public License v3.0
499 stars 245 forks source link

sip.Parser | error parsing header 'From' #473

Open sandeepshindeit opened 11 months ago

sandeepshindeit commented 11 months ago

The project is awesome!!, i tried on asterisk 20 it works for outgoing call and same for 16 and 18 as well, but the browser phone is not able to stay connected, is not able to receive call or message, but yes able to make and send message,

is it probably due to sip.Parser | error parsing header 'From'

In browser I see below

Connected to Web Socket! phone.js:2060 Sending Registration... sip-0.20.0.min.js:2 Sun Oct 15 2023 14:45:28 GMT+0530 (India Standard Time) | sip.Registerer | Waiting toggled to true sip-0.20.0.min.js:2 Sun Oct 15 2023 14:45:28 GMT+0530 (India Standard Time) | sip.Registerer | Registration transitioned to state Registered phone.js:1934 User Agent Registration State: Registered phone.js:2100 Registered! sip-0.20.0.min.js:2 Sun Oct 15 2023 14:45:28 GMT+0530 (India Standard Time) | sip.Registerer | Waiting toggled to false sip-0.20.0.min.js:2 Sun Oct 15 2023 14:45:28 GMT+0530 (India Standard Time) | sip.Parser | error parsing header 'From' print @ sip-0.20.0.min.js:2 genericLog @ sip-0.20.0.min.js:2 genericLog @ sip-0.20.0.min.js:2 error @ sip-0.20.0.min.js:2 e.parseMessage @ sip-0.20.0.min.js:2 onTransportMessage @ sip-0.20.0.min.js:2 transport.onMessage @ sip-0.20.0.min.js:2 onWebSocketMessage @ sip-0.20.0.min.js:2 (anonymous) @ sip-0.20.0.min.js:2 sip-0.20.0.min.js:2 Sun Oct 15 2023 14:45:28 GMT+0530 (India Standard Time) | sip.UserAgent | Failed to parse incoming message. Dropping.

on Server side i see for asterisk -rvvvvvvvvvv as below -- Removed contact 'sip:qa2jhlr2@49.37.161.89:49958;transport=ws' from AOR 'User1' due to request == Contact User1/sip:qa2jhlr2@49.37.161.89:49958;transport=ws has been deleted == WebSocket connection from '49.37.161.89:49970' for protocol 'sip' accepted using version '13' -- Added contact 'sip:tsvmlo9r@49.37.161.89:49970;transport=ws' to AOR 'User1' with expiration of 300 seconds -- Contact User1/sip:tsvmlo9r@49.37.161.89:49970;transport=ws is now Unreachable. RTT: 0.000 msec

looks like it gets added and then it becomes unreachable, is it because qa2jhlr2 and how to change this as ideally it should had been user1 or 100 but some alpha number is generated and added, is it correct how can this be fixed, 
sandeepshindeit commented 11 months ago

More details

when message sent from User2 to User1 the message is not received but able to see ws messages received in browser console as below

MESSAGE sip:s9lle5qu@49.37.161.89:50109;transport=ws SIP/2.0 Via: SIP/2.0/WSS 154.41.254.115:8089;rport;branch=z9hG4bKPjffba9af4-5a20-4811-b34d-4c180692ae01;alias From: "User2" sip:200@subdomain.domain.com;tag=5f089c5e-c06c-4ccd-acf3-796cbe092f3f To: sip:s9lle5qu@49.37.161.89 Contact: sip:User1@405903:5060;transport=ws Call-ID: 6273a227-0c9e-4402-8b15-f6276a8ba19d CSeq: 23829 MESSAGE Max-Forwards: 70 User-Agent: Asterisk PBX 16.0.0 Content-Type: text/plain Content-Length: 4

test

and in console getting below error sip.Parser | error parsing header 'Contact'

looks parser error

is this something has to be done at asterisk level or browser phone client side,

sandeepshindeit commented 11 months ago

Hey thanks i found the solution as below from_user=myusername from_domain=mydomain.com

by mentioning user and domain at endpoints this is resolved

InnovateAsterisk commented 11 months ago

Remember also that the browser doesn’t have access to the network stack, so it doesn’t know what it’s own ip address is. Normally this is resolved with STUN but this is only when a call is setup (as you mentioned outgoing calls work fine), however the STUN request isn’t used as part of the register process. So what happens is either the contact is populated with an “invalid” ip address, or an invalid ip address. Either way, you have to re-write the contact on your server, as packets can easily reach the server (via the established websocket “tunnel”), but you have to still let the server know the ip of the actual client of the endpoint.

When Asterisk completes a register (and if qualify is enabled), it performs an options ping to the newly registered endpoint. This is why the endpoint becomes unavailable directly after the register.