Delivering request-URI and parameters to UAS via proxy

(As WG chair)

We have a couple of milestones that we generated as a result
of
discussion of 

http://www.ietf.org/internet-drafts/draf
t-rosenberg-sip-ua-loose-route-0
1.txt

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)  

This work is currently stalled and the editor needs input.

The document contains various example scenarios where a
solution is
required, for which there appears to be no dispute that a
solution is
needed.

The document proposes one solution to resolve these example
scenarios,
but this solution is not gaining consensus. At least one
other solution
has been talked about, but there is no documentation on the
table.

This mail is to identify a deadline for other solutions to
the example
scenarios to be documented as internet drafts, showing how
the solution
works for those scenarios. This deadline is:

	January 11th 2008

It is appropriate fo these documents to identify any other
scenarios
where such a solution is appropriate. Any other input is
also welcome in
identifying other scenarios.

If we have no such internet-drafts by this deadline, we will
proceed
with completing the solution we have.


Regards

Keith



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Hi,
 
In order to think about documenting "alternative
solutions", I have a question for clarifications
regarding the scope of the problem we are trying to solve.
 
The MECHANISM part of the draft says that a UA supporting
the mechanism would indicate it to the registrar, and the
registrar would only use the mechanism in case the UA has
indicated support for it (that is also shown in the example
in the draft). It has also been claimed that this would be
backward compatible with an MGC which uses the R-URI to map
to ISUP Called Party number, because the MGC does not
register so the mechanism would not be used towards it. 
 
My question is: does this mean that the only entity allowed
to use this mechanism is the registrar, since the mechanism
is used based on whether the UA supports it or not? 
 
When reading the USE-CASE part of the draft, I would say
that the answer is "no". Because, as I understand
the text, there could be non-registrar entities in the path,
which today normally would re-write the R-URI, but would now
instead use this mechanism. Is my understanding correct?
 
If so, my next question is: these non-registrar entities
have no clue about whether the terminating UA supports the
mechanism or not, or whether the call will be routed towards
an MGC. So, what happens if the request is routed towards an
UA that has not indicated support, or towards an MGC? The
MGC may not be able to map the R-URI.
 
Regards,
 
Christer
 
 

________________________________

Lähettäjä: DRAGE, Keith (Keith) [mailto:dragealcatel-lucent.com]
Lähetetty: ti 4.12.2007 16:27
Vastaanottaja: sipietf.org
Aihe: [Sip] Delivering request-URI and parameters to UAS via
proxy



(As WG chair)

We have a couple of milestones that we generated as a result
of
discussion of

http://www.ietf.org/internet-drafts/draf
t-rosenberg-sip-ua-loose-route-0
1.txt

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) 

This work is currently stalled and the editor needs input.

The document contains various example scenarios where a
solution is
required, for which there appears to be no dispute that a
solution is
needed.

The document proposes one solution to resolve these example
scenarios,
but this solution is not gaining consensus. At least one
other solution
has been talked about, but there is no documentation on the
table.

This mail is to identify a deadline for other solutions to
the example
scenarios to be documented as internet drafts, showing how
the solution
works for those scenarios. This deadline is:

        January 11th 2008

It is appropriate fo these documents to identify any other
scenarios
where such a solution is appropriate. Any other input is
also welcome in
identifying other scenarios.

If we have no such internet-drafts by this deadline, we will
proceed
with completing the solution we have.


Regards

Keith



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip




_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Christer Holmberg wrote:
> Hi,
> 
> In order to think about documenting "alternative
solutions", I have a
> question for clarifications regarding the scope of the
problem we are
> trying to solve.
> 
> The MECHANISM part of the draft says that a UA
supporting the
> mechanism would indicate it to the registrar, and the
registrar would
> only use the mechanism in case the UA has indicated
support for it
> (that is also shown in the example in the draft).

For when a proxy is talking to a registered UA, yes.

> It has also been
> claimed that this would be backward compatible with an
MGC which uses
> the R-URI to map to ISUP Called Party number, because
the MGC does
> not register so the mechanism would not be used towards
it.

That is not the intent.

The idea is, any proxy that is translating a request-URI, is
doing so 
based on some kind of mapping table. There are many ways
that this 
mapping table can get into the proxy:

1. dynamically through register
2. provisioned
3. through an enum query
etc.

If we take provisioning as an example (i.e., someone enters
phone number 
routing rules via prefix matching rules), when those rules
are 
provisioned, they would include a flag which says whether
the 
destination is loose-route compliant. If they are loose
route compliant, 
the proxy uses a Route header, else it uses r-uri
translation as is 
currently done.

> 
> My question is: does this mean that the only entity
allowed to use
> this mechanism is the registrar, since the mechanism is
used based on
> whether the UA supports it or not?

As above, no.

> 
> When reading the USE-CASE part of the draft, I would
say that the
> answer is "no". Because, as I understand the
text, there could be
> non-registrar entities in the path, which today
normally would
> re-write the R-URI, but would now instead use this
mechanism. Is my
> understanding correct?

Yes.

> 
> If so, my next question is: these non-registrar
entities have no clue
> about whether the terminating UA supports the mechanism
or not, or
> whether the call will be routed towards an MGC. So,
what happens if
> the request is routed towards an UA that has not
indicated support,
> or towards an MGC? The MGC may not be able to map the
R-URI.

Hopefully the above paragraph answers your question.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall
St.
Cisco Fellow                                   Edison, NJ
08837
Cisco, Voice Technology Group
jdrosencisco.com
http://www.jdrosen.net 
                       PHONE: (408) 902-3084
http://www.cisco.com


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip