[SR-Users] rtpengine returns 0.0.0.0 even with sendrecv in offer
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
___
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
Re: [SR-Users] rtpengine returns 0.0.0.0 even with sendrecv in offer
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. 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
Re: [SR-Users] rtpengine returns 0.0.0.0 even with sendrecv in offer
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 ___ 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
Re: [SR-Users] rtpengine returns 0.0.0.0 even with sendrecv in offer
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 ___ 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
Re: [SR-Users] rtpengine returns 0.0.0.0 even with sendrecv in offer
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 ___ 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
Re: [SR-Users] rtpengine returns 0.0.0.0 even with sendrecv in offer
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 ___ 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
Re: [SR-Users] rtpengine returns 0.0.0.0 even with sendrecv in offer
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 ___ 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
Re: [SR-Users] rtpengine returns 0.0.0.0 even with sendrecv in offer
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 ___ 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
