> I don't have any objections. I have only clarified how it works in IMS, > and why. It's up to you to decide what/if to do with that information. I think we understand that. It may be that the PSAPs will require one or the other solution in calls placed towards them, but I don't see a big problem dealing with that.
As I pointed out, the proposed IMS solution does not even meet the existing specification, let alone anything new. > > Also, in the ECRIT documentation, I think you should indicate that your > solution does not work with MGCs that route the destination number based > on the Request-URI (that is not an IMS specific MGC behavior). That is correct. None of ecrit works with TN based routing. In the U.S. i3 system, it would be required that the MGC arrange a TN to location translation, followed by a LoST query to obtain a PSAP URI and routing per normal SIP standards towards the PSAP. The incoming SIP call will need the Route header in i3 unless we decide to accept the IMS alternative. The current version of the i3 specification does not. > > I do have one question for clarification, though: in the examples there > is only one Route header, pointing towards the PSAP. IF there are > intermediate entities that also need to be in the path, is it assumed > that the one inserting the PSAP Route has information about those, in > order to insert Route headers also for those entities if needed? I would expect that the ESRP could replace the Route header if it needed to. It could indeed put more than one Route header on the call. Brian _______________________________________________ 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
