> (This is getting me to lean more towards my email-identity straw-man. With > it, we can step out of this festering, smelly pile of trying to get E.164 > working well with SIP and move to email-style SIP URIs. The IETF is capable > of building an end-to-end identity/authentication solution around email-style > SIP URIs; we have one (RFC4474) that works if we prohibit SBCs and B2BUAs from > modifying SDP).
I believe this is the conclusion and about sums it up. Henry On 4/9/08 11:20 PM, "Dan Wing" <[EMAIL PROTECTED]> wrote: > > >> -----Original Message----- >> From: Francois Audet [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, April 09, 2008 8:04 PM >> To: Dan Wing >> Cc: [email protected]; Paul Kyzivat; Juha Heinanen >> Subject: RE: [Sip] E.164 - who owns it >> >> Well, you can still do video over PSTN with H.320. I still >> view this as "telephony". > > Sorry -- please pick something you cannot do over the PSTN. Instant > Messaging, presence, high-quality video (HDTV), whatever. > >> Not sure I understand the question. > > Let me reword my previous email into a question: > > If you have a non-SIP telephony application that trunks towards the PSTN, and > it is configured to process tel URIs, and it is asked to initiate a call that > exceeds the capabilities of the PSTN (instant messaging, presence, > HDTV-quality video, whatever you prefer) -- would it route the call towards a > "SIP trunk" in order to gain the ability to set up that call, abort the call, > or just ignore it all and trunk towards the PSTN? > > An additional question (statement, actually) is: We can't influence how that > non-SIP telephony application provides for its own identity and authentication > of tel URIs. > > (This is getting me to lean more towards my email-identity straw-man. With > it, we can step out of this festering, smelly pile of trying to get E.164 > working well with SIP and move to email-style SIP URIs. The IETF is capable > of building an end-to-end identity/authentication solution around email-style > SIP URIs; we have one (RFC4474) that works if we prohibit SBCs and B2BUAs from > modifying SDP). > > -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 _______________________________________________ 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
