On 5/6/13 9:37 AM, SIP Learner wrote:
> 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?
I can't immediately think of anything that focuses on this, though there
most likely are some things. Much of this is specific to individual
implementations. And I think in many cases the implementations make this
configurable, so that it is up to the operators to decide how they want
to handle it.
Maybe somebody else who is closer to actual deployments can comment on this.
> >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!
Yes, proxies are not permitted to change the to/from headers.
Generally when the UAC sends the request the to-uri and the request URI
(R-URI) are the same. The To-URI generally has no effect on how the
message is routed - only the R-URI. And the proxies can and do modify
the R-URI.
Generally the To-URI isn't useful for much of anything.
But in practice, many/most systems now have servers called SBCs (session
border controllers). These are similar to proxies, but are actually
B2BUAs. They feel free to modify To and From headers.
> >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!
Routing an E.164 number can be complex. It requires special knowledge.
A system like a PBX, for a business, may handle this in a simple way:
- check if the number is one that belongs to it.
If so, handle it internally.
- otherwise route the request to a service provider. In simple cases
it will only have one service provider, and so will route all numbers
not its own to a single address. In such a case the service provider
is providing what is called 'sip trunking'.
A sip service provider has a harder job. As above, it can first identify
the numbers it owns/manages (via some database lookup, since there might
be millions of them), and route them to a suitable server.
For all other numbers, it needs to decide how to deliver the request.
Most service providers have peering relationships with other providers.
So they have some mechanism for looking at a number and deciding which
peer to send it to.
Good Luck,
Paul
> Thanks you again Paul and those who may tried to help!
>
> Regards,
> Zhang
>
> ------------------ Original ------------------
> From: "Paul Kyzivat"<pkyzi...@alum.mit.edu>;
> Date: Sat, May 4, 2013 10:53 PM
> To: "sip-implementors"<sip-implementors@lists.cs.columbia.edu>;
> 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 al...@atlanta.com) is
> trying to call Bob (whose SIP URI is b...@biloxi.com), her UA will (at
> least initially) populate the To header field of the outgong INVITE with
> b...@biloxi.com. But according to the above quote enclosed in asterisks,
> when sending outgoing request to Bob, Alice (the requestor) will
> FREQUENTLY inclue b...@atlanta.com 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 (b...@biloxi.com). 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:b...@biloxi.com. 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:+12125551...@example.com;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:2125551...@example.com;user=dialstring
> >
> >But often it may simply be sent as:
> >
> >sip:2125551...@example.com
> >
> >or
> >
> >sip:2125551...@example.com;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
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
