Subject: RE: [SIP] A question about Request-URI:

From: Bodgey Yin Shaohua <[email-masked]>
Date: Tue, 5 Sep 2000 13:23:55 +0530

Hi, Hisham: 
    It is a good interpretation. If so, RFC2543 need describe it more clear.

    When a Server proxy a message WITHOUT modifying the request-uri, The
problem how to select a best route to proxy the message in order to let it
go to the destination more directly is worth considering. For instance, in
the following example, why the Proxy1 don't proxy the message to there.com
directly but to Proxy2? It need a reasoned interpretation. 
    Best regards!
    
Bodgey   

-----Original Message-----
From: Hisham Khartabil [mailto:[email-masked]]
Sent: Monday, September 04, 2000 11:08 PM
To: Bodgey Yin Shaohua
Cc: [email-masked]
Subject: Re: [SIP] A question about Request-URI:

The authors of the call flows draft where under the misconception that
the request-uri has to have the proxy server address in the host part.
This was corrected in later releases.

If a proxy server receives a request with the host part matching it
domain, you handle the request by, for example, tooking up registrations
(in the registrar) for that user-name.  If no registrations are found, a
404 is returned, otherwise, the request is forwarded to the address
found in the registrar.

If a proxy server recieves a request with the host part NOT matching its
domain, the server will just forward the request to the host specified
in the request-uri WITHOUT modifying the request-uri.

Regards,
Hisham

Bodgey Yin Shaohua wrote:

>
>
> Hi,Jonathan:
>     Thank you for your reply.But I also have a puzzle according to
> your answer. Let take a example of a successful call flow. (The
> section 3.1.2 of draft-ietf-sip-call-flows-01a.txt)
>
>    User A          Proxy 1          Proxy 2          User B
>      |                |                |                |
>      |   INVITE F1    |                |                |
>      |--------------->|                |                |
>      |     407 F2     |                |                |
>      |<---------------|                |                |
>      |     ACK F3     |                |                |
>      |--------------->|                |                |
>      |   INVITE F4    |                |                |
>      |--------------->|   INVITE F5    |                |
>      |    (100) F6    |--------------->|   INVITE F7    |
>      |<---------------|    (100) F8    |--------------->|
>      |                |<---------------|                |
>
>  The F4 is :
>    INVITE sip:[email-masked] SIP/2.0
>    To: LittleGuy <sip:[email-masked]>
>    Via: SIP/2.0/UDP here.com:5060
>
>  The F5 is:
>    INVITE sip:[email-masked] SIP/2.0
>    To: LittleGuy <sip:[email-masked]>
>    Via: SIP/2.0/UDP ss1.wcom.com:5060;branch=2d4790.1
>    Via: SIP/2.0/UDP here.com:5060
>
>  The F7 is:
>    INVITE sip:[email-masked] SIP/2.0
>    To: LittleGuy <sip:[email-masked]>
>    Via: SIP/2.0/UDP ss2.wcom.com:5060;branch=721e418c4.1
>    Via: SIP/2.0/UDP ss1.wcom.com:5060;branch=2d4790.1
>    Via: SIP/2.0/UDP here.com:5060
>
>    The Proxy1 and Proxy2 have different host from the there.com, so it
> may proxy the message to there.com as indicated in the figure. Or, it
> may reject the message with 404 response, so the Call is not
> successful.
>
>    In the early version of the Call flow, the Request-URI is the
> Proxy's address (ss1.wcom.com for F4 and ss2.wcom.com for F5) which is
> right according to your explaining.
>
>    So I don't which condition is right? If we choose a situation, the
> RFC2543 may change somewhat in order to give clear contradiction.
>
>    Please check it.
>    Best regards!
>
> Bodgey
>
> > Bodgey Yin Shaohua wrote:
> >
> > Hi:
> >       I find a difference among different versons of the draft of
> SIP
> > Telephony Call Flow Examples:  Before May 2000, in the Request-URI
> of
> > SIP INVITE, there is a address of the Pxory the message will head,
> but
> > the version after this time, there is Callee's address the message
> > will head.
> >
> >      In section 4.3 of RFC2543, there writes "Typically, the UAC
> sets
> > the Request-URI and TO to the same SIP URL, pesumed to remain
> > unchanged over long time periods", so the latter case is right. But
> it
> > is difficult to explain the following word in this section that is
> > "The host part of the Request-URI typically agrees with one of the
> > host name of the receiving server. If it does not, the sever SHOULD
> > proxy the request to the address indicated or return 404 response if
>
> > it is unwilling to do so".  I don't know what is meaning of the
> > "receiving server"?
>
> Its the server that receives the request.
>
> Perhaps an example will illustrate. Lets say I am making a call to
> [email-masked]. I would send an INVITE that looks like:
>
> INVITE sip:[email-masked] SIP/2.0
> To: sip:[email-masked]
>
> Now, in one case, I will take example.com, look it up in DNS, and send
>
> it to the IP address of a server I discover through this process. The
> example.com server receives the request (it is the receiving server
> here). Now, the host part of the request-URI (example.com) matches to
> domain of that server (also example.com), so it knows how to handle
> requests for this domain.
>
> In another case, I am using a local outboud proxy at dynamicsoft.com.
> So, instead of sending the above request there, I send it to the IP
> address of the dynamicsoft.com proxy, which my UAC is configured with.
>
> Now, for this proxy, the domain of the request URI (example.com) does
> not match the domain of the receiving serer (dynamicsoft.com). So, the
>
> proxy can either forward it to example.com, or reject it with 404.
>
> -Jonathan R.
>
> --
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
>
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 05 Sep 2000 12:32:42 +0300

I think section 1.4.2 of the bis clearly describes the steps to be taken
(SRV, DNS, etc).

Regards,
Hisham

Bodgey Yin Shaohua wrote:

>     When a Server proxy a message WITHOUT modifying the request-uri,
> The problem how to select a best route to proxy the message in order
> to let it go to the destination more directly is worth considering.
> For instance, in the following example, why the Proxy1 don't proxy the
> message to there.com directly but to Proxy2? It need a reasoned
> interpretation.
>
>     Best regards!
>
> Bodgey
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 05 Sep 2000 10:31:49 -0400

"Best Route" is really a matter of local policy. In the example call
flow you gave, clearly proxy 1 did not forward to proxy 2 based on a
lookup of there.com in DNS. Instead, it chose to send to yet another
local outbound proxy. There is nothing wrong with doing so. It could be
that proxy 1 is a departmental proxy that does some stuff related to the
department, and its configured to send all outbound requests to proxy 2,
the company wide proxy that controls the firewall. From there, proxy 2
will use DNS to route the request.

I will agree that the spec needs additional clarification about the
flexibility of routing policies.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 05 Sep 2000 10:59:52 -0400

Attempt at a paragraph for the introduction:

SIP requests are forwarded by proxies. User agents send requests either
directly to the address indicated in the request URI or to a designated 
proxy (``outbound proxy'').  Each proxy can forward the request based
on    
any combination of local policy decisions and information in the
request. It {\MAY} rewrite the the request URI. A proxy {\MAY} also
forward the request to another designated proxy regardless of the
request URI. For example, a departmental proxy could forward all
authorized requests to a corporate-wide proxy which then forwards it
to    
the proxy operated by the Internet service provider, which finally
routes the request based on the request URI.

----

The introduction already has the more formal:

When a client wishes to send a request, the client either sends it to
a locally configured SIP proxy server (as in HTTP), independent of the
\header{Request-URI}, or sends it to the IP address and port
corresponding to the \header{Request-URI}.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Shail Bhatnagar <[email-masked]>
Date: Wed, 20 Sep 2000 14:12:36 -0400

On a related note, when a proxy does a successful SRV lookup for
domain.com and gets bigmachine.domain.com,5055 and 
bigm2.domain.com,6000 and it selects bigmachine.domain.com,5055.
Should it change the incoming 
sip:[email-masked] 
to 
sip:[email-masked]:5055 ??

I believe, it should.

Also, when forwarding a request using the Route header, should 
the outgoing Request-URI always be the addr-spec portion of the Route
header or it can be different due to SRV lookup on the maddr ??

Thanks,
Shail

---

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 21 Sep 2000 09:24:45 +0100

> sip:[email-masked]:5055 ??

Interesting.  I believe it should not. &:)

If you look at the rules of Section 1.4.2, all the magic done
is _based on the Request-URI_; suggesting that the Request-URI
is already well-defined at that point.

Imagine a case where you have a Large Corporation, the ubiquitous
example.com.  Now example.com has two divisions: division1 and
division2.  If there were two distinct Smith's working for
example.com, one in division1 and one in division2, then they
might have the SIP URLs
sip:[email-masked],
sip:[email-masked],
respectively.  Now if there's a large SIP proxy sitting "at the
edge" of example.com, sip.example.com, and this proxy can be
found via SRV, then changing the Request-URI could potentially
result in a fatal loss of information.  Not good.

Of course, as always, proxies are free to do what they want --
it's their birthright; thus there may well be situations where
this is exactly what you want.  In general, however, I would
argue that it is not what you want.

> header or it can be different due to SRV lookup on the maddr ??

The whole Request-URI in the Route is copied into the Request-URI
proper; maddr, transport (although this should never appear in
a Record-Route/Route), etc., parameters are no-longer illegal here.

HTH,

 - Jo.