Re: [Doubango] enable_rtcweb_breaker: false - Via header wrong?

[Mamadou]

Before going deeper just have 1 question: why are you using 2 webrtc2sip instances?
If you enable RTCWeb Breaker only g711 and VP8 will be used when the caller is a browser as it's the only common codecs (amr, ilbc, gsm, g729, g722,h263,h264... are not supported by chrome/firefox). If you want all codecs you'll need to enable the media coder for transcoding.
In your case webrtc2sip is useless as both RTCWeb Breaker and Media Coder are disabled. The only enabled module is SIP Proxy and it's useless as Kamailo support WebSocket transport. If I was you, I'd not use webrtc2sip.

On 3/25/2013 3:13 PM, Robert wrote:

Hi,

We are trying to establish a video call between two browsers that connect to a Kamailio SIP proxy via the webrtc2sip proxy. In order to have all codecs available, the browser's SIP stack is initialized with enable_rtcweb_breaker: false (otherwise the breaker seems to strip out all audio codecs except G711). 

When we do this, something goes wrong with the SIP signaling. To illustrate, the flow of one INVITE is this:

Browser 1 --> webrtc2sip --> Kamailo --> webrtc2sip --> Browser 2

What we see is this:

1)

Browser 1 sends INVITE with 

Via 1: Websocket connection to webrtc2sip

2)

Browser 2 receives INVITE with

Via 1: UDP connection to webrtc2sip

Via 2: UDP connection to Kamailio SIP proxy

Via 3: Websocket connection from browser

recv=INVITE sip:18...@192.168.1.14:5061;rtcweb-breaker=no;transport=udp;ws-src-ip=192.168.1.1;ws-src-port=55127;ws-src-proto=ws SIP/2.0 Via: SIP/2.0/UDP 192.168.1.12;branch=z9hG4bK2775.8df06621.3 From: <sip:18...@sip.test>;tag=kCaEkW7HeXxiauhz4GRB To: <sip:1891@sip.test> Contact: "1890"<sip:18...@192.168.1.14:5061;rtcweb-breaker=no;transport=udp;ws-src-ip=192.168.1.1;ws-src-port=55125;ws-src-proto=ws>;+g.oma.sip-im;+sip.ice;language="en,de" Call-ID: 63b1a0fb-e587-4ab2-06e1-a8aeef2c54dd CSeq: 34974 INVITE Content-Type: application/sdp Content-Length: 2721 Record-Route: <sip:192.168.1.12;lr=on> Via: SIP/2.0/UDP 192.168.1.14:5061;rport=5061;branch=z9hG4bKVP86O9sWZx0iRUDvt1Tw74tDzo4CxHDI Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.0.0.0-Laboratories Organization: Lab Via: SIP/2.0/TCP 192.168.1.1:55125;rport;branch=z9hG4bKVP86O9sWZx0iRUDvt1Tw74tDzo4CxHDI;ws-hacked=WS

Via 1 is incorrect - it should be a Websocket connection to webrtc2sip. The correct set would be:

(Via 4) Browser 1 WS --> (Via 3) Breaker UDP --->  (Via 2) Kamailio UDP ---> (Via 1) Breaker WS

When Browser 2 sends a 200 OK, it uses the incorrect Via set above. The webrtc2sip proxy receives the 200 OK and seems to discard it because the Via 1 does not point to the Websocket connection. 

The 200 OK never reaches Browser 2, so the session cannot be established.

Does anyone have similar experiences with Brwoser-to-Browser or have we messed up the configuration somehow?

Any help would be very appreciated!

Thanks,

Robert

--
You received this message because you are subscribed to the Google Groups "discuss-doubango" group.
To unsubscribe from this group and stop receiving emails from it, send an email to doubango+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Mamadou DIOP - Technology Evangelist
Doubango Telecom - Paris, France
http://www.doubango.org
Click here to call me!

[Robert]

Hi Mamadou,

Yes, you are absolutely right. Originally, we wanted to do just that - doing Browser-to-Browser calls with the breaker enabled. Unfortunately, we get a similar protocol issue when doing this: The call seems to be established because the breaker acts as a b2bua for both browsers - but after a short time the session is closed by the breaker (sends BYE). A trace shows that the ACK for the 200 OK is somehow not associated with it (so 200 OK is sent repeatedly). I cannot give the exact details as I do not have the trace at hand.

Anyhow, perhaps you have some good tips for me about what has to be configured so that Browser-to-Browser via the breaker works? Perhaps I misconfigured something completely? We normally use the breaker for PSTN calls via the Kamailo and a voice gateway and that works absolutely fine - we just run into problems whenever two browsers want to communicate directly.

Am Montag, 25. März 2013 15:47:40 UTC+1 schrieb Mamadou:

Before going deeper just have 1 question: why are you using 2 webrtc2sip instances?
If you enable RTCWeb Breaker only g711 and VP8 will be used when the caller is a browser as it's the only common codecs (amr, ilbc, gsm, g729, g722,h263,h264... are not supported by chrome/firefox). If you want all codecs you'll need to enable the media coder for transcoding.
In your case webrtc2sip is useless as both RTCWeb Breaker and Media Coder are disabled. The only enabled module is SIP Proxy and it's useless as Kamailo support WebSocket transport. If I was you, I'd not use webrtc2sip.

On 3/25/2013 3:13 PM, Robert wrote:

Hi,

We are trying to establish a video call between two browsers that connect to a Kamailio SIP proxy via the webrtc2sip proxy. In order to have all codecs available, the browser's SIP stack is initialized with enable_rtcweb_breaker: false (otherwise the breaker seems to strip out all audio codecs except G711). 

When we do this, something goes wrong with the SIP signaling. To illustrate, the flow of one INVITE is this:

Browser 1 --> webrtc2sip --> Kamailo --> webrtc2sip --> Browser 2

What we see is this:

1)

Browser 1 sends INVITE with 

Via 1: Websocket connection to webrtc2sip

2)

Browser 2 receives INVITE with

Via 1: UDP connection to webrtc2sip

Via 2: UDP connection to Kamailio SIP proxy

Via 3: Websocket connection from browser

recv=INVITE sip:...@192.168.1.14:5061;rtcweb-breaker=no;transport=udp;ws-src-ip=192.168.1.1;ws-src-port=55127;ws-src-proto=ws SIP/2.0 Via: SIP/2.0/UDP 192.168.1.12;branch=z9hG4bK2775.8df06621.3 From: <sip...@sip.test>;tag=kCaEkW7HeXxiauhz4GRB To: <sip:1891@sip.test> Contact: "1890"<sip:...@192.168.1.14:5061;rtcweb-breaker=no;transport=udp;ws-src-ip=192.168.1.1;ws-src-port=55125;ws-src-proto=ws>;+g.oma.sip-im;+sip.ice;language="en,de" Call-ID: 63b1a0fb-e587-4ab2-06e1-a8aeef2c54dd CSeq: 34974 INVITE Content-Type: application/sdp Content-Length: 2721 Record-Route: <sip:192.168.1.12;lr=on> Via: SIP/2.0/UDP 192.168.1.14:5061;rport=5061;branch=z9hG4bKVP86O9sWZx0iRUDvt1Tw74tDzo4CxHDI Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.0.0.0-Laboratories Organization: Lab Via: SIP/2.0/TCP 192.168.1.1:55125;rport;branch=z9hG4bKVP86O9sWZx0iRUDvt1Tw74tDzo4CxHDI;ws-hacked=WS

Via 1 is incorrect - it should be a Websocket connection to webrtc2sip. The correct set would be:

(Via 4) Browser 1 WS --> (Via 3) Breaker UDP --->  (Via 2) Kamailio UDP ---> (Via 1) Breaker WS

When Browser 2 sends a 200 OK, it uses the incorrect Via set above. The webrtc2sip proxy receives the 200 OK and seems to discard it because the Via 1 does not point to the Websocket connection. 

The 200 OK never reaches Browser 2, so the session cannot be established.

Does anyone have similar experiences with Brwoser-to-Browser or have we messed up the configuration somehow?

Any help would be very appreciated!

Thanks,

Robert

--
You received this message because you are subscribed to the Google Groups "discuss-doubango" group.
To unsubscribe from this group and stop receiving emails from it, send an email to doubango+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Mamadou]

We're doing browser-to-browser and it works without any issue. Off course we don't have two webrtc2sip instances like you and don't know why you need them.
You should open a ticket in the tracker and attach the logs.
Don't know what's your Doubango SVN revision but highly recommend using latest.

[Robert]

Thanks a lot for your help so far. One important question: How did you get the impression that we have two webrtc2sip instances running? We have only one that has the breaker enabled... is this a hint to our problem? 

[Mamadou]

How did you get the impression that we have two webrtc2sip instances running? We have only one that has the breaker enabled... is this a hint to our problem?

On 3/25/2013 4:22 PM, Robert wrote:

Browser 1 --> webrtc2sip --> Kamailo --> webrtc2sip --> Browser 2