Thank you very much for your valuable information Paul!
I did some homework after receiving your kind reply. But I still have some new question concerning your answer, I hope you (or some other fellow guys on the mail list) will again take some time to give me some help. Thank you in advance! Following I will first quote your answer to my previous post in parts and ask my questions below the qoute. Qoutes from your reply will start with a '>' on each line, and I enclose the key portion of your answer to make them stand out, if necessary. >In principle, the domain portion of the sip URI *should* denote the >domain which hosts that particular number. But often these are >constructed using whatever domain is convenient, usually that of the >caller's service provider. ***Further explanation of that is a longer story >than I want to type here.*** Could you please refer me to some materials describing the detailed story about how a numeric SIP URI is handled in practice? >Other times a server acting on behalf of the caller may do it. In that >case the string of digits that were dialed need to be conveyed to the >server that will do the translation, by encoding them as a URI. > I learned from some other place that the proxies traversed by a request can not change the To header field of the request. So what role does the server acting on behalf of the caller to translate a dialed number to a URI play? Is it a normal proxy or is it a B2BUA? references to this subject is greatly appreciated! >In all these cases, the call will presumably be routed to a server for >example.com. It then may handle it directly if it is responsible for >that number. Or ****it may translate to an E.164 number and route it to >another server in a different domain****. The detailed routing of phone >numbers is complex, so I won't discuss it here. How can an E.164 number be routed in SIP? By "a different domain", do you mean a separate SIP network or the PSTN? Again, references to this subject is greatly appreciated! Thanks you again Paul and those who may tried to help! Regards, Zhang ------------------ Original ------------------ From: "Paul Kyzivat"<[email protected]>; Date: Sat, May 4, 2013 10:53 PM To: "sip-implementors"<[email protected]>; Subject: Re: [Sip-implementors] A question about Section 8.1.1.2 of RFC3261(To header filed) Zhang, On 5/4/13 6:31 AM, SIP Learner wrote: > Hi, everyone! > > > I am a newcomer to SIP and I have a problem with Section 8.1.1.2 of RFC3261. > > > Following is a short qoute from Section 8.1.1.2 of RFC 3261 (I enclosed the > key sentence within asterisks to make them stand out): > > > "A UAC may learn how to populate the To header field for a particular request > in a number of ways... Frequently, the user will not enter a complete URI, > but rather a string of digits or letters (for example, "bob"). ...*** The RHS > will frequently be the home domain of the requestor, which allows for the > home domain to process the outgoing request."*** > > > As far as I know, when Alice (whose SIP URI is [email protected]) is trying > to call Bob (whose SIP URI is [email protected]), her UA will (at least > initially) populate the To header field of the outgong INVITE with > [email protected]. But according to the above quote enclosed in asterisks, when > sending outgoing request to Bob, Alice (the requestor) will FREQUENTLY inclue > [email protected] in the To header field, where atlanta.com is Alice's home > domain. What does this mean? I am really confused :-( > > > Anyone please help me out with this, thank you very much! >This is all about user interface, and isn't standardized. >In common practice there is a big difference between numeric addresses >(phone numbers) and email-style addresses ([email protected]). For better >or worse, most of the focus with sip has been on phone numbers. > >For email-style addresses there isn't enough information in "bob" to >infer that it should be sip:[email protected]. So either the user must type >in more. If he just types "bob" then you *might* decide this means the >bob in the same domain as the caller, or else just consider it an error. >Or if you have access to an address book you could look up "bob" there >and translate it to a url. > >For numbers, things are handled differently depending upon the system, >and often revised while flowing through the network. The generally >preferred way to represent phone numbers in SIP is via a "tel:" URI (RFC >3966), or else a sip URI with the user part having the same format as a >tel URI. E.g., > >tel:+12125551212 >sip:[email protected];user=phone > >In many respects the two URIs above are equivalent. The syntax beginning >with "+" denotes an E.164 number, including a country code. > >Some systems don't support the tel: uri itself, and expect the sip form. > >In principle, the domain portion of the sip URI *should* denote the >domain which hosts that particular number. But often these are >constructed using whatever domain is convenient, usually that of the >caller's service provider. Further explanation of that is a longer story >than I want to type here. > >Of course callers will typically not want to type that full sip URI, or >the tel URI, or even the E.164 number. They will usually type something >shorter that is unambiguous in the context of the caller. In that case >*something* will probably need to expand it into the E.164 form. >Sometimes the calling device can do that. > >Other times a server acting on behalf of the caller may do it. In that >case the string of digits that were dialed need to be conveyed to the >server that will do the translation, by encoding them as a URI. For >instance, perhaps the caller dialed "2125551212". The best sanctioned >way of representing that is: > >sip:[email protected];user=dialstring > >But often it may simply be sent as: > >sip:[email protected] > >or > >sip:[email protected];user=phone > >(The last, with user=phone, is *incorrect* but still sometimes used.) > >In all these cases, the call will presumably be routed to a server for >example.com. It then may handle it directly if it is responsible for >that number. Or it may translate to an E.164 number and route it to >another server in a different domain. The detailed routing of phone >numbers is complex, so I won't discuss it here. > >Business systems, with internal extensions may use variations on these >approaches. > >Good Luck, >Paul > > _______________________________________________ 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
