Subject: RE: [SIP] Re: questions on rfc2543bis

From: "Donovan, Steven R." <[email-masked]>
Date: Wed, 05 Apr 2000 08:28:47 +0000

Li Li,

Just to be clear, it is certainly legal for the request uri received at a
proxy to contain a host portion that does not point to the proxy. 

For instance, it is perfectly valid for a customer using an MCI Worldcom
proxy with a host name of sip.wcom.com to call someone with a request uri of
sip:[email-masked].  

Thus, if I wanted to call you, using my proxy server for the first hop
(maybe because that is the only way I can get the call to go through the MCI
Worldcom firewall) I can send the following INVITE request to my proxy.
Note that my user agent may be configured to send all requests to the
sip.wcom.com proxy, or I may on a call-by-call basis decide where to send
the request.

Calling UA       --------------------->  Proxy
[email-masked]                         sip.wcom.com

INVITE sip:[email-masked] SIP/2.0
Via: SIP/2.0/UDP srd.wcom.com
From: sip:[email-masked]
To: sip:[email-masked]
callid: [email-masked]
Cseq: 1 INVITE

In this case the proxy is providing the service to the calling user.  If the
proxy doesn't know anything about [email-masked] then it would proxy
the request to the ss8networks.com host, in this case assumed to be a proxy,
but it could be your end device.

Proxy            --------------------->  Proxy
sip.wcom.com                             ss8networks.com

INVITE sip:[email-masked] SIP/2.0
Via: SIP/2.0/UDP sip.wcom.com;branch=xyz
Via: SIP/2.0/UDP srd.wcom.com
From: sip:[email-masked]
To: sip:[email-masked]
callid: [email-masked]
Cseq: 1 INVITE

Note that the request uri doesn't change, just the destination for the
message.

It is also possible that the proxy is also providing a service to the called
user, in which case it may change the request uri before sending it to the
next hop.

It would probably be helpful to add a scenario like this to the call flow
document.

Steve
> -----Original Message-----
> From: Li Li [mailto:[email-masked]]
> Sent: Tuesday, April 04, 2000 9:08 PM
> To: Johnston, Alan
> Cc: Jonathan Rosenberg; [email-masked]
> Subject: RE: [SIP] Re: questions on rfc2543bis
> 
> 
> 
> 
> >
> > I thought your question might have been based on the use of
> > Request-URI in the
> > Call Flows draft.
> 
> Yes. Alan, my misunderstanding was exactly resulted from there.
> >
> > I think the Request-URIs in the draft were formulated based on
> > the (mistaken?)
> > idea that the host portion of the Request-URI should map to the
> > IP address of
> > the proxy or server (the entity to which the request was sent).
> >
> > For example, in 3.1.2 on page 25 of
> > draft-ietf-sip-call-flows-00.txt, message F4
> > has the INVITE Request-URI of [email-masked] but the To
> > header contains
> > [email-masked] where ss1.wcom.com is the Proxy Server.
> >
> > Should the Request-URI instead match the To header in this case?
> 
> Always have the host portion of the Request-URI mapped to the
> IP address of the proxy or server may have a problem when there is
> a local proxy that handles many (or all) outgoing calls for a caller.
> Put Request-URI as [email-masked] in this example may be better,
> my own take. Clearer to me. If proxy ss1 only handles calls to users
> in wcom.com, things may not be too bad if the INVITE message has
> Request-URI with ss1.wcom.com in the host portion. But say if 
> the caller
> also wants to call somebody outside of wcom.com but should 
> access through
> the
> wcom's ss1 proxy for all his services. If in this case the 
> caller UAC gets
> all the destinations in the world mapped to a unique [email-masked]
> in the Request-URI in the INVITE message, we'd have problems 
> of too many
> mappings to handle for ss1.wcom.com. Of course, probably user 
> A can send his
> different calls directly to different proxy servers of the destination
> carrier's
> network, which I don't know if it is the case.
> 
> li li
> >
> > Alan Johnston
> > MCI WorldCom
> >
> > Li Li wrote:
> > >
> > > > >
> > > > > Thanks for pointing/confirming about the unique name 
> space. Then if
> > > > > there is a "[email-masked]" and a
> > "[email-masked]",
> > > > > the proxy server needs to configure two names as
> > [email-masked] and
> > > > > [email-masked] to send the call to different 
> called destinations?
> > > >
> > > > You've lost me. If I call [email-masked] and
> > > > [email-masked], those will go to two different 
> proxies (or
> > > > possibly the same proxy doing virtual hosting). If those map to
> > > > different people, then the outgoing URIs will be different.
> > >
> > > I see the problem I have is thst from all the call flow 
> examples in the
> > > call flow draft, the INVITE message always have 
> user@proxydomain in the
> > > Request-URI and the Request-URI changes all the time from proxy
> > to proxy.
> > > For example, if the INVITE goes through proxy ss1.mciworld.com and
> > > ss2.mciworld.com. The Request-URI in the INVITE message 
> is shown as
> > > [email-masked] and then changed to
> > [email-masked].
> > > Should the caller UAC just send in Request-URI 
> [email-masked] to
> > > SS1 proxy. The SS1 does a look up and know that SS2 handles
> > > [email-masked]
> > > and proxy it to SS2? Otherwise, as in the draft, it implies to me
> > > that everyone in the mciworld.com also should have a 
> unique name in the
> > > ss1.mciworldcom.com so that SS1 can handle it.
> > > That leads me to think that when an INVITE is sent to a proxy,
> > it should use
> > > the proxy's host name in the host part of the Request-URI. But
> > as what you
> > > pointed out here, really  the Request-URI should be the 
> destination
> > > user@host
> > > and is sent to the proxy of the destination domain.
> > > Thanks for your help. Very much apprecaited.
> > >
> > > li li
> > >
> > > >
> > > > > So
> > > > > the proxy server should not serve too many different
> > destination domains
> > > > > as this would make the name management impossible to give them
> > > > all different
> > > > > names in the proxy's domain. Is this right?
> > > >
> > > > No, of course not. Why is this a problem? The proxy is 
> serving many
> > > > domains, as you say. To me, this means it handles requests for
> > > > domain1.com, domain2.com, etc. You also seem to imply 
> that these are
> > > > mapped into a single namespace in the "proxy's domain". 
> I don't follow
> > > > that. If it receives a call for [email-masked], it checks
> > its tables
> > > > for domain1.com, and finds that this is mapped to 
> [email-masked], and
> > > > sends it out to foo.com. Not all incoming request get mapped
> > to foo.com.
> > > > For those that do, its up to foo.com to properly manage their
> > namespace.
> > > >
> > > > -Jonathan R.
> > > >
> > > > --
> > > > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> > > > Chief Scientist                             First Floor
> > > > dynamicsoft                                 East 
> Hanover, NJ 07936
> > > > [email-masked]                     FAX:   
> (732) 741-4778
> > > > 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
> >
> 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 05 Apr 2000 11:59:02 -0400

What Steve is saying is exactly correct.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: "Li Li" <[email-masked]>
Date: Wed, 5 Apr 2000 12:49:21 -0400

Fully agree with what you've explained. Adding a
different scenario to the flow chart is good.

li li

---

From: "Alexei Prokofiev" <[email-masked]>
Date: Thu, 6 Apr 2000 18:51:30 +0400

Hi,

in case replies are sent by a server UA via several TCP connections (for
example,
a new connection is created for each message) close out of which of the
connetions
must be treated by a client UA as CANCEL in case the transaction is not
complete?

Thanks a lot!
-----------
Alexei Prokofiev,        mailto:[email-masked]
Software Engeneer,
Mera Labs.

----- Original Message -----
From: Jonathan Rosenberg <[email-masked]>
To: Alexei Prokofiev <[email-masked]>
Cc: sip <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, March 07, 2000 9:06 PM
Subject: Re: Several TCP connections for the same SIP transaction

> It depends on how forgiving your client is. A server is supposed to send
> responses on the same connection the requests came from, if that
> connection is still open. If the client closes the connection before the
> response comes, the server should CANCEL. If, by chance, the CANCEL and
> the actual final response pass on the wire, the server is supposed to
> open a connection to the client to send the response. Sooo, a client
> will already need to handle incoming connections for responses, but only
> in this specific case. If a server opens a new connection to send a
> response, and the initial one is still open, the server has erred. What
> the client does (handle this or not) is at its discretion. Handling this
> may be easy since it already needs to deal with a similar case.
>
> -Jonathan R.
>
> > Alexei Prokofiev wrote:
> >
> > Hi,
> >
> > should a client UA accept replies of a transaction in case they are
> > sent
> > by a server UA via several TCP connections different from the one used
> > to send the request of the transaction?
> >
> > Thanks a lot!
> >
> > -----------
> > Alexei Prokofiev,        mailto:[email-masked]
> > Software Engeneer,
> > Mera Labs.
>
> --
> Jonathan D. Rosenberg                       200 Executive Drive
> Chief Scientist                             Suite 120
> dynamicsoft                                 West Orange, NJ 07052