[SIPForum-techwg] Question re Application Server

[Jay Batson]

By the way, all:

In terms of process, I saw some emails previously about "getting this  
done before Tuesday."

The formal state of the current Recommendation is "Proposed  
Recommendation."  (See http://tinyurl.com/hmk84 ). The current  
process description says it will stay in this state until there are  
at least 2 implementations that, together between them, implement the  
bulk of the Recommendation, and have proved to successfully  
interoperate (preferably at a SIPit.)

I had intended in the process description to allow for the  
possibility that, during the implementation / testing phase, there  
are likely to be things were not fully, or correctly considered in  
the drafts leading up to, and including the Proposed Recommendation  
state, and that accordingly there could be a limited amount of draft  
revision between PR and Adopted status.

It turns out I didn't actually *say* this.  I meant to....

So assuming people think it's a good thing to add (I do), I'll add  
something explicit to sf-draft-admin-batson-recommendations-6 about  
this and ask for people to consider it.

But, that specific change doesn't directly address the current case  
-- where we've found changes we want to make, and they should  
probably be made to the current draft *prior* to implementations, for  
the benefit of the implementers.  But since the doc is in PR state,  
do changes to it mean that it drops "out" of PR state back into  
Working Draft state?  Or is the notion of a PR something that  
shouldn't exist at all until *after* implementations?  (The latter is  
a bit troublesome from a reality perspective;  announcing entry into  
PR-state is what we're making our big press brouhaha about tomorrow....)

Thoughts on process to handle the current situation?
-jb


On Sep 11, 2006, at 4:14 PM, Paul Kyzivat wrote:

>
>
> Chris Sibley wrote:
>
>>> Chris, I think this highlights a real problem regarding callerid
>>> processing. What algorithm *should* the PBX use to decide what to
>>> display as the calling identity?
>>>
>>> As things stand, it must base this on From. But is the From value to
>>> be trusted?
>>>
>>
>> Not any more or less so than the caller-ID information delivered from
>> the PSTN (over a TDM connection) today...
>
>>> I guess if the PBX has a contract with the SP, then the contract  
>>> could
>>> state that the SP warrants that the From value is valid, and then  
>>> the
>>> PBX could trust it for purpose of generating a callerid display.  
>>> That
>>> would work for the gateway case that is covered.
>>>
>>
>> Since the SP can't 100% verify the CID information received from the
>> PSTN then I don't think that it could warrant to an enterprise  
>> that the
>> contents of the 'From:' field will be valid in any case.
>
> I think that is not so clear.
>
> Please correct me if I am wrong, but I think the SPs have a  
> contractual
> transitive trust relationship with one another. And they have a way to
> indicate that a number they are reporting is not trusted. When
> connecting a PBX, I think the SP is obligated to either:
> - have a contractual transitive trust relation with the PBX operator
> - check that the number reported by the PBX is one it is authorized
>    to use
> - mark the number provided by the PBX as untrusted.
>
> If the above is true, then either the received number is marked
> untrusted, or else it is trusted based on a chain of transitive trust
> backed up with legally enforceable contracts.
>
> That is stronger than taking a SIP From header on blind faith.
>
> (I should check my Vonage subscriber agreement to see if I am legally
> prevented from causing my UA to lie about its identity.)
>
> It would be interesting to see some lawsuits over forged caller id.
>
>>> But then what about the inter-enterprise case where the SP is acting
>> as
>>> a proxy? Does the SP warrant the From value in that case? It  
>>> *could*,
>> to
>>> some extent, by rejecting any incoming calls from a PBX where the  
>>> From
>>> domain is not consistent with the authentication of the source  
>>> PBX. I
>>> guess that is out of scope of this document, and could be added  
>>> later
>> as
>>> a compatible upgrade. But is it consistent with the expectations of
>> the
>>> authors?
>>>
>>
>> Well, I guess the SP could verify that the domain in the 'From:'  
>> field
>> is valid for the originating enterprise but this would still not  
>> prevent
>> the enterprise from asserting an E.164 address in the user portion of
>> the URI that didn't belong to it (on the PSTN).
>
> Technically there is nothing wrong with this because the user part  
> of a
> URI is only interpreted within the scope of the domain name. So
>
> - sip:+19785551234 at atlanta.com;user=phone
> - sip:+19785551234 at biloxi.com;user=phone
>
> are both valid URIs belonging to their respective domains. However  
> only
> one of them is equivalent to:
>
> - tel:+19785551234
>
> and there is no way to tell which by inspection. This is why it is
> dangerous in general to take a sip uri and display only the numeric
> portion. Doing so assumes it is equivalent to the tel form.
>
> IMO the preferred approach is to only use the P-Asserted-ID header as
> the source for callerid info, and to use tel in that when a phone  
> number
> is to be displayed. Or at worst, use the number from a sip uri in P- 
> A-ID
> only when the the contractual arrangement says it is ok to do that.
>
>> I think this would also be the case even if the identity headers are
>> used. When identity is used, I believe that the responsibility for
>> inserting the 'Identity:' and 'Indentity-Info:' headers would be  
>> on the
>> originating enterprise's proxy server, not the SP's.
>
> It doesn't matter who inserts the identity header. It is the cert
> authority for the identity that matters.
>
> But yes, unless some special kind of cert is defined for this, you  
> could
> get an identity cert for both the atlanta.com and biloxy.com URIs with
> the same number in them. Jon Peterson has avoided having SIP Identity
> treat tel URIs, because it is hard. So we won't find a solution there.
>
> So if this is to be solved at all (in order to give *any* validity to
> sip callerid of phone numbers), then I think it must for now be a
> transitive trust solution, probably with the SP with the  
> responsibility
> for either preventing improper usage of numbers, or else refusing to
> assert identity for them.
>
>>> A related issue is if the UAS is only capable of displaying callerid
>> as
>>> a number, rather than as a URI. Is it expected to extract the number
>>> from the From URI whenenver that looks like a number, and/or has
>>> user=phone, *regardless* of the domain of the URI? In general you  
>>> are
>>> not supposed to "interpret" the user part unless it is your own
>> domain,
>>> even if it has user=phone. I think that can be stretched to allow
>>> interpreting the user part when one has specific knowledge of the
>>> conventions used by the domain, which could be assumed when it is  
>>> the
>> SP
>>> domain. But I don't think it can be stretched to allow  
>>> interpretation
>> of
>>> random other domains, unless part of SIPConnect is a requirement  
>>> that
>>> all players have this convention.
>>>
>>
>> Since this is just a profile of SIP, I don't think it is  
>> unreasonable to
>> say that all players must be using the conventions as defined. That
>> said, the PBX needs some way of determining when to apply the
>> rules/conventions associated with the profile. Perhaps we should add
>> some guidelines around checking the 'Via:' header to make sure the
>> request came from the SP's proxy vs. some other proxy (that doesn't
>> implement the profile.)
>
> The solution I prefer is to base it on P-Asserted-ID. The SP should  
> not
> assert an identity unless it can verify that it is valid.  
> Unfortunately,
> you guys have chosen to preempt P-A-ID for a different purpose.
>
> My alternative is for the SP to verify the From, and reject requests
> where it cannot be verified. However that has a serious downside - I
> think it means that all calls from the PSTN must be rejected if the
> caller's identity cannot be verified.
>
>>> I know there is currently no general concensus on exactly how  
>>> callerid
>>> should be handled. But I find it very suspect to ever trust using  
>>> From
>>> for this unless it is supported by SIP Identity. It would be  
>>> better if
>>>  From was always a TEL URI when it is a phone number, and the SP
>> refused
>>> requests when the From wasn't a phone number assigned to the source.
>> It
>>> would also be better if P-Asserted-ID was passed to the target PBX,
>> and
>>> was considered the only trustworthy source of caller identity.
>>>
>>
>> I'm not sure that using a tel: URI in the 'From:' field is a good  
>> idea
>> if we want to start using the identity headers in the future.
>
> Well, there is that.
>
> Better I guess to rely on P-Asserted-ID, which can be used in
> conjunction with SIP Identity. Using a TEL in a P-A-ID isn't a  
> problem.
> Using a sip with a clear understanding that the number in it will be
> valid is also not too much of a problem.
>
> 	Paul
>
>> <snip from RFC 4474>
>>
>> .
>> Implementations that intend to send their requests through an
>> authentication service SHOULD put telephone numbers in the From  
>> header
>> field into SIP or SIPS URIs whenever possible.
>> .
>>
>> </snip>
>>
>>> 	Paul
>>
>>
>> ********************************************************************* 
>> *
>> This email may contain confidential information. If you are not
>> the intended recipient, please advise by return email and delete
>> immediately without reading or forwarding to others.
>>  -- Cbeyond
>> ********************************************************************* 
>> *
>>
> _______________________________________________
> techwg mailing list
> Send mail to: techwg at sipforum.org
> Unsubscribe or edit options at:  http://sipforum.org/mailman/ 
> listinfo/techwg

----------
Jay Batson
Acting Managing Director, Chairman
batsonjay at sipforum.org
+1-978-824-0111