ProvisionVoiceAccountRequest response has old Vivox data inside
needs info
Glaznah Gassner
We are developing a voice support for SpeedLight (web SL viewer). The ProvisionVoiceAccountRequest cap request gives unexpected response.
The LLSD data being sent:
<llsd>
<map>
<key>jsep</key>
<map>
<key>type</key>
<string>offer</string>
<key>sdp</key>
<string>-a-lot-of-sdp-data-here-</string>
</map>
<key>parcel_local_id</key>
<integer>2</integer>
<key>channel_type</key>
<string>local</string>
<key>voice_server_type</key>
<string>webrtc</string>
</map>
</llsd>
According to https://wiki.secondlife.com/wiki/WebRTC_Voice the response contains jsep. Instead of expected
<key>jsep</key>
response we get old Vivox data:{"password":"...","username":"...","voice_account_server_name":"https://www.bhd.vivox.com/api2/","voice_sip_uri_hostname":"bhd.vivox.com"}
(dumped it as JSON)
Tried it both in webRTC1 and webRTC2. What may be a reason of missing webrtc response?
Log In
MelanieCosti Resident
Hello, Developping the webrtc support for Genesis viewer, I get the same problem
I am on webrtc2 region and this is the LLSD for this region
2024-07-20T13:44:26Z INFO: LLViewerRegion::setSimulatorFeatures: region WebRTC Voice 2 <llsd>
<map>
<key>AnimatedObjects</key>
<map>
<key>AnimatedObjectMaxTris</key>
<integer>100000</integer>
<key>MaxAgentAnimatedObjectAttachments</key>
<integer>2</integer>
</map>
<key>AvatarHoverHeightEnabled</key>
<boolean>1</boolean>
<key>BakesOnMeshEnabled</key>
<boolean>1</boolean>
<key>DeadReckoningDistance</key>
<real>20</real>
<key>DeadReckoningTime</key>
<real>1</real>
<key>DynamicPathfindingEnabled</key>
<boolean>1</boolean>
<key>HostName</key>
<string>simhost-0907b59fedca3f5c1.agni.secondlife.io</string>
<key>LSLSyntaxId</key>
<uuid>20223055-8449-5b68-0111-f4307e77b81d</uuid>
<key>MaxAgentAttachments</key>
<integer>38</integer>
<key>MaxAgentGroups</key>
<integer>70</integer>
<key>MaxAgentGroupsBasic</key>
<integer>42</integer>
<key>MaxAgentGroupsPremium</key>
<integer>70</integer>
<key>MaxEstateAccessIds</key>
<integer>750</integer>
<key>MaxEstateManagers</key>
<integer>20</integer>
<key>MaxMaterialsPerTransaction</key>
<integer>50</integer>
<key>MaxTextureResolution</key>
<integer>2048</integer>
<key>MeshRezEnabled</key>
<boolean>1</boolean>
<key>MeshUploadEnabled</key>
<boolean>1</boolean>
<key>MeshXferEnabled</key>
<boolean>1</boolean>
<key>MirrorsEnabled</key>
<boolean>1</boolean>
<key>PBRMaterialSwatchEnabled</key>
<boolean>1</boolean>
<key>PBRTerrainEnabled</key>
<boolean>1</boolean>
<key>PhysicsMaterialsEnabled</key>
<boolean>1</boolean>
<key>PhysicsShapeTypes</key>
<map>
<key>convex</key>
<boolean>1</boolean>
<key>none</key>
<boolean>1</boolean>
<key>prim</key>
<boolean>1</boolean>
</map>
<key>RenderMaterialsCapability</key>
<real>4</real>
<key>VoiceServerType</key>
<string>webrtc</string>
</map>
</llsd>
so we are on a webrtc voiceservertype.
The cap I receive for this region and ProvisionVoiceAccountRequest cap is
I do a post curl call with this LLSD :
<llsd><map><key>channel_type</key><string>local</string><key>jsep</key><map><key>sdp</key><string>v=0
o=- 2823553196765899670 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=msid-semantic: WMS SLStream
m=audio 9 UDP/TLS/RTP/SAVPF 111 63 9 102 0 8 13 110 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:hcF0
a=ice-pwd:<masked>
a=ice-options:trickle
a=fingerprint:<masked>
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendrecv
a=msid:SLStream SLAudio
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=fmtp:111 minptime=10;useinbandfec=1;stereo=1;sprop-stereo=1;maxplaybackrate=48000;sprop-maxplaybackrate=48000;sprop-maxcapturerate=48000
a=rtpmap:63 red/48000/2
a=fmtp:63 111/111
a=rtpmap:9 G722/8000
a=rtpmap:102 ILBC/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:126 telephone-event/8000
a=ssrc:2266921868 cname:x2w2VVaf+SNlmjkU
a=ssrc:2266921868 msid:SLStream SLAudio
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=ice-ufrag:hcF0
a=ice-pwd:<masked>
a=ice-options:trickle
a=fingerprint:<masked>
a=setup:actpass
a=mid:1
a=sctp-port:5000
a=max-message-size:262144
</string><key>type</key><string>offer</string></map><key>voice_server_type</key><string>webrtc</string></map></llsd>
the response I get looks like a vivox reply (http status 200)
requestVoiceConnection successed
<llsd><map><key>password</key><string>masked</string><key>username</key><string>masked</string><key>voice_account_server_name</key><string>https://www.bhr.vivox.com/api2/</string><key>voice_sip_uri_hostname</key><string>bhr.vivox.com</string></map></llsd>
What am I doing wrong?
Signal Linden
needs info
Roxie Linden
That's odd, that should be correct. What's the exact URL you're sending the request too (including hostname, port, etc.?)
Have you attempted to implement the cross-region voice yet? If that's the case, you'll get vivox results back from the neighboring Vivox regions, which technically isn't optimal, but on the main grid we likely not end up in that situation given rollout plans.
MelanieCosti Resident
Roxie Linden
I gave an example for the same issue encountered on Genesis Viewer.
Thanks in advance for any help
MelanieCosti Resident
finally found a way to make it work. problem with the body format in the post.Maybe the API should reply something else than 200 when the body is wrong