...
> [JRE] What about the following case? Enterprise.com uses two service
> providers, sp1.net for incoming calls and some outgoing calls and
> sp2.net for other outgoing calls. It sends an INVITE request via
> sp2.net, which signs the E.164-based From URI. The SUBSCRIBE
> request is
> routed via sp1.net to enterprise.com, which will be unable to sign the
> NOTIFY request. However, if the outgoing call had gone via
> sp1.net there
> would be no problem. I am not sure whether this behaviour is a good
> thing or a bad thing.
Here is a quick ASCII diagram of what you are describing:
sp1.net-<<-
/
/
Enterprise.com -<
\
\sp2.net->>-
> Of course, if enterprise.com signs and the signature survives
> end-to-end there is no problem and the called user gets a more
> useful caller ID.
Exactly.
If enterprise.com is UNABLE to create a signature, but rather its
signatures are destroyed and over-written by sp1.net or sp2.net,
then yes, the best that can be done is trust sp1.net and sp2.net
to have Done The Right Thing. That is not too valuable to me.
If that is the only value we want or need, we already have RFC4474
that provides exactly this same characteristic.
draft-wing-sip-e164-rrc is an attempt to provide something
stronger, so that the message arrives at Enterprise.com and
they -- not their service provider(s) -- create the signature (as
you said).
-d
_______________________________________________
Sip mailing list https://www.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
