26 feb 2009 kl. 10.52 skrev Theo Zourzouvillys: > On Thu, Feb 26, 2009 at 9:38 AM, Johansson Olle E <[email protected]> > wrote: >> TO be picky - you say only host. Does this also imply that the domain >> part is indeed a host and should not be looked up for NAPTR/SRV >> records? >> >>> >>> >>>> And user=<other-user> >>> >>> RFC4967 is the other defined one. >> >> Thanks. user=dialstring >> Anyone that has seen this anywhere? > > Yes - we use it. > >>> note however that 2806 (which 3261 references for >>> telephone-subscriber) does not MUST the context parameter, only >>> SHOULD >>> - however rfc3966 (which updates 2806) makes the phone-context >>> parameter a MUST. > > (note that 2806 conflicted itself regarding if the context was > required. in one place in 2.5.2 it says it MUST, and in another in > the same section it says it SHOULD; 3966 fixes this in both text and > BNF) > >> Thanks for that update! That was an important change indeed. The >> problem >> here is >> always interoperability. If we force that in software - rejecting >> calls with >> user=phone >> and no phone-context - users will start screaming. > > I'm not suggesting you do - but do ensurre you parse the > ;phone-context and other parameters in the user portion when > user=phone or dialstring - a lot of devices break when you send this > atm. Phone numbers are really simple if passed around properly, it's > just most people don't :) Well, I have some architecture issues on what to do with the context in regards to Asterisk. We can map it directly to the dialplan, which is an interesting feature. Propably the easiest path to take. > > >> As always, we should propably try enforcing this, which means that >> in most >> cases >> moving treating user=phone as user=dialstring on incoming calls and >> setting >> user=dialstring >> on outbound will match the current level of implementations. > > note that user=dialstring requires a context parameter.
Oh dear, you shot my theory directly, propably from the hip too :-) Thanks, /O _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
