i got mozilla to generate sdp with sendrecv, but still rtpengine does not replace 0.0.0.0 address on o and c lines. why?
-- juha
Dec 19 10:20:18 box /usr/bin/sip-proxy[5841]: INFO: ===== rtpengine_offer(ICE=force replace-session-connection replace-origin via-branch=1) Dec 19 10:20:18 box rtpengine[20171]: Got valid command from 127.0.0.1:39586: offer - { "sdp": "v=0#015#012o=Mozilla-SIPUA-34.0 25949 0 IN IP4 0.0.0.0#015#012s=SIP Call#015#012t=0 0#015#012a=ice-ufrag:f5511cb8#015#012a=ice-pwd:1d062e6b56db4f738c7613bc97086194#015#012a=fingerprint:sha-256 45:CA:2E:A5:12:4E:80:0C:AD:9D:11:94:C5:2D:ED:15:55:FD:83:70:91:59:3D:57:3D:F9:A5:77:74:85:BD:E8#015#012m=audio 9 RTP/SAVPF 109 9 0 8 101#015#012c=IN IP4 0.0.0.0#015#012a=rtpmap:109 opus/48000/2#015#012a=ptime:20#015#012a=rtpmap:9 G722/8000#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:101 telephone-event/8 ... Dec 19 10:20:18 box rtpengine[20171]: ... 000#015#012a=fmtp:101 0-15#015#012a=sendrecv#015#012a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level#015#012a=setup:actpass#015#012a=rtcp-mux#015#012a=candidate:0 1 UDP 2122252543 192.168.1.52 42190 typ host#015#012a=candidate:0 2 UDP 2122252542 192.168.1.52 54801 typ host#015#012a=candidate:1 1 UDP 1686110207 192.98.100.128 42190 typ srflx raddr 192.168.1.52 rport 42190#015#012a=candidate:1 2 UDP 1686110206 192.98.100.128 54801 typ srflx raddr 192.168.1.52 rport 54801#015#012", "ICE": "force", "replace": [ "session-connection", "origin" ], "call-i ... Dec 19 10:20:18 box rtpengine[20171]: ... d": "lr92g1vkbkvmgdt9m1dg", "via-branch": "z9hG4bK2313203", "received-from": [ "IP4", "192.98.100.128" ], "from-tag": "d03ug77pi6", "command": "offer" } Dec 19 10:20:18 box rtpengine[20171]: [lr92g1vkbkvmgdt9m1dg] Creating new call Dec 19 10:20:18 box rtpengine[20171]: [lr92g1vkbkvmgdt9m1dg] Opened ports 8056..8057 for media relay Dec 19 10:20:18 box rtpengine[20171]: [lr92g1vkbkvmgdt9m1dg] Opened ports 8012..8013 for media relay Dec 19 10:20:18 box rtpengine[20171]: [lr92g1vkbkvmgdt9m1dg] Returning to SIP proxy: d3:sdp725:v=0#015#012o=Mozilla-SIPUA-34.0 25949 0 IN IP4 0.0.0.0#015#012s=SIP Call#015#012t=0 0#015#012a=ice-lite#015#012m=audio 8056 RTP/SAVPF 109 9 0 8 101#015#012c=IN IP4 0.0.0.0#015#012a=rtpmap:109 opus/48000/2#015#012a=ptime:20#015#012a=rtpmap:9 G722/8000#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101 0-15#015#012a=sendrecv#015#012a=rtcp:8057#015#012a=rtcp-mux#015#012a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:8FwYLdKkGvVH4Ykc+kTgrFN1Cwz0KZVpT2JK7+g0#015#012a=setup:actpass#015#012a=fingerprint:sha-1 ED:DE:59:BA:F7 ... Dec 19 10:20:18 box rtpengine[20171]: [lr92g1vkbkvmgdt9m1dg] ... :F8:78:9D:1D:78:42:AA:00:6C:88:85:A4:2B:36:42#015#012a=ice-ufrag:4dmKpmV3#015#012a=ice-pwd:75jY5mekvVULGZnnB9mJmHQoVa9i#015#012a=candidate:bVSyZZLCFRG94R1D 1 UDP 2130706431 192.26.111.29 8056 typ host#015#012a=candidate:bVSyZZLCFRG94R1D 2 UDP 2130706430 192.26.111.29 8057 typ host#015#0126:result2:oke
Richard Fuchs writes:
On 12/19/14 03:32, Juha Heinanen wrote:
i got mozilla to generate sdp with sendrecv, but still rtpengine does not replace 0.0.0.0 address on o and c lines. why?
Because 0.0.0.0 means steam is on hold and so should be left in place.
what i understand from rfc3264 is that 0.0.0.0 address in initial invite does not mean that the call is on hold. 0.0.0.0 is used because webrtc client does not know its ip address:
RFC 2543 [10] specified that placing a user on hold was accomplished by setting the connection address to 0.0.0.0. Its usage for putting a call on hold is no longer recommended, since it doesn't allow for RTCP to be used with held streams, doesn't work with IPv6, and breaks with connection oriented media. However, it can be useful in an initial offer when the offerer knows it wants to use a particular set of media streams and formats, but doesn't know the addresses and ports at the time of the offer.
also, if the call would on hold, there would be sendonly attribute in the sdp, which is not the case in my example, which had sendrecv.
-- juha
On 12/19/14 09:33, Juha Heinanen wrote:
Richard Fuchs writes:
On 12/19/14 03:32, Juha Heinanen wrote:
i got mozilla to generate sdp with sendrecv, but still rtpengine does not replace 0.0.0.0 address on o and c lines. why?
Because 0.0.0.0 means steam is on hold and so should be left in place.
what i understand from rfc3264 is that 0.0.0.0 address in initial invite does not mean that the call is on hold. 0.0.0.0 is used because webrtc client does not know its ip address:
RFC 2543 [10] specified that placing a user on hold was accomplished by setting the connection address to 0.0.0.0. Its usage for putting a call on hold is no longer recommended, since it doesn't allow for RTCP to be used with held streams, doesn't work with IPv6, and breaks with connection oriented media. However, it can be useful in an initial offer when the offerer knows it wants to use a particular set of media streams and formats, but doesn't know the addresses and ports at the time of the offer.
also, if the call would on hold, there would be sendonly attribute in the sdp, which is not the case in my example, which had sendrecv.
Yes I understand, but 1) the mechanism of using 0.0.0.0 to put a call on hold must remain operational and intact for those clients which use it, and 2) if the offering client sends 0.0.0.0 in the SDP, then the rewritten SDP should also contain 0.0.0.0, no matter what the purpose behind it is.
cheers
Richard Fuchs writes:
Yes I understand, but 1) the mechanism of using 0.0.0.0 to put a call on hold must remain operational and intact for those clients which use it, and 2) if the offering client sends 0.0.0.0 in the SDP, then the rewritten SDP should also contain 0.0.0.0, no matter what the purpose behind it is.
So with current implementation of rtpengine there is no hope if Firefox webrtc client needs rtpengine services?
If so, would it be possible have a new flag that tells rtpengine to replace also 0.0.0.0 address if there is no sendonly attribute in sdp?
-- Juha
On 12/19/14 10:02, Juha Heinanen wrote:
Richard Fuchs writes:
Yes I understand, but 1) the mechanism of using 0.0.0.0 to put a call on hold must remain operational and intact for those clients which use it, and 2) if the offering client sends 0.0.0.0 in the SDP, then the rewritten SDP should also contain 0.0.0.0, no matter what the purpose behind it is.
So with current implementation of rtpengine there is no hope if Firefox webrtc client needs rtpengine services?
If so, would it be possible have a new flag that tells rtpengine to replace also 0.0.0.0 address if there is no sendonly attribute in sdp?
I don't see how it would make a difference. If Firefox sends 0.0.0.0 and rtpengine replaces it with its own address, then the receiving client can send media to rtpengine, but rtpengine would have nowhere to forward it to. After the answer, ICE processing may commence and determine an IP address, after which I expect Firefox to send an updated offer with the address filled in. At this point, media should start to flow no matter what.
I'm not sure how much of a valid use-case this is, or if it'd be just a Firefox-specific workaround, but my all means, give it a try and see if it makes a difference.
cheers
Richard Fuchs writes:
I don't see how it would make a difference. If Firefox sends 0.0.0.0 and rtpengine replaces it with its own address, then the receiving client can send media to rtpengine, but rtpengine would have nowhere to forward it to. After the answer, ICE processing may commence and determine an IP address, after which I expect Firefox to send an updated offer with the address filled in. At this point, media should start to flow no matter what.
I'm not sure how much of a valid use-case this is, or if it'd be just a Firefox-specific workaround, but my all means, give it a try and see if it makes a difference.
i found this on jssip mailing list:
Just a side note; FF34 does offer the value '0.0.0.0' as the media connectiom address, and the value 9 as the media port. This way it announces the support for ICE Trickle.
Media servers not aware of this will take it as a 'hold' request and wont send media to the peer.
-- juha
On 12/19/14 11:39, Juha Heinanen wrote:
Richard Fuchs writes:
I don't see how it would make a difference. If Firefox sends 0.0.0.0 and rtpengine replaces it with its own address, then the receiving client can send media to rtpengine, but rtpengine would have nowhere to forward it to. After the answer, ICE processing may commence and determine an IP address, after which I expect Firefox to send an updated offer with the address filled in. At this point, media should start to flow no matter what.
I'm not sure how much of a valid use-case this is, or if it'd be just a Firefox-specific workaround, but my all means, give it a try and see if it makes a difference.
i found this on jssip mailing list:
Just a side note; FF34 does offer the value '0.0.0.0' as the media connectiom address, and the value 9 as the media port. This way it announces the support for ICE Trickle.
Media servers not aware of this will take it as a 'hold' request and wont send media to the peer.
Oh dear, another IETF draft...
Well that certainly explains, thanks. Doesn't look like Firefox is quite finished with it yet though, as ice-options=trickle isn't given.
cheers
-
Juha Heinanen -
Richard Fuchs