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
[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
Envoyé : lundi 14 janvier 2008 17:58
À : [email protected]
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
[EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
