> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul > Kyzivat > > IMO if I give you sip:[EMAIL PROTECTED], with or without user=phone, > then a call back to that URI MUST be via sip, and the 3263 rules say > that it MUST be routed to domain sp.com before making any decision about > how to reach something associated with the user part.
Interesting. You said "if I give you... then a call *back* to that MUST be via sip". In what way do you mean "if I give you..."? Like in the From-URI of an outgoing request? Or out-of-band (e.g., on a business card)? Or both? > If you are originating a call from a dial string, not a URI, then I > guess you can formulate the R-URI any way you want. But if the calling > party is supplying a URI (e.g. one it has saved from a prior received > call) then it should be used as-is. So how are we to tell which one it was, if you can formulate a dial string any which way? (I'm confused) > If you want some server on the originating end to do something for the > outbound call, then you should put a Route header in the request > identifying the server. And I wish that would work, but in many cases it won't. For some of those cases I think it's because of bad equipment, and hopefully not a permanent problem. But the From-URI you end up getting has a host-part that is of the previous or local domain, instead of the real originating domain, and thus the Req/To-URI you end up generating later will likewise be the local or next-domain. If we could get wider vendor support for Tel-URIs (and Route headers), this problem will go away eventually... I hope. -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
