Hi
When i dial #31# 011111with a sip phone i have an INVITE in OPENSER with a number
%2331%23 011111.
Who know how can i send an INVITE whith prefix #31# using a phone or softphone.
thanks,
2009/1/12 ALAEDDINE abbech alasupcom@yahoo.fr:
Hi
When i dial #31# 011111with a sip phone i have an INVITE in OPENSER with a number
%2331%23 011111.
Who know how can i send an INVITE whith prefix #31# using a phone or softphone.
Symbol # is NOT allowed into a SIP URI userinfo part per SIP BNF grammar, so the phone is escaping it before sending the request. This is a correct behavior even if lots of softphones don't escape it.
You should use "unescape" transformation in your script to decode it as #.
2009/1/12 Iñaki Baz Castillo ibc@aliax.net:
Symbol # is NOT allowed into a SIP URI userinfo part per SIP BNF grammar, so the phone is escaping it before sending the request. This is a correct behavior even if lots of softphones don't escape it.
Also, # symbol is allowed in a TEL URI, but not in a SIP URI userinfo part.
12 jan 2009 kl. 11.42 skrev Iñaki Baz Castillo:
2009/1/12 Iñaki Baz Castillo ibc@aliax.net:
Symbol # is NOT allowed into a SIP URI userinfo part per SIP BNF grammar, so the phone is escaping it before sending the request. This is a correct behavior even if lots of softphones don't escape it.
Also, # symbol is allowed in a TEL URI, but not in a SIP URI userinfo part.
Just to check - is the # allowed unescaped in a TEL uri, but only escaped in a SIP uri userinfo part?
/O
2009/1/12 Johansson Olle E oej@edvina.net:
12 jan 2009 kl. 11.42 skrev Iñaki Baz Castillo:
2009/1/12 Iñaki Baz Castillo ibc@aliax.net:
Symbol # is NOT allowed into a SIP URI userinfo part per SIP BNF grammar, so the phone is escaping it before sending the request. This is a correct behavior even if lots of softphones don't escape it.
Also, # symbol is allowed in a TEL URI, but not in a SIP URI userinfo part.
Just to check - is the # allowed unescaped in a TEL uri, but only escaped in a SIP uri userinfo part?
Yes, that is.
So if you want to convert a SIP URI into a TEL URI you must take it in account and unescape the # (but unfortunatelly this is not the worst issue when converting TEL to SIP or SIP to TEL).
SIP is designed by martians XD
On Mon, Jan 12, 2009 at 11:45 AM, Johansson Olle E oej@edvina.net wrote:
12 jan 2009 kl. 11.42 skrev Iñaki Baz Castillo:
2009/1/12 Iñaki Baz Castillo ibc@aliax.net:
Symbol # is NOT allowed into a SIP URI userinfo part per SIP BNF grammar, so the phone is escaping it before sending the request. This is a correct behavior even if lots of softphones don't escape it.
Also, # symbol is allowed in a TEL URI, but not in a SIP URI userinfo part.
Just to check - is the # allowed unescaped in a TEL uri, but only escaped in a SIP uri userinfo part?
Right
thanks all,
But my problem is to dial this prefix whith a phone and i detect it
whith my OpenSER.
So the question is : can i have #31# in the Username in SIP Request's URI?
ALAEDDINE abbech schrieb:
thanks all,
But my problem is to dial this prefix whith a phone and i detect it
whith my OpenSER.
So the question is : can i have #31# in the Username in SIP Request's URI?
There must not be #31# in the userpart.
quick and dirty solution: check for %2331%23
nice solution: transformations http://www.kamailio.org/dokuwiki/doku.php/transformations:1.4.x
$rU.{s.unescape.user}
regards klaus
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
2009/1/12 ALAEDDINE abbech alasupcom@yahoo.fr:
thanks all,
But my problem is to dial this prefix whith a phone and i detect it
whith my OpenSER.
So the question is : can i have #31# in the Username in SIP Request's URI?
I already explained that # is not allowed in a SIP URI (also in the SIP Request URI, of course).
12 jan 2009 kl. 15.34 skrev Iñaki Baz Castillo:
2009/1/12 ALAEDDINE abbech alasupcom@yahoo.fr:
thanks all,
But my problem is to dial this prefix whith a phone and i detect it
whith my OpenSER.
So the question is : can i have #31# in the Username in SIP Request's URI?
I already explained that # is not allowed in a SIP URI (also in the SIP Request URI, of course).
On the other side, the answer is "Yes, of course, provided that your SIP equipment follows the standard and encodes the # character. You are allowed to dial that character, but any SIP-compliant device (useragent) is not allowed to transfer it verbatim in a SIP uri, but has to encode it - much like many international characters in a HTTP uri.
/O
2009/1/12 Johansson Olle E oej@edvina.net:
I already explained that # is not allowed in a SIP URI (also in the SIP Request URI, of course).
On the other side, the answer is "Yes, of course, provided that your SIP equipment follows the standard and encodes the # character. You are allowed to dial that character, but any SIP-compliant device (useragent) is not allowed to transfer it verbatim in a SIP uri, but has to encode it - much like many international characters in a HTTP uri.
Yeah, but in Kamailio you must decode it using some "undecode" transformation. Kamailio itself doesn't undecode it by default and treats %23 hexedecimal code as 3 normal ASCII chars: '%', '2', '3'.
On 01/12/2009 06:38 PM, Iñaki Baz Castillo wrote:
2009/1/12 Johansson Olle E oej@edvina.net:
I already explained that # is not allowed in a SIP URI (also in the SIP Request URI, of course).
On the other side, the answer is "Yes, of course, provided that your SIP equipment follows the standard and encodes the # character. You are allowed to dial that character, but any SIP-compliant device (useragent) is not allowed to transfer it verbatim in a SIP uri, but has to encode it - much like many international characters in a HTTP uri.
Yeah, but in Kamailio you must decode it using some "undecode" transformation. Kamailio itself doesn't undecode it by default and treats %23 hexedecimal code as 3 normal ASCII chars: '%', '2', '3'.
By some reason, the '#' is used a lot in telecom/mobile operators dialed extensions (e.g., charging credit on mobile phone), not sure why is not allowed in SIP.
That is the reason kamailio (openser) does accept '#' in the username. If you want to be strict compliant to SIP-RFC then you have to use the transformations. Not sure what would be the best to make default for the future ....
Cheers, Daniel
El Lunes, 12 de Enero de 2009, Daniel-Constantin Mierla escribió:
By some reason, the '#' is used a lot in telecom/mobile operators dialed extensions (e.g., charging credit on mobile phone),
Well, IMHO the reason is that key '#' appears in all the phones :)
not sure why is not allowed in SIP.
I assume this is due to inheritance from common URI syntax (an username in a mail URI doesn't allow it also).
That is the reason kamailio (openser) does accept '#' in the username. If you want to be strict compliant to SIP-RFC then you have to use the transformations. Not sure what would be the best to make default for the future ....
I think it's ok to allow it, but it would be nice if Kamailio would decode "%23" as "#" directly, without the need of using transformations. In this way, if a strict compliant phone encodes "#" as "%23" in the RURI it would be automatically detected by Kamailio as a "#" symbol.
Could it be feasible? Regards.
On 01/12/2009 10:49 PM, Iñaki Baz Castillo wrote:
El Lunes, 12 de Enero de 2009, Daniel-Constantin Mierla escribió:
By some reason, the '#' is used a lot in telecom/mobile operators dialed extensions (e.g., charging credit on mobile phone),
Well, IMHO the reason is that key '#' appears in all the phones :)
... including the SIP phones. The '#' is also lot used to terminate the dialing string orDTMF sequences
not sure why is not allowed in SIP.
I assume this is due to inheritance from common URI syntax (an username in a mail URI doesn't allow it also).
That is the reason kamailio (openser) does accept '#' in the username. If you want to be strict compliant to SIP-RFC then you have to use the transformations. Not sure what would be the best to make default for the future ....
I think it's ok to allow it, but it would be nice if Kamailio would decode "%23" as "#" directly, without the need of using transformations. In this way, if a strict compliant phone encodes "#" as "%23" in the RURI it would be automatically detected by Kamailio as a "#" symbol.
Could it be feasible? Regards.
That is one line on top your config file:
$rU = $(rU{s.unescape.user});
Cheers, Daniel
2009/1/13 Daniel-Constantin Mierla miconda@gmail.com:
By some reason, the '#' is used a lot in telecom/mobile operators dialed extensions (e.g., charging credit on mobile phone),
Well, IMHO the reason is that key '#' appears in all the phones :)
... including the SIP phones. The '#' is also lot used to terminate the dialing string orDTMF sequences
But that's not an URI.
Phones terminating the dialing string with '#' don't send the '#' as part of the URI username. '#' key becomes a "Dial" button.
And in case of DTMF, it's not an URI, and valid DTFM codes are: 0-9, #, *, A, B, C, D
That is one line on top your config file:
$rU = $(rU{s.unescape.user});
Yes, it's enough easy, thanks for pointing it out.
PD: Perhaps the default script should include that line?
On 01/13/2009 06:23 PM, Iñaki Baz Castillo wrote:
2009/1/13 Daniel-Constantin Mierla miconda@gmail.com:
By some reason, the '#' is used a lot in telecom/mobile operators dialed extensions (e.g., charging credit on mobile phone),
Well, IMHO the reason is that key '#' appears in all the phones :)
... including the SIP phones. The '#' is also lot used to terminate the dialing string orDTMF sequences
But that's not an URI.
Phones terminating the dialing string with '#' don't send the '#' as part of the URI username. '#' key becomes a "Dial" button.
Yes, also this happens with several SIP phones as well - they do not send # in uri (it is interpreted as dial button). But others do...
And in case of DTMF, it's not an URI, and valid DTFM codes are: 0-9, #, *, A, B, C, D
That is one line on top your config file:
$rU = $(rU{s.unescape.user});
Yes, it's enough easy, thanks for pointing it out.
PD: Perhaps the default script should include that line?
There will be a refurbished config before release. A lot of things has changed/added and worth to be there.
Cheers, Daniel
Dear Kamailio users,
Does anybody know how to configure OpenSER 1.3 to support secure VoIP?
Another question about SIP is how difference between sips and TLS?
Thank you very much!
Best Regards,
Steven
On Wednesday 25 February 2009, Steven Wu wrote:
Does anybody know how to configure OpenSER 1.3 to support secure VoIP?
Another question about SIP is how difference between sips and TLS?
Hi Steven,
you find some documentation about TLS support in kamailio/ OpenSER here: http://kamailio.org/docs/tls.html.
SIPS is the secure variant of SIP, it uses TLS to encrypt its data.
Cheers,
Henning
On 02/25/2009 12:05 PM, Henning Westerholt wrote:
On Wednesday 25 February 2009, Steven Wu wrote:
Does anybody know how to configure OpenSER 1.3 to support secure VoIP?
Another question about SIP is how difference between sips and TLS?
Hi Steven,
you find some documentation about TLS support in kamailio/ OpenSER here: http://kamailio.org/docs/tls.html.
SIPS is the secure variant of SIP, it uses TLS to encrypt its data.
IIRC the specs, sips is the indication that the user does not want to be reached unless there is a secure channel, e.g., TLS. However, not sure if this applies as well if between caller-server-callee is IP sec or other secured transport and SIP is sent over it.
Looking at uri comparison, sip:a@b.com is different than sips:a@b.com. I haven't any real sip device using sips so far. Has anybody of you seen some usage of sips indication in SIP addresses?
Cheers, Daniel
Hello,
On 02/26/2009 09:34 AM, Johansson Olle E wrote:
25 feb 2009 kl. 11.05 skrev Henning Westerholt:
SIPS is the secure variant of SIP, it uses TLS to encrypt its data.
Actually both SIP: and SIPS: can be protected by TLS. The difference is that a SIPS: url *request* TLS.
what I tried to figure out in one of my previous emails, is: - does sips requires TLS only, or can be any form of secure communication channel, e.g., ipsec?
Cheers, Daniel
26 feb 2009 kl. 10.10 skrev Daniel-Constantin Mierla:
Hello,
On 02/26/2009 09:34 AM, Johansson Olle E wrote:
25 feb 2009 kl. 11.05 skrev Henning Westerholt:
SIPS is the secure variant of SIP, it uses TLS to encrypt its data.
Actually both SIP: and SIPS: can be protected by TLS. The difference is that a SIPS: url *request* TLS.
what I tried to figure out in one of my previous emails, is:
- does sips requires TLS only, or can be any form of secure
communication channel, e.g., ipsec?
The original SIPS spec was very vague here. IPsec was among the "approved solutions". Also note that the requirements did not require any protection on the last hop. Kamailio is allowed to use UDP on a SIPS uri when calling a registered phone.
I haven't had time to go through the changes in the latest update, but it was supposed to fix a lot of these issues.
The document I need to re-read and store in parsed format somewhere in my memory storage is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-09.txt
" This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP." "1. Introduction The meaning and usage of the SIPS URI scheme and of TLS [RFC5246] is underspecified in SIP [RFC3261] and has been a source of confusion for implementers. This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP (including both [RFC3261] and [RFC3608]."
/O
2009/2/26 Johansson Olle E oej@edvina.net:
" This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP." "1. Introduction The meaning and usage of the SIPS URI scheme and of TLS [RFC5246] is underspecified in SIP [RFC3261] and has been a source of confusion for implementers. This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP (including both [RFC3261] and [RFC3608]."
This is very common in lots of RFC's: It seems that a draft must contain some stuff about "security" and "privacy" in order to be accepted as a new RFC.
For example, each new RFC has a vague section mentioning S/MIME:
"In order to provide security the UA could use S/MIME"
Of course, S/MIME is not implemented *AT ALL*, but that seems not to be important, the target is publishing a new RFC so S/MIME, SIPS, IPSEC and TLS stuff is required to appear "somewhere" in the draft.
IETF guys should visit our planet someday.
26 feb 2009 kl. 15.20 skrev Iñaki Baz Castillo:
2009/2/26 Johansson Olle E oej@edvina.net:
" This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP." "1. Introduction The meaning and usage of the SIPS URI scheme and of TLS [RFC5246] is underspecified in SIP [RFC3261] and has been a source of confusion for implementers. This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP (including both [RFC3261] and [RFC3608]."
This is very common in lots of RFC's: It seems that a draft must contain some stuff about "security" and "privacy" in order to be accepted as a new RFC.
For example, each new RFC has a vague section mentioning S/MIME:
"In order to provide security the UA could use S/MIME"
Of course, S/MIME is not implemented *AT ALL*, but that seems not to be important, the target is publishing a new RFC so S/MIME, SIPS, IPSEC and TLS stuff is required to appear "somewhere" in the draft.
IETF guys should visit our planet someday.
This is a problem I realize at every SIPit. The implementations are far away from the IETF world. And the gap doesn't seem to close.
Basic stuff like DNS is not understood or used by many SIPit attendees so even trying to mention NAPTR is too complex, and it's necessary for many security scenarious.
The big question is how to close this gap. I have no clue. - Can we stop the IETF SIP development during a year and work on implementations, testing and reality checks? - Would it be possible to get more implementation guidelines published?
We have at least two cases now where an update to the RFC added important MUSTs:
- Tel uri - phone-context is now required, which affects all SIP devices using SIP uri with user=phone regardless if they use a Tel: URI. - RFC2833 DTMF is updated and secure RTP is now required
Will these changes be implemented at all? When?
I think people will use "rfc2833" over insecure RTP for a very long time, regardless that it's now not allowed.
The Jabber world annualöy publish a document where they specify "base level standard compliance" for a client and a server. Maybe the SIP world should copy this and use it as a way to push changes to the market.
If the standardization is too far away from current implementations, we have a fork. That's not good for anyone. /O
2009/2/26 Olle E. Johansson oej@edvina.net:
This is a problem I realize at every SIPit. The implementations are far away from the IETF world. And the gap doesn't seem to close.
Basic stuff like DNS is not understood or used by many SIPit attendees so even trying to mention NAPTR is too complex, and it's necessary for many security scenarious.
RFC 3263 (Locating SIP Servers) is really complex, NAPTR is really complex, and it's not needed in 99% of current SIP deployments, so vendors don't implement it. If a SIP provider whises to use NAPTR records then all its clients should implement it in their SIP phones (obviously this is unfeasible for now). Solution? don't use NAPTR at all.
The big question is how to close this gap. I have no clue.
- Can we stop the IETF SIP development during a year and work on
implementations, testing and reality checks?
AFAIK no one draft or RFC comes with a real implementation. Sincerelly I don't feel to much interest in real implementations aroud IETF. They can join a long maillist thread about exotic SIP issues that will never happen because nobody will implement the required especifications. When I read IETF-SIP maillist and compare their threads with today's SIP implementations, they seems two different worlds.
- Would it be possible to get more implementation guidelines published?
Does one of these already exist? where?
We have at least two cases now where an update to the RFC added important MUSTs:
- Tel uri - phone-context is now required, which affects all SIP devices
using SIP uri with user=phone regardless if they use a Tel: URI.
- RFC2833 DTMF is updated and secure RTP is now required
I would add all those especifications including new "Require" values, and also those requiring multipart (widely NOT implemented).
The Jabber world annualöy publish a document where they specify "base level standard compliance" for a client and a server. Maybe the SIP world should copy this and use it as a way to push changes to the market.
There is somewhere an RFC pointing a list of "recommended" RFC's. When I read it long time ago there were a *lot* of specifications there.
If the standardization is too far away from current implementations, we have a fork. That's not good for anyone.
Sure, but who care? This should care to both implementators and designers, but...
Iñaki Baz Castillo wrote:
2009/2/26 Olle E. Johansson oej@edvina.net:
This is a problem I realize at every SIPit. The implementations are far away from the IETF world. And the gap doesn't seem to close.
Basic stuff like DNS is not understood or used by many SIPit attendees so even trying to mention NAPTR is too complex, and it's necessary for many security scenarious.
RFC 3263 (Locating SIP Servers) is really complex, NAPTR is really complex, and it's not needed in 99% of current SIP deployments, so vendors don't implement it. If a SIP provider whises to use NAPTR records then all its clients should implement it in their SIP phones (obviously this is unfeasible for no
I tend to disagree. I always hate to configure stuff like outbound proxy and protocol in a SIP client. If all client supports NAPTRs then it would be sufficient to configure in your client only the AoR and password.
And people which understand SIP should be able to understand DNS too.
regards klaus
On 02/26/2009 06:40 PM, Klaus Darilion wrote:
Iñaki Baz Castillo wrote:
2009/2/26 Olle E. Johansson oej@edvina.net:
This is a problem I realize at every SIPit. The implementations are far away from the IETF world. And the gap doesn't seem to close.
Basic stuff like DNS is not understood or used by many SIPit attendees so even trying to mention NAPTR is too complex, and it's necessary for many security scenarious.
RFC 3263 (Locating SIP Servers) is really complex, NAPTR is really complex, and it's not needed in 99% of current SIP deployments, so vendors don't implement it. If a SIP provider whises to use NAPTR records then all its clients should implement it in their SIP phones (obviously this is unfeasible for no
I tend to disagree. I always hate to configure stuff like outbound proxy and protocol in a SIP client. If all client supports NAPTRs then it would be sufficient to configure in your client only the AoR and password.
And people which understand SIP should be able to understand DNS too
a proper DNS implementation in SIP phones would be a big step forward in terms of service scalability and reliability. I would love to see that live.
However, being out there so many phones without such support, it is practically unusable since service providers won't deploy different server solutions for each group of devices, so they stick to one size fits all and that is not DNS for now.
Proper DNS support should be enforced somehow (who knows how?!?) before anything else. At the end, DNS drives the IP world.
Cheers, Daniel
2009/2/26 Daniel-Constantin Mierla miconda@gmail.com:
However, being out there so many phones without such support, it is practically unusable since service providers won't deploy different server solutions for each group of devices, so they stick to one size fits all and that is not DNS for now.
Devices don't implement it, so service providers don't implement it, so devices don't implement it, so... XD
Proper DNS support should be enforced somehow (who knows how?!?) before anything else. At the end, DNS drives the IP world.
IMHO RFC 3263 complexity doesn't help too much.
On 02/26/2009 07:08 PM, Iñaki Baz Castillo wrote:
2009/2/26 Daniel-Constantin Mierla miconda@gmail.com:
However, being out there so many phones without such support, it is practically unusable since service providers won't deploy different server solutions for each group of devices, so they stick to one size fits all and that is not DNS for now.
Devices don't implement it, so service providers don't implement it, so devices don't implement it, so... XD
I think the sip server implementations are pretty good here. Besides that, for client interaction it is required only DNS server configuration, nothing in sip server.
What I meant is the headache for sip server providers to deploy two different fault tolerant solution: - one based on DNS - one based on shared/virtual IP or load balancer
Each of them will require maintenance, man power, etc... Anyway, even with second option, good DNS in phones does not harm.
Cheers, Daniel
Proper DNS support should be enforced somehow (who knows how?!?) before anything else. At the end, DNS drives the IP world.
IMHO RFC 3263 complexity doesn't help too much.
2009/2/26 Daniel-Constantin Mierla miconda@gmail.com:
Devices don't implement it, so service providers don't implement it, so devices don't implement it, so... XD
I think the sip server implementations are pretty good here. Besides that, for client interaction it is required only DNS server configuration, nothing in sip server.
True, what I mean is that SIP providers don't offer a NAPTR record for their service since most clients don't implement it.
On 02/26/2009 07:30 PM, Iñaki Baz Castillo wrote:
2009/2/26 Daniel-Constantin Mierla miconda@gmail.com:
Devices don't implement it, so service providers don't implement it, so devices don't implement it, so... XD
I think the sip server implementations are pretty good here. Besides that, for client interaction it is required only DNS server configuration, nothing in sip server.
True, what I mean is that SIP providers don't offer a NAPTR record for their service since most clients don't implement it.
I see your point now. True but somehow sad, whole thing, dns records chain from NAPTR to A, is about 10 lines, for a sip server supporting udp/tcp/tls. This one would be the easiest to fix, just some willingness...
Cheers, Daniel
2009/2/26 Daniel-Constantin Mierla miconda@gmail.com:
True, what I mean is that SIP providers don't offer a NAPTR record for their service since most clients don't implement it.
But NAPTR request on windows are a pain. "dnsquery DNS_TYPE_NAPTR" on google gives very low number of results: most of them are people not able to overcome with parsing the NAPTR answer which is not parsed at all by micosoft APIs...
That's at least a reason among other for NAPTR not being adopted.
An other reason is that many people buy a domain and does not wish to run a DNS server: thus, they cannot declare any NAPTR entry. At least my DNS provider let me add SRV entry since less than a year... When will he open NAPTR???
The very last reason for non wide adoption in UA is that many (some) providers still DON't answer NAPTR request... That leads to huge timeout which are unacceptable for users... Want to guess my latest patch for my product?
http://svn.savannah.gnu.org/viewvc/trunk/exosip/src/eXutils.c?root=exosip&am...
Just look at the last commit text: "Add option to disable NAPTR requests"...
Regards, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
El Jueves, 26 de Febrero de 2009, Aymeric Moizard escribió:
An other reason is that many people buy a domain and does not wish to run a DNS server: thus, they cannot declare any NAPTR entry. At least my DNS provider let me add SRV entry since less than a year... When will he open NAPTR???
That's true, but it's also true that a SIP provider MUST manage its own domains in an own DNS server.
On 02/26/2009 09:44 PM, Aymeric Moizard wrote:
2009/2/26 Daniel-Constantin Mierla miconda@gmail.com:
True, what I mean is that SIP providers don't offer a NAPTR record for their service since most clients don't implement it.
But NAPTR request on windows are a pain.
then indeed, this is a solid reason against propagation of naptr in client side -- most of the softphones and hardphones are build on win platform.
"dnsquery DNS_TYPE_NAPTR" on google gives very low number of results: most of them are people not able to overcome with parsing the NAPTR answer which is not parsed at all by micosoft APIs...
That's at least a reason among other for NAPTR not being adopted.
An other reason is that many people buy a domain and does not wish to run a DNS server: thus, they cannot declare any NAPTR entry. At least my DNS provider let me add SRV entry since less than a year... When will he open NAPTR???
Running an IP-based service without a good managed DNS server does not sound good for me. It is not expensive to get a proper one.
The very last reason for non wide adoption in UA is that many (some) providers still DON't answer NAPTR request... That leads to huge timeout which are unacceptable for users...
Again, true, therefore I agree with your next patch ...
Cheers, Daniel
Want to guess my latest patch for my product?
http://svn.savannah.gnu.org/viewvc/trunk/exosip/src/eXutils.c?root=exosip&am...
Just look at the last commit text: "Add option to disable NAPTR requests"...
Regards, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
On Thu, 26 Feb 2009, Daniel-Constantin Mierla wrote:
Running an IP-based service without a good managed DNS server does not sound good for me. It is not expensive to get a proper one.
Sure, but small business can't become their own "*small*" SIP provider because managing DNS for SIP is not as fast(automatic) as for mail.
tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
El Jueves, 26 de Febrero de 2009, Aymeric Moizard escribió:
On Thu, 26 Feb 2009, Daniel-Constantin Mierla wrote:
Running an IP-based service without a good managed DNS server does not sound good for me. It is not expensive to get a proper one.
Sure, but small business can't become their own "*small*" SIP provider because managing DNS for SIP is not as fast(automatic) as for mail.
Again, I consider that a SIP provider (even if small) should manage its own DNS server.
The problem could arise if a SIP provider allows its clients having their own domain for SIP, this is, client "francebank.fr" wants SIP accounts like "sip:info@francebank.fr". Most probably, that domain would be managed by the client itself of by other domains provider/ISP. In this case is more difficult to play with NAPTR/SRV records since it doesn't depend just on the SIP provider.
Best regards.
26 feb 2009 kl. 18.27 skrev Daniel-Constantin Mierla:
On 02/26/2009 07:08 PM, Iñaki Baz Castillo wrote:
2009/2/26 Daniel-Constantin Mierla miconda@gmail.com:
However, being out there so many phones without such support, it is practically unusable since service providers won't deploy different server solutions for each group of devices, so they stick to one size fits all and that is not DNS for now.
Devices don't implement it, so service providers don't implement it, so devices don't implement it, so... XD
I think the sip server implementations are pretty good here. Besides that, for client interaction it is required only DNS server configuration, nothing in sip server.
What I meant is the headache for sip server providers to deploy two different fault tolerant solution:
- one based on DNS
- one based on shared/virtual IP or load balancer
Each of them will require maintenance, man power, etc... Anyway, even with second option, good DNS in phones does not harm.
A problem here is of course the good old NAT issue. Even if the phones have DNS support, having a NAT in between the phone and a provider's server more or less force a provider to use some IP failover solution to be able to keep the NAT binding.
DNS helps with failover and some load balancing from the client side, so it's a good complement.
I have not yet received requests for NAPTR support in Asterisk, even though with our recent baby steps into the TLS/TCP world, we really do need them.
/O
2009/2/27 Olle E. Johansson oej@edvina.net:
I have not yet received requests for NAPTR support in Asterisk
Ok, please implement NAPTR in Asterisk, and also all the SIMPLE related stuff. Could it be done for next week? I've already sold such an installation. Thanks.
27 feb 2009 kl. 11.59 skrev Iñaki Baz Castillo:
2009/2/27 Olle E. Johansson oej@edvina.net:
I have not yet received requests for NAPTR support in Asterisk
Ok, please implement NAPTR in Asterisk, and also all the SIMPLE related stuff. Could it be done for next week? I've already sold such an installation. Thanks.
Ok, now I received a request. Where do I send the bill? ;-)
Have a nice weekend all Kamailians!
/O
Hi Everyone, After reading the full chain of mails, I who is currently implementing RFC 3263 feels bit confused. I am not facing any major problems implementing it. Can i request to give me some points which are dicey and I need to take care of them.
cheers!!!! sarvpriya
On Fri, Feb 27, 2009 at 4:22 PM, Olle E. Johansson oej@edvina.net wrote:
26 feb 2009 kl. 18.27 skrev Daniel-Constantin Mierla:
On 02/26/2009 07:08 PM, Iñaki Baz Castillo wrote:
2009/2/26 Daniel-Constantin Mierla miconda@gmail.com:
However, being out there so many phones without such support, it is practically unusable since service providers won't deploy different server solutions for each group of devices, so they stick to one size fits all and that is not DNS for now.
Devices don't implement it, so service providers don't implement it, so devices don't implement it, so... XD
I think the sip server implementations are pretty good here. Besides that, for client interaction it is required only DNS server configuration, nothing in sip server.
What I meant is the headache for sip server providers to deploy two different fault tolerant solution:
- one based on DNS
- one based on shared/virtual IP or load balancer
Each of them will require maintenance, man power, etc... Anyway, even with second option, good DNS in phones does not harm.
A problem here is of course the good old NAT issue. Even if the phones have DNS support, having a NAT in between the phone and a provider's server more or less force a provider to use some IP failover solution to be able to keep the NAT binding.
DNS helps with failover and some load balancing from the client side, so it's a good complement.
I have not yet received requests for NAPTR support in Asterisk, even though with our recent baby steps into the TLS/TCP world, we really do need them.
/O _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Iñaki Baz Castillo wrote:
2009/2/26 Daniel-Constantin Mierla miconda@gmail.com:
However, being out there so many phones without such support, it is practically unusable since service providers won't deploy different server solutions for each group of devices, so they stick to one size fits all and that is not DNS for now.
Devices don't implement it, so service providers don't implement it, so devices don't implement it, so... XD
I know SIP providers who are actually using SRV in real world for providing access to end-users. So DNS is out there.
Proper DNS support should be enforced somehow (who knows how?!?) before anything else. At the end, DNS drives the IP world.
IMHO RFC 3263 complexity doesn't help too much.
I wouldn't say so. I personally implemented this RFC and it is very helpful if you understand it and if you are able to take advantage of all its functionalities (discovery, failover, balancing, etc)
Do not blame the tool - blame who's not capable to use the tool.
Regards, Bogdan
2009/2/26 Bogdan-Andrei Iancu bogdan@voice-system.ro:
IMHO RFC 3263 complexity doesn't help too much.
I wouldn't say so. I personally implemented this RFC and it is very helpful if you understand it and if you are able to take advantage of all its functionalities (discovery, failover, balancing, etc)
Do not blame the tool - blame who's not capable to use the tool.
ok :)
On Thu, Feb 26, 2009 at 5:08 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
However, being out there so many phones without such support, it is practically unusable since service providers won't deploy different server solutions for each group of devices, so they stick to one size fits all and that is not DNS for now.
Devices don't implement it, so service providers don't implement it, so devices don't implement it, so... XD
We use SRV extensivly, and indeed as the main means of redundancy.
However, there are lots of issues with UA implementations of SRV, most notably when they're behind NAT and jumping between different records.
Others will not ever expire it's cache, and stick to the same one. Even 2 months after we removed an RR from SRV, we're still seeing some devices using that proxy (!!).
Asterisk is particularly bad at doing SRV, to the point we've had to give it it's own DNS record:
http://wiki.voip.co.uk/products/asterisk#asterisk.bugs
There are STILL some (mainstream) devices out there that don't support DNS. this means we're forced to give IP addresses to customers, which of course is bad for redundancy and capacity planning.
As a result, we've devoted (read: wasted) a lot of time and effort on implementing anycast for our platform rather than rely on devices supporting SRV properly. It works, but it's far from pretty and something we should never have had to have done.
I'm not actually sure which is better - devices that don't support SRV, or those that try and implement it but don't get it right :-)
On the same note, it's shocking how many devices bail out after receiving a 503 and just give up. Please, implementers: 503 does not mean "never try registering again".
Proper DNS support should be enforced somehow (who knows how?!?) before anything else. At the end, DNS drives the IP world.
IMHO RFC 3263 complexity doesn't help too much.
I don't see any real complexity in RFC 3263 for a well engineered stack. What do you see as being complex about it?
~ Theo
On Thu, Feb 26, 2009 at 3:26 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
RFC 3263 (Locating SIP Servers) is really complex, NAPTR is really complex, and it's not needed in 99% of current SIP deployments, so vendors don't implement it. If a SIP provider whises to use NAPTR records then all its clients should implement it in their SIP phones (obviously this is unfeasible for now). Solution? don't use NAPTR at all.
Not at all true. It is easy to deploy, and works just fine as long as you know the issues involved.
Almost every technology in use on the 'net has issues with different clients. Working around them is part of the job of SPs or vendors.
NAPTR and SRV really aren't complex - although perhaps there are some issues in the quantity/quality of documentation out there if you're having problems with it.
On Thu, Feb 26, 2009 at 2:57 PM, Olle E. Johansson oej@edvina.net wrote:
IETF guys should visit our planet someday.
Agreed. There are some people - me included - who live on both planets. but as time goes by, those people are becoming less and less. This is mostly, it would seem, due to many of the people who used to be active in being acquired by large vendors who then get them working on other things or change their direction or thinking :-)
This is a problem I realize at every SIPit. The implementations are far away from the IETF world. And the gap doesn't seem to close.
This is the issue I see at every IETF meeting, and in a lot of on-list discussions. Implementers need to get more involved!
The IETF is *not* a closed process - it's open to everyone. If anyone is unhappy about the direction that the IETF is going, them please please please: get active in the process!
Basic stuff like DNS is not understood or used by many SIPit attendees so even trying to mention NAPTR is too complex, and it's necessary for many security scenarious.
perhaps this is another major issue then - the fact that some implementers don't understand the protocols they're writing software for
Implementers can't make an informed decision about NAPTR/SRV unless they understand it, as well as all the other DNS issues that exist. (on that note, the number of DNS client's that don't randomise QID or sport is shocking). Perhaps they should learn the protocols :-)
now, this leads on to another topic ...
The big question is how to close this gap. I have no clue.
- Can we stop the IETF SIP development during a year and work on
implementations, testing and reality checks?
no! (!!)
- Would it be possible to get more implementation guidelines published?
absolutely. and i think this is where we're going wrong at the moment on the implementer side. We don't have any real "implementers guides" that can be a helping hand to people trying to get up to speed on protocols involved. Almost the whole of SIP requires wrapping your head around many, many issues crossing many RFCs and protocols and "learned experience".
Although, i'll add that many people have managed to understand the protocols without such a guide, so it is possible - but takes many years. Don't expect to just be able to sit down read a book, not get involved in the SIP community, scan a few rfcs/drafts, and suddenly and magically understand SIP. it takes time - there are *lots* of quirks, and a sizeable chunk of undocumented philosophy.
We have at least two cases now where an update to the RFC added important MUSTs:
- Tel uri - phone-context is now required, which affects all SIP
devices using SIP uri with user=phone regardless if they use a Tel: URI.
- RFC2833 DTMF is updated and secure RTP is now required
Will these changes be implemented at all? When?
Yes, they will at some point. Although the problem in RAI is that no one seems to have any time to actually do stuff. So anyone who feels strongly should get involved!
Out of interest - how many people on sip-implementors@ that are actually maintaining SIP implementations are going to be at ietf74 and feel strongly about these issues?
~ Theo
We have at least two cases now where an update to the RFC added important MUSTs:
- Tel uri - phone-context is now required, which affects all SIP
devices using SIP uri with user=phone regardless if they use a Tel: URI.
Sincerelly I can't understand the usage/requeriment of "user" parameter. How would detect a phone if the dialed number is a PSTN number or an extension? For example: - 1004 is a short number in Spain (Telefonica) - 2002 could be a domain user
How
I expect that phones don't need to implement all the PSTN dialplan of the world :)
-----Original Message----- From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip- implementors-bounces@lists.cs.columbia.edu] On Behalf Of Iñaki Baz Castillo Sent: Friday, February 27, 2009 4:59 AM
We have at least two cases now where an update to the RFC added important MUSTs:
- Tel uri - phone-context is now required, which affects all SIP
devices using SIP uri with user=phone regardless if they use a Tel: URI.
Sincerelly I can't understand the usage/requeriment of "user" parameter. How would detect a phone if the dialed number is a PSTN number or an extension? For example:
- 1004 is a short number in Spain (Telefonica)
- 2002 could be a domain user
How
The short answer is you don't. Hardly anyone uses/encodes/looks-for the phone-context param in practice (and not many folks use the Tel: URI scheme either, btw - they just encode it in a sip scheme).
As for the user=phone, it's been a major source of confusion for folks since many devices don't encode it (because as you note they have no idea if it's a telephone number or just a username string of digits). In practice what happens is the "proxies" often treat the username portion as a phone number if it's comprised of digits or looks like an E.164, regardless of the user=phone param. So far that's worked ok, but it may lead to problems someday.
-hadriel
Dear Kamailio users,
Thank you for your help about the concept of TLS & SIPS. I still confuse with the scenerio of how to use SIPS/TLS to make security VoIP by Opensips. I got the information like following from console after run opensips 1.4.0 with TLS enabled.
Listening on udp: 192.168.1.11 [192.168.1.11]:5060 tcp: 192.168.1.11 [192.168.1.11]:5060 tls: 192.168.1.11 [192.168.1.11]:5061 Aliases: tls: wavehost:5061 tcp: wavehost:5060 udp: wavehost:5060
As RFC3261 said, 5061 is default port for SIP. So, there are two ports here after TLS enabled. My question is how to configure my UA to use the SIP server? In the other word, how to use SIP server with TLS enabled? My UA is SJphone 1.6, seems it doesn't support SIPs/TLS. Is there any open source SIP UA which support TLS availiable ?
Best regards, Steven Wu
________________________________
From: users-bounces@lists.kamailio.org 代表 Henning Westerholt Sent: 2009-2-25 (星期三) 18:05 To: users@lists.kamailio.org Cc: Steven Wu Subject: Re: [Kamailio-Users] Secure VoIP
On Wednesday 25 February 2009, Steven Wu wrote:
Does anybody know how to configure OpenSER 1.3 to support secure VoIP?
Another question about SIP is how difference between sips and TLS?
Hi Steven,
you find some documentation about TLS support in kamailio/ OpenSER here: http://kamailio.org/docs/tls.html.
SIPS is the secure variant of SIP, it uses TLS to encrypt its data.
Cheers,
Henning
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-
ALAEDDINE abbech -
Aymeric Moizard -
Bogdan-Andrei Iancu -
Daniel-Constantin Mierla -
Hadriel Kaplan -
Henning Westerholt -
Iñaki Baz Castillo -
Johansson Olle E -
Klaus Darilion -
Olle E. Johansson
-
sarvpriya -
Steven Wu -
Theo Zourzouvillys -
Victor Pascual Ávila