Hi Christer,
Also, since neither the PSAP or MGCF registers themselves to the
E-CSCF, the
loose-route draft mechanism wouldn't be used towards those
entities even if adopted by IMS.
I don't think that the Request URI has anything todo with
registrations.
The mechanism in the draft is only used towards users that in the
registration have indicated support for it.
This seems to be a "capability discovery" approach.
Since the PSAP does not register at the E-CSCF the "capability
discovery" would not work.
Do you expect that the call uses a different emergency call marking
technique went it enters the PSAP operator network?
I think it is up to each operator to decide how the marking is done.
In the 3GPP model with the E-CSCF and the PSAP having a close
relationship you could leave this issue open. It would,
however, make their life easier.
There will always be agreements between the PSAP operators and the
other
("public") operators using them.
Only in the 3GPP IMS alike architecture. The IETF emergency services
architecture is a bit different.
Well, you asked how it works in IMS :)
Correct. I asked for the IMS description.
But you understand that we would like to use mechanisms in a generic way
whenever possible regardless whether the call starts in a 3GPP, Wimax,
DSL, WLAN or enterprise network.
I guess it would also be possible to put the original service URN into
the P-Called-Party-Id
header (as for normal calls), eventhough I don't think it's currently
specified.
I am not sure whether this is a good solution.
Why not?
I read through
http://tools.ietf.org/wg/sip/draft-rosenberg-sip-ua-loose-route-01.txt
and I got the impression that Jonathan has encountered a generic problem
and the description he provided looked reasonable to me to argue for the
Request URI to remains unchanged end-to-end and not to use other
solutions. He listed two other solutions and the P- header approach does
not look generic to me.
Ciao
Hannes
_______________________________________________
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
