Hi!
Few days ago I was lucky to establish calls between Chrome and SIP UA. Thanks to new rtpproxy developers! That was for audio only because many UAs lack for VP8 support. To verify a video I tried to involve Jitsi into the tests. Mediaproxy can't rewrite answer SDP from Jitsi. Probably the issue is related to SDP but I'm not sure to which part in particularly.
*Original offer SDP (ICE attributes are skipped) *
v=0 o=- 6784329718950523193 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio video a=msid-semantic: WMS 0dKFIAlsVMexmIc0qjieYgfPDvBnSLG5lmpP m=audio 59996 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126 c=IN IP4 10.xx.xx.xx a=rtcp:59996 IN IP4 10.xx.xx.xx .... a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=sendrecv a=mid:audio a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:VZhAArr96fxUtzvuNPpE+OSa09wchsmTD9pdrdBv a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:107 CN/48000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:579751405 cname:n2gMzhLDYdqpWwP7 a=ssrc:579751405 msid:0dKFIAlsVMexmIc0qjieYgfPDvBnSLG5lmpP 0dKFIAlsVMexmIc0qjieYgfPDvBnSLG5lmpPa0 a=ssrc:579751405 mslabel:0dKFIAlsVMexmIc0qjieYgfPDvBnSLG5lmpP a=ssrc:579751405 label:0dKFIAlsVMexmIc0qjieYgfPDvBnSLG5lmpPa0 m=video 59996 RTP/SAVPF 100 116 117 c=IN IP4 10.xx.xx.xx a=rtcp:59996 IN IP4 10.xx.xx.xx ... a=extmap:2 urn:ietf:params:rtp-hdrext:toffset a=sendrecv a=mid:video a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:VZhAArr96fxUtzvuNPpE+OSa09wchsmTD9pdrdBv a=rtpmap:100 VP8/90000 a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 goog-remb a=rtpmap:116 red/90000 a=rtpmap:117 ulpfec/90000 a=ssrc:1190198390 cname:n2gMzhLDYdqpWwP7 a=ssrc:1190198390 msid:0dKFIAlsVMexmIc0qjieYgfPDvBnSLG5lmpP 0dKFIAlsVMexmIc0qjieYgfPDvBnSLG5lmpPv0 a=ssrc:1190198390 mslabel:0dKFIAlsVMexmIc0qjieYgfPDvBnSLG5lmpP a=ssrc:1190198390 label:0dKFIAlsVMexmIc0qjieYgfPDvBnSLG5lmpPv0
*Original answer SDP*
v=0 o=user2 0 0 IN IP4 10.xx.xx.xx s=- c=IN IP4 10.xx.xx.xx t=0 0 m=audio 5052 RTP/AVP 0 8 126 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:126 telephone-event/8000 m=video 5054 RTP/AVP 100 a=rtpmap:100 VP8/90000
*Mediaproxy logs* (for answer SDP)
mediaproxy-ng[14907]: Got valid command from 127.0.0.1:38310: answer .... mediaproxy-ng[14907]: [7dmpb0qdja07p87pa1ji - ] Got LOOKUP, but no usable callstreams found mediaproxy-ng[14907]: Error rewriting SDP mediaproxy-ng[14907]: Protocol error in packet from 127.0.0.1:38310: Error rewriting SDP:...
However the *audio calls work well*. Here's the answer SDP from Jitsi:
v=0 o=user2 0 0 IN IP4 10.xx.xx.xx s=- c=IN IP4 10.xx.xx.xx t=0 0 m=audio 5048 RTP/AVP 0 8 126 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:126 telephone-event/8000
Comments and suggestions would be greatly appreciated.
regards, Alexey
On 08/01/13 09:10, Alexey Rybalko wrote:
Hi!
Few days ago I was lucky to establish calls between Chrome and SIP UA. Thanks to new rtpproxy developers! That was for audio only because many UAs lack for VP8 support. To verify a video I tried to involve Jitsi into the tests. Mediaproxy can't rewrite answer SDP from Jitsi. Probably the issue is related to SDP but I'm not sure to which part in particularly.
Hi,
This is a known issue with mediaproxy-ng. The problem is that Chrome multiplexes both media streams on the same port and mediaproxy-ng currently doesn't handle this case correctly. I'm working on a fix, but it's a major change and will take a little while.
cheers
Richard, thank you for the quick response! Waiting for the fix.
best regards, Alexey
01.08.2013 17:45 пользователь "Richard Fuchs" rfuchs@sipwise.com написал:
On 08/01/13 09:10, Alexey Rybalko wrote:
Hi!
Few days ago I was lucky to establish calls between Chrome and SIP UA. Thanks to new rtpproxy developers! That was for audio only because many UAs lack for VP8 support. To verify a video I tried to involve Jitsi into the tests. Mediaproxy can't rewrite answer SDP from Jitsi. Probably the issue is related to SDP but I'm not sure to which part in
particularly.
Hi,
This is a known issue with mediaproxy-ng. The problem is that Chrome
multiplexes both media streams on the same port and mediaproxy-ng currently doesn't handle this case correctly. I'm working on a fix, but it's a major change and will take a little while.
cheers
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users