2009/1/12 Iñaki Baz Castillo <ibc(a)aliax.net>et>: Also, # symbol is allowed in a TEL URI, but not in a SIP URI userinfo part. -- Iñaki Baz Castillo <ibc(a)aliax.net>

2009/1/12 Johansson Olle E <oej(a)edvina.net>et>: 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 -- Iñaki Baz Castillo <ibc(a)aliax.net>

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?

2009/1/12 ALAEDDINE abbech <alasupcom(a)yahoo.fr>fr>: I already explained that # is not allowed in a SIP URI (also in the SIP Request URI, of course). -- Iñaki Baz Castillo <ibc(a)aliax.net>

2009/1/12 Johansson Olle E <oej(a)edvina.net>et>: 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'. -- Iñaki Baz Castillo <ibc(a)aliax.net>

El Lunes, 12 de Enero de 2009, Daniel-Constantin Mierla escribió: Well, IMHO the reason is that key '#' appears in all the phones :) I assume this is due to inheritance from common URI syntax (an username in a mail URI doesn't allow it also). 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. -- Iñaki Baz Castillo

2009/1/13 Daniel-Constantin Mierla <miconda(a)gmail.com>om>: 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 Yes, it's enough easy, thanks for pointing it out. PD: Perhaps the default script should include that line? -- Iñaki Baz Castillo <ibc(a)aliax.net>

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 02/25/2009 12:05 PM, Henning Westerholt wrote: 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 -- Daniel-Constantin Mierla http://www.asipto.com

Hello, On 02/26/2009 09:34 AM, Johansson Olle E wrote: 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 -- Daniel-Constantin Mierla http://www.asipto.com

2009/2/26 Johansson Olle E <oej(a)edvina.net>et>: 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. -- Iñaki Baz Castillo <ibc(a)aliax.net>

2009/2/26 Olle E. Johansson <oej(a)edvina.net>et>: 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. 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. Does one of these already exist? where? I would add all those especifications including new "Require" values, and also those requiring multipart (widely NOT implemented). 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. Sure, but who care? This should care to both implementators and designers, but... -- Iñaki Baz Castillo <ibc(a)aliax.net>

On 02/26/2009 06:40 PM, Klaus Darilion wrote: 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 -- Daniel-Constantin Mierla http://www.asipto.com

On 02/26/2009 07:08 PM, Iñaki Baz Castillo wrote: 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 -- Daniel-Constantin Mierla http://www.asipto.com

On 02/26/2009 07:30 PM, Iñaki Baz Castillo wrote: 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 -- Daniel-Constantin Mierla http://www.asipto.com

El Jueves, 26 de Febrero de 2009, Aymeric Moizard escribió: That's true, but it's also true that a SIP provider MUST manage its own domains in an own DNS server. -- Iñaki Baz Castillo

On Thu, 26 Feb 2009, Daniel-Constantin Mierla wrote: 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/

26 feb 2009 kl. 18.27 skrev Daniel-Constantin Mierla: 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

27 feb 2009 kl. 11.59 skrev Iñaki Baz Castillo: Ok, now I received a request. Where do I send the bill? ;-) Have a nice weekend all Kamailians! /O

Iñaki Baz Castillo wrote: I know SIP providers who are actually using SRV in real world for providing access to end-users. So DNS is out there. 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

On Thu, Feb 26, 2009 at 5:08 PM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote: 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". 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 -- Theo Zourzouvillys Chief Technical Officer VoIP.co.uk Sent from: Bicester Oxfordshire United Kingdom.

On Thu, Feb 26, 2009 at 2:57 PM, Olle E. Johansson <oej(a)edvina.net> wrote: 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 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! 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 ... no! (!!) 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. 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 -- Theo Zourzouvillys Chief Technical Officer VoIP.co.uk Sent from: Bicester Oxfordshire United Kingdom.

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