Hannes,
The scenarios seem pretty reasonable to me, with one qualification on
the last one:
If the R-URI contains a "dial string" then the proxy may replace it with
a Service URN if the proxy is responsible for the domain of the service
URN. That of course assumes that the "dial string" is encoded as a SIP
URI, rather than a TEL URI. (But that seems most likely since there is
no standard way to encode a dial string as a TEL URI.)
If the proxy is not responsible for the domain of the dial string then
it can't relace the R-URI. That is a rule that I think we *must*
preserve. Only a node responsible for the domain is allowed to interpret
the user part, including determining that it is an emergency number.
Paul
Hannes Tschofenig wrote:
Hi all,
after some discussions on the usage of the Service URN it seems that
most people in ECRIT agreed to move forward with the initially planned
approach. Below, you can find a description of how the Service URN would
be used in various scenarios.
Are there any objections?
Ciao
Hannes
---------------------
== End Host Procedures ==
* UA does not recognize the emergency call.
To: Dial String
Request URI: Dial String
No Route header
* UA runs LoST and determines the PSAP URI:
Request URI: Service URN
To: Service URN
Route Header: PSAP URI
* UA does not run LoST but recognizes the emergency call.
Request URI: Service URN
To: Service URN
No Route header
== Proxy Procedures ==
* Incoming request contains Service URN; Proxy runs LoST
and determines the PSAP URI
--- Input:
Request URI: Service URN
To: Service URN
No Route header
--- Output:
Request URI: Service URN
To: Service URN
Route Header: PSAP URI
* Incoming request contains Dial String; Proxy runs LoST
and determines the PSAP URI:
--- Input:
Request URI: Dial String
To: Dial String
No Route header
--- Output:
Request URI: Service URN
To: Dial String
Route Header: PSAP URI
Remark: "Dial String" refers to http://tools.ietf.org/html/rfc4967
_______________________________________________
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
