Hello,
I managed to try it out and I have good news and bad news :)
The good news is that always TURN is working perfect. So, if I remove all
the ice-candidates (rtpproxy_manage("+")) everything is perfect. If I just
append turn candidate (rtpproxy_manage()) I have strange errors in kamailio
log and the media won't flow (black image on both parties).
I have attached the logs for both cases:
1. remove previous ice candidates - working - rtpproxy_manage("+")
http://snk.to/f-c7tjwm5k
2. keep ice candidates and append itself - not working - rtpproxy_manage()
http://snk.to/f-c71n29ic
My case and probably a nice feature is to have the possibility to append
the turn server candidate in SDP and let the client to decide what to use -
for WebRTC to WebRTC. Or, make this decision on server side (as it is now)
when you need conversion (RTP/AVP to and from RTP/SAVPF) - WebRTC to SIP,
etc. I'm sorry if I'm telling something wrong.
What I noticed is this line:
14(8465) ERROR: rtpproxy-ng [rtpproxy.c:1339]: rtpp_function_call(): failed
to decode bencoded reply from proxy: d3:sdp4301:v=0
I'm testing with the branch that you told me - pull yesterday.
Thank you.
Best regards,
Mihai M
On Thu, Feb 6, 2014 at 3:43 PM, Richard Fuchs <rfu...@sipwise.com> wrote:
> Hey,
>
> What mediaproxy-ng can do (which other RTP proxies don't do) is
> translate RTP/AVP (from regular SIP endpoints) to and from RTP/SAVPF
> (encrypted RTP from WebRTC), which is what people usually use it for.
>
> Assuming that ICE does its job correctly, two WebRTC endpoints should be
> able to communicate directly with each other (without RTP proxy), even
> if a firewall is involved. But I understand that in some cases even ICE
> might fail.
>
> There's two things I see wrong with the resulting SDP body, both related
> to the last stable version of MP-NG not supporting BUNDLE. If you could
> try adding an SDP rewrite rule to your kamailio config to remove the
> a=group:... line. If that doesn't work, also try disabling video when
> making the call.
>
> Alternatively, you can try building MP-NG from this branch:
> https://github.com/sipwise/mediaproxy-ng/tree/rfuchs/3.0
> This is currently under heavy development, but it should support BUNDLE
> just enough to make this work.
>
> cheers
>
>
> On 02/05/14 11:23, Mihai Marin wrote:
> > Hello,
> > I'm trying the simplest case first. I don't understand why you are
> > saying that most of the people don't use mediaproxy-ng
> > for WebRTC to WebRTC calls. If my firewall is a restrictive one I need
> > to use turn server and mediaproxy-ng can do turn too? Probably I'm not
> > seeing the big picture.
> >
> > Regarding the problem with Incompatible SDP I have attached the SDP
> > before mp-ng and after:
> >
> > BEFORE mediaproxy-ng magic:
> > 14(21473) DEBUG: websocket [ws_frame.c:650]: ws_frame_receive(): Rx SIP
> > message:
> > INVITE sip:bob@93.187.138.214 <mailto:sip%3Abob@93.187.138.214> SIP/2.0
> > Via: SIP/2.0/WS an6ikqlgivd7.invalid;branch=z9hG4bK5845620
> > Max-Forwards: 69
> > To: <sip:bob@93.187.138.214 <mailto:sip%3Abob@93.187.138.214>>
> > From: "Alice Test" <sip:alice@93.187.138.214
> > <mailto:sip%3Aalice@93.187.138.214>>;tag=dt8iuu64l9
> > Call-ID: bmaapitncfv1jnijrbcf
> > CSeq: 7318 INVITE
> > Contact: <sip:sbt6u2o1@an6ikqlgivd7.invalid;transport=ws;ob>
> > Allow: ACK,CANCEL,BYE,OPTIONS,INVITE
> > Content-Type: application/sdp
> > Supported: path, outbound, gruu
> > User-Agent: JsSIP 0.3.0
> > Content-Length: 2967
> >
> > v=0
> > o=- 1167703101330838157 2 IN IP4 127.0.0.1
> > s=-
> > t=0 0
> > a=group:BUNDLE audio video
> > a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
> > m=audio 9496 RTP/SAVPF 111 103 0 8 106 105 13 126
> > c=IN IP4 213.233.85.51
> > a=rtcp:9496 IN IP4 213.233.85.51
> > a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
> > generation 0
> > a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
> > generation 0
> > a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host
> > generation 0
> > a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host
> > generation 0
> > a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx
> > raddr 10.93.108.223 rport 53310 generation 0
> > a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx
> > raddr 10.93.108.223 rport 53310 generation 0
> > a=ice-ufrag:gNml+vA5NqfaRg0w
> > a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
> > a=ice-options:google-ice
> > a=mid:audio
> > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
> > a=sendrecv
> > a=rtcp-mux
> > a=crypto:1 AES_CM_128_HMAC_SHA1_80
> > inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
> > a=rtpmap:111 opus/48000/2
> > a=fmtp:111 minptime=10
> > a=rtpmap:103 ISAC/16000
> > a=rtpmap:0 PCMU/8000
> > a=rtpmap:8 PCMA/8000
> > 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:231261060 cname:aZBL5jB9VQtchKUh
> > a=ssrc:231261060 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
> > e8c9eb9c-916e-4c30-884f-fd602b2d8c90
> > a=ssrc:231261060 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
> > a=ssrc:231261060 label:e8c9eb9c-916e-4c30-884f-fd602b2d8c90
> > m=video 9496 RTP/SAVPF 100 116 117
> > c=IN IP4 213.233.85.51
> > a=rtcp:9496 IN IP4 213.233.85.51
> > a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
> > generation 0
> > a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
> > generation 0
> > a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host
> > generation 0
> > a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host
> > generation 0
> > a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx
> > raddr 10.93.108.223 rport 53310 generation 0
> > a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx
> > raddr 10.93.108.223 rport 53310 generation 0
> > a=ice-ufrag:gNml+vA5NqfaRg0w
> > a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
> > a=ice-options:google-ice
> > a=mid:video
> > a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
> > a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
> > a=sendrecv
> > a=rtcp-mux
> > a=crypto:1 AES_CM_128_HMAC_SHA1_80
> > inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
> > 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:3207772497 cname:aZBL5jB9VQtchKUh
> > a=ssrc:3207772497 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
> > ec757148-040c-479f-adbe-f6bac271fbd6
> > a=ssrc:3207772497 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
> > a=ssrc:3207772497 label:ec757148-040c-479f-adbe-f6bac271fbd6
> >
> >
> > AFTER mediaproxy-ng magic:
> > 14(21473) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call():
> > proxy reply: d3:sdp3046:
> > v=0
> > o=- 1167703101330838157 2 IN IP4 93.187.138.214
> > s=-
> > t=0 0
> > a=group:BUNDLE audio video
> > a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
> > m=audio 30408 RTP/SAVPF 111 103 0 8 106 105 13 126
> > c=IN IP4 93.187.138.214
> > a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
> > generation 0
> > a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
> > generation 0
> > a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host
> > generation 0
> > a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host
> > generation 0
> > a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx
> > raddr 10.93.108.223 rport 53310 generation 0
> > a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx
> > raddr 10.93.108.223 rport 53310 generation 0
> > a=ice-ufrag:gNml+vA5NqfaRg0w
> > a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
> > a=ice-options:google-ice
> > a=mid:audio
> > a=sendrecv
> > a=crypto:1 AES_CM_128_HMAC_SHA1_80
> > inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
> > a=rtpmap:111 opus/48000/2
> > a=fmtp:111 minptime=10
> > a=rtpmap:103 ISAC/16000
> > a=rtpmap:0 PCMU/8000
> > a=rtpmap:8 PCMA/8000
> > 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:231261060 cname:aZBL5jB9VQtchKUh
> > a=ssrc:231261060 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
> > e8c9eb9c-916e-4c30-884f-fd602b2d8c90
> > a=ssrc:231261060 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
> > a=ssrc:231261060 label:e8c9eb9c-916e-4c30-884f-fd602b2d8c90
> > a=rtcp:30409
> > a=candidate:8JGnwCAu0icAoJnr 1 UDP 2130706432 93.187.138.214 30408 typ
> host
> > a=candidate:8JGnwCAu0icAoJnr 2 UDP 2130706431 93.187.138.214 30409 typ
> host
> > m=video 30408 RTP/SAVPF 100 116 117
> > c=IN IP4 93.187.138.214
> > a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
> > generation 0
> > a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
> > generation 0
> > a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host
> > generation 0
> > a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host
> > generation 0
> > a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx
> > raddr 10.93.108.223 rport 53310 generation 0
> > a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx
> > raddr 10.93.108.223 rport 53310 generation 0
> > a=ice-ufrag:gNml+vA5NqfaRg0w
> > a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
> > a=ice-options:google-ice
> > a=mid:video
> > a=sendrecv
> > a=crypto:1 AES_CM_128_HMAC_SHA1_80
> > inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
> > 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:3207772497 cname:aZBL5jB9VQtchKUh
> > a=ssrc:3207772497 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
> > ec757148-040c-479f-adbe-f6bac271fbd6
> > a=ssrc:3207772497 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
> > a=ssrc:3207772497 label:ec757148-040c-479f-adbe-f6bac271fbd6
> > a=rtcp:30409
> > a=candidate:8JGnwCAu0icAoJnr 1 UDP 2130706432 93.187.138.214 30408 typ
> host
> > a=candidate:8JGnwCAu0icAoJnr 2 UDP 2130706431 93.187.138.214 30409 typ
> host
> >
> >
> >
> > Between them, I have some strange logs in kamailio:
> > 14(21473) ERROR: *** cfgtrace:
> > c=[/usr/local/etc/kamailio/kamailio-test-media.cfg] l=878 a=25
> > n=rtpproxy_manage
> > 14(21473) DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:565]:
> > extract_mediaip(): located IP address [127.0.0.1] in `o=' field
> > 14(21473) DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:565]:
> > extract_mediaip(): located IP address [213.233.85.51] in `c=' field
> > 14(21473) DEBUG: <core> [parser/sdp/sdp.c:574]: parse_sdp_session():
> > ignoring unknown type in a= line: `a=ice-ufrag:gNml+vA5NqfaRg0w
> > a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
> > a=ice-options:google-ice
> > a=mid:audio
> > ...............................................................
> > 14(21473) DEBUG: <core> [parser/sdp/sdp.c:574]: parse_sdp_session():
> > ignoring unknown type in a= line: `a=ssrc:3207772497
> > label:ec757148-040c-479f-adbe-f6bac271fbd6
> > '
> > 14(21473) DEBUG: rtpproxy-ng [rtpproxy_funcs.c:148]:
> > check_content_type(): type <application/sdp> found valid
> > 14(21473) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call():
> > proxy reply: d3:sdp3046:v=0
> > o=- 1167703101330838157 2 IN IP4 93.187.138.214
> > s=-
> > t=0 0
> > a=group:BUNDLE audio video
> > a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
> >
> >
> > Thank you very much for your help and for spending time debugging this
> > error.
> >
> >
> > Best regards,
> > Mihai M
> >
> >
> > On Wed, Feb 5, 2014 at 5:41 PM, Richard Fuchs <rfu...@sipwise.com
> > <mailto:rfu...@sipwise.com>> wrote:
> >
> > Hey,
> >
> > If you're trying to connect two WebRTC endpoints with each, you don't
> > need any of mediaproxy-ng's magic to get it working. All the previous
> > replies were assuming that you were trying to connect a WebRTC
> endpoint
> > with a non-WebRTC one, which is usually what people are trying to do.
> >
> > In your case, the flags "froc" in either direction should be
> sufficient
> > to get the job done. If it still doesn't work, can you please post
> the
> > rejected SDP body as it appears both on the sender's side and on the
> > receiver's side (i.e. both before and after it went through MP-NG).
> >
> > cheers
> >
> >
> > On 02/05/14 05:17, Mihai Marin wrote:
> > > Hello,
> > > Thank you for your detailed explication but I miss some
> information or
> > > I'm unable to understand it properly. What I'm trying to do is to
> use
> > > mediaproxy-ng as a turn server between 2 WebRTC endpoints (when at
> > least
> > > one is behind restrictive firewall). Trying to replicate what you
> > > explained on my needs I tried:
> > > $avp(rtpproxy_offer_flags) = "froc+SP";
> > > $avp(rtpproxy_answer_flags) = "froc-SP";
> > >
> > > But, unfortunately, I have the same error. Sorry if the solution is
> > > obvious but I can't find it.
> > >
> > > Thank you.
> > >
> > > Best regards,
> > > Mihai M
> > >
> > >
> > > On Tue, Feb 4, 2014 at 10:45 PM, Muhammad Shahzad
> > <shaherya...@gmail.com <mailto:shaherya...@gmail.com>
> > > <mailto:shaherya...@gmail.com <mailto:shaherya...@gmail.com>>>
> wrote:
> > >
> > > There are several problems that need to be addressed in your
> > > kamailio.cfg but let me try to focus only on mediaprxoy-ng
> > related ones.
> > >
> > > First instead of engaging mediaproxy in failure route, engage
> it
> > > main route or branch route. Why wait for failure when we know
> call
> > > will fail anyway if you try to call webrtc to sip or vice
> versa.
> > >
> > > Secondly you need to keep track of connection type of both
> caller
> > > and callee and set appropriate mediaproxy-ng flags according
> > to call
> > > direction, e.g. call from webrtc to sip, or sip to webrtc or
> > webrtc
> > > to webrtc or sip to sip, each type of call needs different set
> of
> > > flags for both rtpproxy_offer and rtpproxy_answer.
> > >
> > > How you do this, is pretty simple, to detect if caller is
> webrtc
> > > endpoint you can use,
> > >
> > >
> > > if ($avp(mline) =~ "SAVPF") {
> > > # caller is a webrtc endpoint
> > > };
> > >
> > > To check if callee is a webrtc endpoint, you can use,
> > >
> > > if ($(ru{uri.param,transport}) =~ "ws") {
> > > # callee is a webrtc endpoint
> > > };
> > >
> > > For testing purpose, i recommend you only use mediaproxy-ng for
> > > bridging webrtc to sip or vice versa calls, i.e. if both
> endpoints
> > > are using same transport (e.g. sip to sip or webrtc to webrtc
> > calls)
> > > then don't use mediaproxy-ng at all and allow endpoints to
> > establish
> > > media directly (that would work out the box at least for
> webrtc to
> > > webrtc calls).
> > >
> > > Finally use correct flags for each type of call (i recommend
> doing
> > > it in branch route), for example,
> > >
> > > For WebRTC to SIP call use flags (case-sensitive),
> > >
> > > $avp(rtpproxy_offer_flags) = "froc-sp";
> > > $avp(rtpproxy_answer_flags) = "froc+SP";
> > > rtpproxy_offer($avp(rtpproxy_offer_flags));
> > >
> > > For SIP to WebRTC call use flags (case-sensitive),
> > >
> > > $avp(rtpproxy_offer_flags) = "froc+SP";
> > > $avp(rtpproxy_answer_flags) = "froc-sp";
> > > rtpproxy_offer($avp(rtpproxy_offer_flags));
> > >
> > >
> > > Then in reply route,
> > >
> > > rtpproxy_answer($avp(rtpproxy_answer_flags));
> > >
> > >
> > > Remember, currently mediaproxy-ng does NOT support SRTP/DTLS,
> > which
> > > is required by firefox, so as result your webrtc endpoint MUST
> be
> > > running on Chrome.
> > >
> > > Hope this helps.
> > >
> > > Thank you.
> > >
> > >
> > >
> > >
> > > On Tue, Feb 4, 2014 at 3:28 PM, Mihai Marin
> > <marinmi...@gmail.com <mailto:marinmi...@gmail.com>
> > > <mailto:marinmi...@gmail.com <mailto:marinmi...@gmail.com>>>
> > wrote:
> > >
> > > Hello,
> > > Thank you for your support.
> > >
> > > Yes, I have the same error without video enabled. I have
> > > attached the logs from jssip (with and without video
> support)
> > > and logs from kamailio when trying a call with video
> support
> > > enabled. The kamailio.cfg used is the same from my
> > previous mail.
> > >
> > > I also tried with sipml5 and I have the same behavior.
> > >
> > > I'm stuck on this error and I think I'm looking in the
> wrong
> > > direction.
> > >
> > > Thank you.
> > >
> > > Best regards,
> > > Mihai M
> > >
> > >
> > > On Tue, Feb 4, 2014 at 2:49 PM, Andrew Pogrebennyk
> > > <apogreben...@sipwise.com
> > <mailto:apogreben...@sipwise.com> <mailto:apogreben...@sipwise.com
> > <mailto:apogreben...@sipwise.com>>> wrote:
> > >
> > > Hi,
> > > could you please post also your Chrome js developer
> log?
> > > Does the problem exist if you start the jssip clients
> > > without video support?
> > >
> > > Andrew
> > >
> > > On 02/03/2014 12:00 PM, Mihai Marin wrote:
> > > > Hello,
> > > >
> > > > Another weekend struggling to make a call from jssip
> to
> > > another jssip
> > > > behind firewall and I still receive 488 - Not
> Acceptable
> > > Here. I tried
> > > > all the ideas that I had/received without any
> success -
> > > including catch
> > > > 488 and re-invite.
> > > > [...]
> > > > What do I miss from my configuration?
> > > >
> > > > Thank you.
> > > >
> > > > Best regards,
> > > > Mihai M
> > >
> > >
> > > _______________________________________________
> > > SIP Express Router (SER) and Kamailio (OpenSER) -
> sr-users
> > > mailing list
> > > sr-users@lists.sip-router.org
> > <mailto:sr-users@lists.sip-router.org>
> > > <mailto:sr-users@lists.sip-router.org
> > <mailto:sr-users@lists.sip-router.org>>
> > >
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> > >
> > >
> > >
> > > _______________________________________________
> > > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
> > > mailing list
> > > sr-users@lists.sip-router.org
> > <mailto:sr-users@lists.sip-router.org>
> > <mailto:sr-users@lists.sip-router.org
> > <mailto:sr-users@lists.sip-router.org>>
> > >
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> > >
> > >
> > >
> > > _______________________________________________
> > > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
> > mailing list
> > > sr-users@lists.sip-router.org
> > <mailto:sr-users@lists.sip-router.org>
> > <mailto:sr-users@lists.sip-router.org
> > <mailto:sr-users@lists.sip-router.org>>
> > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
> > list
> > > sr-users@lists.sip-router.org <mailto:
> sr-users@lists.sip-router.org>
> > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> > >
> >
> >
> > _______________________________________________
> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
> list
> > sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >
> >
> >
> >
> > _______________________________________________
> > 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
> >
>
>
> _______________________________________________
> 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
>
>
_______________________________________________
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
