[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Delivering request-URI and parameters to UAS via proxy
youssef.chadli at orange-ftgroup.com wrote:
I think there is a misunderstanding on these use cases:
Quite possible.
- The intermediate entity in the customer side does perform only one registration to the network.
The AoRs associated to the served terminals inside the client domain are registred automatically
by the home network, using implicit registration for example. In fact, it's not conceivable to
register individually all the users of a corporate network for example.
You seem to be describing one of the models covered by the SIPForum in
their SIPConnect specification. Is that what you mean?
From the point of view of the registrar this seems similar to IMS
implicit registration, except that the scale is much larger - there may
be *very many* implicit registrations generated by this one explicit
registration.
- The "intermediate entity" should be able to route incoming requests inside its domain based on
standard RFC3261 behaviour, that is, based on the Request-URI.
I find the case much less compelling than the IMS case.
IMO this is an abuse of REGISTER to a purpose for which it is not well
suited.
Treating it as registration means that there is an *expectation* that
the R-URI will be translated. That isn't really appropriate in this
case. The registration doesn't specify the mapping anyway - it is
configuration in the network of all the addresses that belong to the
"pbx" that does that. This is more appropriately viewed as just a
routing operation, and so pushing the address of the enterprise server
as a Route header is by far the best choice. Its only because this has
been done using REGISTER that brings up how to preserve the old address
when it is translated.
Thanks,
Paul
Best regards
Youssef
-----Message d'origine-----
De : Paul Kyzivat [mailto:pkyzivat at cisco.com]
Envoyé : lundi 28 janvier 2008 21:46
À : CHADLI Youssef RD-CORE-ISS
Cc : drage at alcatel-lucent.com; sip at ietf.org
Objet : Re: [Sip] Delivering request-URI and parameters to
UAS via proxy
These cases can all be handled by having intermediate entity
use a unique user part, together with its own domain name, to
construct a contact address for each terminal UA that it is
registering. Then when it receives an incoming request to one
of these uris it can simply translate it, using the user part
as a key to its own local mappings.
We don't need anything new to solve these cases.
Paul
youssef.chadli at orange-ftgroup.com wrote:
There are other cases similar to what is described in
section 2.1 Unknown Aliases of J. Rosenberg draft that
should be taken into account.
Those cases are where the customer side is composed of
several SIP terminals that access the network through an
intermediate entity which registers their associated aliases
with its contact address. Thus, such client side is seen from
the network as a single client having several aliases
(aggregated endpoints). Moreover, such client side may be a
mini private network composed of several entities. In these
configurations, the intermediate entity is in charge of
routeing incoming calls inside the client domain and may need
to behave as a SIP proxy for incoming SIP messages.
As examples of such configuration:
- Corporate networks: in that case the PBX register all the
served individual user identities with its contact address
and routes incoming calls toward the individual called users.
- Home networks: the Home Gateway may need to register on
behalf of all the served terminals. The Home Gateway is in
charge of routeing incoming calls toward the individual called users.
J. Rosenberg draft seems give a good solution to take into
account these configurations.
Best regards,
Youssef
-----Message d'origine-----
De : DRAGE, Keith (Keith)
[mailto:drage at alcatel-lucent.com] Envoyé :
lundi 14 janvier 2008 17:58 À : sip at ietf.org Objet : [Sip]
Delivering
request-URI and parameters to UAS via proxy
(As WG chair)
In fulfilment of our charter items of
Dec 2007 Delivering request-URI and parameters to UAS
via proxy to
WGLC
Feb 2008 Delivering request-URI and parameters to UAS
via proxy to
IESG (PS)
We now have a couple of proposals on the table for solving the
problem.
The original draft from Jonathan and which led to the
creation of the
charter items by the WG is unfortunately expired, but is at:
http://tools.ietf.org/id/draft-rosenberg-sip-ua-loose-route-01.txt
The alternative document from Christer, etc is at:
http://www.ietf.org/internet-drafts/draft-holmberg-sip-target-
uri-delive
ry-00.txt
We obviously need to make a decision between the two approaches so
please attempt to address the following specific points via the
mailing
list:
1) Problem cases: These are summarised in section 4.4 of
draft-rosenberg-sip-ua-loose-route-01 and from my read of
the other
draft, I don't believe that this draft adds any others.
If you believe there are other cases that should be covered by the
solution, then please identify them. If there is support
on any new
problem cases, I would encourage the authors of both drafts to add
text concerning these problem cases.
2) Clarifications: If for any reason you don't understand either
draft, or believe that there are technical issues that are not
represented in the current draft, please post your questions /
comments to the list. I would encourage authors of both drafts to
revise as frequently as appropriate to reflect the current
state of
discussion.
3) Support for either position. If you wish to indicate support for
either position please do so, but please accompany this is
technical
reasoning as to why you have this position, as that will
help other
members of the WG form a position.
I would encourage as much list discussion as possible before
Philadelphia. I suspect we will need to have a discussion at the
face-to-face meeting in Philadephia, but list discussion
is essential
prior to that. If we can solve this positions on list,
then well and
good, and even better (that is how we are meant to make decisions).
Regards
Keith
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
sip-implementors at cs.columbia.edu for questions on current sip Use
sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
sip-implementors at cs.columbia.edu for questions on current sip Use
sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip