[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] Delivering request-URI and parameters to UAS via proxy
I think there is a misunderstanding on these use cases:
- 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.
- 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.
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