i tried to use kamailio built-in stun server, but failed, because it supports only binding requests. my ua tried to send it "allocate request lifetime" request, which failed with 600 global failure response.
what is the status of kamailio's stun server? is anyone interested in developing it further or should we obsolete the server and start using some external server?
-- juha
I haven't done any testing of it, but supporting STUN on the same port as SIP is a requirement for an edge proxy supporting outbound. So I don't think it should be obsoleted or removed.
Peter
On 15 Dec 2012, at 17:49, Juha Heinanen jh@tutpro.com wrote:
i tried to use kamailio built-in stun server, but failed, because it supports only binding requests. my ua tried to send it "allocate request lifetime" request, which failed with 600 global failure response.
what is the status of kamailio's stun server? is anyone interested in developing it further or should we obsolete the server and start using some external server?
-- 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
Peter Dunkley writes:
I haven't done any testing of it, but supporting STUN on the same port as SIP is a requirement for an edge proxy supporting outbound. So I don't think it should be obsoleted or removed.
ok, in that case improving kamailio's stun server is new requirement for getting outbound support in next version of kamailio.
-- juha
I haven't done any testing of it, but supporting STUN on the same port as SIP is a requirement for an edge proxy supporting outbound. So I don't think it should be obsoleted or removed.
peter,
my understanding is that stun server as specified in ice rfc 5245 authenticates its clients, but there does not seem to be any possibility for the server to know the realm of the connecting client, which mean that a single realm must be configured in the stun server.
if that is true, it is not possible that a single stun server serves more than one domain at the same port. so does what you write in above mean that in multi-domain sip proxy setup, kamailio must be configured to listen at different ports for different domains (which in my opinion is not realistic).
-- juha
Hi Juha,
The STUN in outbound is a limited subset of STUN (Binding Request, Binding Response, and Binding Error Response, with no attributes except XOR-MAPPED-ADDRESS). This is described in RFC 5626 section 8. I am not expert in STUN, but as the attributes for authentication are not used for STUN in SIP outbound, I don't think there is a multi-domain problem.
I believe this subset of requests and responses is small enough that the current Kamailio STUN implementation should be adequate. I suspect that the correct thing is to have STUN enabled in Kamailio for SIP use with clients that support outbound, and a completely separate STUN server that supports the full protocol for use with ICE.
I did some experimentation with http://turnserver.sourceforge.net/ recently for ICE/WebRTC testing, and this seems promissing.
Regards,
Peter
I haven't done any testing of it, but supporting STUN on the same port as SIP is a requirement for an edge proxy supporting outbound. So I don't think it should be obsoleted or removed.
peter,
my understanding is that stun server as specified in ice rfc 5245 authenticates its clients, but there does not seem to be any possibility for the server to know the realm of the connecting client, which mean that a single realm must be configured in the stun server.
if that is true, it is not possible that a single stun server serves more than one domain at the same port. so does what you write in above mean that in multi-domain sip proxy setup, kamailio must be configured to listen at different ports for different domains (which in my opinion is not realistic).
-- 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
Peter Dunkley writes:
The STUN in outbound is a limited subset of STUN (Binding Request, Binding Response, and Binding Error Response, with no attributes except XOR-MAPPED-ADDRESS). This is described in RFC 5626 section 8. I am not expert in STUN, but as the attributes for authentication are not used for STUN in SIP outbound, I don't think there is a multi-domain problem.
yes, i checked that too and in outbound rfc5626, a subset of stun is used as a keepalive mechanism only.
I did some experimentation with http://turnserver.sourceforge.net/ recently for ICE/WebRTC testing, and this seems promissing.
thanks for the pointer. i was testing with restund from baresip project http://www.creytiv.com/baresip.html.
-- juha