This question would probably be better on sip-implementors so if you reply, please remove iptel. Bit of an answer inline.
On 12/14/04 12:11 AM, "Gaurav.Kheterpal" <[EMAIL PROTECTED]> wrote: > Hello, > > I am currently implementing support for <tel:> URI's in our User Agent as > per RFC 3966/ RFC 2806-bis standards. I had the following doubts regarding > the same. Any inputs will be highly appreciated. > > 1. Contact Header: As per RFC 3261 Section 8.1.1.8, it mentions that this > URI must be in either SIP/ SIPS format. In Section 10.2.1, it is mentioned > that for registrations, the Contact header field can contain any URI Scheme > (e.g the tel URL, RFC 2806 [9]) or email addresses (with a mailto URL, RFC > 2368 [32]) as Contacts for an address-of-record. > > Does this mean that the 'Contact' field in an INVITE message must always be > a SIP/SIPS URI while in a REGISTER message, it can be a SIP/SIPS/TEL/Mailto > URI ? Yes. Pretty weird Eh? The contact header in SIP got overloaded for too many different uses but that is the way it is. Also, a 302 can have a Contact header field value that is any URI (such as tel, email). > > 2. Besides 'Request URI' and 'To:' header fields, can the TEL URI be present > in any other INVITE header values (e.g. Via, Route Header, Contact etc). It can be in a From header and the RFC 3325 P-Asserted-Identity header. It should never be in a Via. > In > other words, which fields in the INVITE request does the proxy scan for > possible tel->sip translation using ENUM/ any other mechanism ? Only the request URI. The others should never be changed by a proxy. > In case, > there is no other field which contains this information, how is the TEL URI > information propagated across intermediate proxies when the UA is configured > with a outbound proxy having a defined route set. If the defined route set > is proxy 1-> proxy 2 in the below diagram, the request will be formed using: > > INVITE sip:proxy1 > Route: <sip:proxy2> > To: <tel:1234> > Proxies never route based on the To. Again, weird but true. So to make something like this work the path below happen, you would have. The routes are used before the R-URI. (I'm assuming that proxy 2 will route 1234 to user B) INVITE tel:1234 Route: <sip:proxy1;lr>, <sip:proxy2;lr> > User A Proxy 1 Proxy 2 User B > | | | | > | INVITE F1 | | | > |--------------->| | | > > Does this mean that in such a case, the only parameter which contains the > TEL URI is the 'To' field. No the request URI should have had the tel > As I understand, this field is never processed by > the proxies unless they implement privacy/ RFC 3324(5) ?? Yes - even then the the To field is never changed by a proxy. > > I am current not aware of any proxy which is capable of handling TEL URI's, > any information/ links regarding the same will be highly useful. I think there several proxies that can do tel and ENUM - there are also several GWs capable of tel. > > Thanks in advance for your help. > > regards, > > Gaurav > Hope that helps, Cullen _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
