2 Jun
2017
2 Jun
'17
2:40 p.m.
Hi!
I’m trying to make RTPEngine to work with calls Browser <-> SIP.
Call From SIP to Browser working perfectly, but when calling to SIP from Browser, on 200
OK (sdp) I don’t receive
...
a=rtcp-mux
...
lines, but it was told to RTPEngine on reply_route to add this. And this line is mandatory
for me, cause I don’t control JS softphone on other side
Reply route in a case of Browser->SIP call looks like
reply_route[REPLY_R] {
…
rtpengine_answer("internal external UDP/TLS/RTP/SAVPF ICE=force
rtcp-mux-offer");
...
}
Also I’ve tried with rtcp-mux-accept but still no luck
Regards, Igor
2 Jun
2 Jun
2:56 p.m.
On 02/06/17 07:40 AM, Igor Olhovskiy wrote:
Hi!
I’m trying to make RTPEngine to work with calls Browser <-> SIP.
Call From SIP to Browser working perfectly, but when calling to SIP
from Browser, on 200 OK (sdp) I don’t receive
...
a=rtcp-mux
...
lines, but it was told to RTPEngine on reply_route to add this. And
this line is mandatory for me, cause I don’t control JS softphone on
other side
Reply route in a case of Browser->SIP call looks like
reply_route[REPLY_R] {
…
rtpengine_answer("internal external UDP/TLS/RTP/SAVPF ICE=force
rtcp-mux-offer");
...
}
Also I’ve tried with rtcp-mux-accept but still no luck
You cannot "offer" rtcp-mux an in "answer".
I believe what you want is to use rtcp-mux-demux in the offer.
Cheers
3:01 p.m.
Getting same result..
v=0
o=- 1334974643 4 IN IP4 X.X.X.X
c=IN IP4 X.X.X.X
t=0 0
m=audio 41572 UDP/TLS/RTP/SAVPF 0 9 126
a=rtpmap:0 PCMU/8000
a=rtpmap:9 G722/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
a=rtcp:41573
a=setup:active
a=fingerprint:sha-1 79:28:0E:B7:44:65:8F:69:9A:B5:A6:A4:FF:79:A8:78:51:X:X:X
a=ice-ufrag:skh8lj8m
a=ice-pwd:FE5tjyUuBmWDaVhE3zcsYgZr52
a=candidate:YLrFRpDB3kwIFygB 1 UDP 2130706431 120.76.27.231 41572 typ host
a=candidate:YLrFRpDB3kwIFygB 2 UDP 2130706430 120.76.27.231 41573 typ host
m=video 0 UDP/TLS/RTP/SAVPF 96 98 100 102 127 97 99 101 125
c=IN IP4 X.X.X.X
Regards, Igor
On 2 июня 2017 г., 14:57 +0300, Richard Fuchs <rfuchs(a)sipwise.com>om>, wrote:
On 02/06/17 07:40 AM, Igor Olhovskiy wrote:
Hi!
I’m trying to make RTPEngine to work with calls Browser <-> SIP.
Call From SIP to Browser working perfectly, but when calling to SIP from Browser, on 200
OK (sdp) I don’t receive
...
a=rtcp-mux
...
lines, but it was told to RTPEngine on reply_route to add this. And this line is
mandatory for me, cause I don’t control JS softphone on other side
Reply route in a case of Browser->SIP call looks like
reply_route[REPLY_R] {
…
rtpengine_answer("internal external UDP/TLS/RTP/SAVPF ICE=force
rtcp-mux-offer");
...
}
Also I’ve tried with rtcp-mux-accept but still no luck
You cannot "offer" rtcp-mux an in "answer".
I believe what you want is to use rtcp-mux-demux in the offer.
Cheers
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
3:05 p.m.
Fixed.
In relay route added in
rtpengine_offer rtcp-mux-demux option.
Regards, Igor
On 2 июня 2017 г., 14:57 +0300, Richard Fuchs <rfuchs(a)sipwise.com>om>, wrote:
On 02/06/17 07:40 AM, Igor Olhovskiy wrote:
Hi!
I’m trying to make RTPEngine to work with calls Browser <-> SIP.
Call From SIP to Browser working perfectly, but when calling to SIP from Browser, on 200
OK (sdp) I don’t receive
...
a=rtcp-mux
...
lines, but it was told to RTPEngine on reply_route to add this. And this line is
mandatory for me, cause I don’t control JS softphone on other side
Reply route in a case of Browser->SIP call looks like
reply_route[REPLY_R] {
…
rtpengine_answer("internal external UDP/TLS/RTP/SAVPF ICE=force
rtcp-mux-offer");
...
}
Also I’ve tried with rtcp-mux-accept but still no luck
You cannot "offer" rtcp-mux an in "answer".
I believe what you want is to use rtcp-mux-demux in the offer.
Cheers
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
2730
days inactive
2730
days old
3 comments
2 participants
participants (2)
-
Igor Olhovskiy -
Richard Fuchs