[SR-Users] kamailio with mediaproxy-ng, 488 Not Acceptable Here

Muhammad Shahzad shaheryarkh at gmail.com
Thu Feb 6 20:42:00 CET 2014


Great, i would test Bundle right away. Just wondering if this branch also
supports DTLS--SRTP. I would love to test that feature when available.

Thank you.




On Thu, Feb 6, 2014 at 2:43 PM, Richard Fuchs <rfuchs at 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 at 93.187.138.214 <mailto:sip%3Abob at 93.187.138.214> SIP/2.0
> > Via: SIP/2.0/WS an6ikqlgivd7.invalid;branch=z9hG4bK5845620
> > Max-Forwards: 69
> > To: <sip:bob at 93.187.138.214 <mailto:sip%3Abob at 93.187.138.214>>
> > From: "Alice Test" <sip:alice at 93.187.138.214
> > <mailto:sip%3Aalice at 93.187.138.214>>;tag=dt8iuu64l9
> > Call-ID: bmaapitncfv1jnijrbcf
> > CSeq: 7318 INVITE
> > Contact: <sip:sbt6u2o1 at 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 <rfuchs at sipwise.com
> > <mailto:rfuchs at 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
> >     <shaheryarkh at gmail.com <mailto:shaheryarkh at gmail.com>
> >     > <mailto:shaheryarkh at gmail.com <mailto:shaheryarkh at 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
> >     <marinmihai at gmail.com <mailto:marinmihai at gmail.com>
> >     >     <mailto:marinmihai at gmail.com <mailto:marinmihai at 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
> >     >         <apogrebennyk at sipwise.com
> >     <mailto:apogrebennyk at sipwise.com> <mailto:apogrebennyk at sipwise.com
> >     <mailto:apogrebennyk at 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 at lists.sip-router.org
> >     <mailto:sr-users at lists.sip-router.org>
> >     >             <mailto:sr-users at lists.sip-router.org
> >     <mailto:sr-users at 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 at lists.sip-router.org
> >     <mailto:sr-users at lists.sip-router.org>
> >     <mailto:sr-users at lists.sip-router.org
> >     <mailto:sr-users at 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 at lists.sip-router.org
> >     <mailto:sr-users at lists.sip-router.org>
> >     <mailto:sr-users at lists.sip-router.org
> >     <mailto:sr-users at 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 at lists.sip-router.org <mailto:
> sr-users at 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 at lists.sip-router.org <mailto:sr-users at 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 at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140206/b328b442/attachment-0001.html>


More information about the sr-users mailing list