I think RFC3261 is quite clear that routing of incoming SIP calls should be done based on the Request-URI and not on the TO field. I.e. the Request-URI is the current called party number (CPN) and the TO should be considered the original called number (OCN).
Yet I am running into trouble with other implementations that expect calls to be routed based on the TO field rather than the Request-URI. Do you guys face similar problems and how do you resolve them? Regards, Danail Kirov -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Olle E. Johansson Sent: Friday, February 27, 2009 05:57 To: Theo Zourzouvillys Cc: SIP Mailing list Implementors Subject: Re: [Sip-implementors] [Kamailio-Users] Secure VoIP 27 feb 2009 kl. 08.49 skrev Theo Zourzouvillys: > On Thu, Feb 26, 2009 at 2:57 PM, Olle E. Johansson <[email protected]> > 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! I think what you're saying here is really the core. We need to expand the IETF group and be able to give more feedback. And be helpful to new developers. This mailing list is an essential tool. It's almost impossible to go through all the SIP and SIP related RFCs and get a clear picture. Before you implement - ask on the mailing list. Even though I've read documents to my eye bleed and hacked SIP code for many years, I still learn new things on this list (and find new bugs in the software I develop). Iñaki's list of questions during the last year, and a lot of other mails should be compiled into a "Hitchhiker's guide to SIP development" RFC. I will attend IETF in Stockholm :-) I do hope to see a lot of you all here in Stockholm during July! > >> 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 I discussed with Robert Sparks if we could start adding a few days in front of SIPit for doing a quick training for newbies, going through some very basic things like - DNS' role in SIP - SIP routing - Request-URI vs To: - Caller ID handling Maybe also an update for others on things considered important - GRUU's - TLS handling - Identity - ... > > > 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. Dale Worley wrote a very good implementor's guide to GRUU, which made things a lot easier for me. It was a very good start! > > >> 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! > Well, they will only be implemented if they solve an existing problem. As long as SIP is confined to private networks or PSTN-over-IP last- mile-access applications, a lot of the issues that solutions like secure identity, GRUU's and others solve won't be a big problem.... Open Source has a way of showing what's important for developers and the people who pay them. There are unfortunately reasons why SRV and NAPTR support in Asterisk is non-existent or just bad, why there's no GRUU support and why the TCP/TLS implementation stinks. A very crude reality check. Theo, I really appreciate this kind of feedback. Thanks! /O _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
