Subject: RE: [Sipping] Re: draft-sinnreich-sipdev-req-06.txt

From: "Christian Stredicke" <[email-masked]>
Date: Wed, 18 May 2005 08:08:16 +0200

More comments inline. Tried to make the indentation readable again...

>>>This continues to be an important draft. I haven't looked at
carefully
>>>for a few versions, but finally got to it. I have a few suggestions.
>>>
>>>	Thanks,
>>>	Paul
>>>
>>>>       Req-17: SIP telephony devices MAY support a local dial plan.
>>>>               If a dial plan is supported, it MUST consist of a
pattern 
>>>>               string to match dial digits, and the ability to strip
>>>>               and also append prefix digits, and also append suffix
>>>>               digits.  
>>>
>>>This is incomplete.  What about inserting phone-context and
user=phone
>>>or user=dialstring? What about choice of SIP or TEL?  Section 3.6
shows
>>>functionality that addresses these points, but it seems to be more of
an
>>>example than a requirement.
>> 
>> We only require a "MAY" because this is of course highly
>> implementation-dependant. This paragraph tries to explain that *if* a
>> local dial is supported, the least thing that should be available is
>> that pattern matching thing. That does not include other more
advanced
>> things, as the reader can see in the example.
>
>I understand that requiring a dial plan at all is optional, except for 
>the default dial plan that just maps the dial string into a URI.
>
>What I am getting at is that *if* there is a dial plan, and if not then

>for the "Default Digit Map", there is a MUST strength requirement to 
>generate a URI from it, and I think there should be a SHOULD strength 
>requirement to be configurable about the form of URI that is generated:
>- control of SIP or TEL (and SIPS?)
>- ability to configure insertion of phone-context and user=phone
>   or user=dialstring.
>
>The stuff in 3.6 would provide this capability, but the requirements 
>there are very weak. 3.6.3 has a SHOULD, but it doesn't mandate what
the 
>substitution requirements are.
>
>Just a requirement for a *single* configurable pattern that can:
>- insert an arbitrary scheme at the front,
>- parameters after the number and before the "@",
>- a domain name that might be different from the outbound proxy,
>- and parameters after the domain name
>
>Would be a huge improvement over a device that always just slapps
"sip:" 
>at the front and "@"+proxy-name at the back.
>

Okay. What about the following wording?

"Req-17: SIP telephony devices MAY support a local dial plan.  If a
dial plan is supported, it MUST be able to match the user input to
one of multiple pattern strings and transform the input to a URI,
including an arbitrary scheme and URI parameters."

>>>The outgoing proxy will presumably have requirements for how URIs 
>>>containing phone numbers are formed. There need to be enough 
>>>requirements so that the phone can be configured to work with the
>> proxy.
>> 
>> But I am afraid the discussion did not result in a consensus that
goes
>> that far. Some people think that it is the proxy's job to clean the
URI
>> up. Therefore we cannot mandate such a behavior in this document.
>
>Well, maybe I can't fight mother nature. But even if you expect the 
>proxy to fix it, you need to give the proxy enough data to work with.
>
>And there are things a proxy isn't supposed to fix. The poster child
for 
>this is a blind transfer where the transfer target is dialed by the 
>device initiating the transfer. This could result in something like:
>
>	REFER sip:[email-masked]
>	To: sip:[email-masked]
>	From: sip:[email-masked]
>	Refer-To: sip:[email-masked]
>	Route: sip:atlanta.com;lr
>	...
>
>If atlanta.com is a *proxy* it isn't supposed to mess with the Refer-To

>header. If it doesn't, then this will result in:
>
>	INVITE sip:[email-masked]
>	To: sip:[email-masked]
>	From: sip:[email-masked]
>	Route: sip:biloxi.com;lr
>	...
>
>At that point the fact that this call was dialed by alice has been lost

>from the message. Biloxy.com can't fix it, and atlanta.com can fix it 
>only if all users of atlanta.com have the same digit map.
>
>OTOH, if the original request had been:
>
>	REFER sip:[email-masked]
>	To: sip:[email-masked]
>	From: sip:[email-masked]
>	Refer-To: sip:4321;phone=context=plan12.atlanta.com
>		@atlanta.com;user=dialstring
>	Route: sip:atlanta.com;lr
>	...
>
>Then the request would get back to atlanta.com in a form that it would 
>know how to fix it.
>
>Otherwise, if you force atlanta.com to "fix" the Refer-To, you either 
>require it to be a non-conforming proxy, or else require it to be a 
>B2BUA/SBC. I don't think we want that.
>
>>>>       Req-18: SIP telephony devices MUST support the URIs for 
>>>>               Telephone numbers as per RFC 3966 [9].  
>>>
>>>What is meant by "support"? Which headers should TEL be accepted in,
and 
>>>which should it be capable of generating TEL in. In case of
generation, 
>>>how is use of TEL vs SIP specified?
>> 
>> We are just referring to RFC3966. That can't be a mistake.
>
>Referring to 3966 isn't a mistake. But 3966 says nothing about where it

>is used. *Maybe* this is sufficient to make it clear a device must not 
>fail if it receives a message with one of these any place 3261 says it 
>may be. But it is not a requirement that the device be able to generate

>TEL URIs in the messages it sends. Is ability to receive all you are 
>after? If so, than I withdraw my objection.

Req-17 states that the phone will generate anything that is
configured in the dial plan, including a URI according to RFC
3966.

Now Req-18 deals with the semantics of one specific URI type. It
is clear that a phone must be able to receive RFC 3966 URI. But it
must also be able to send a request with that URI set, what else
should it do when a user enters such a URI (possibly through the
dial plan)?

Lets say "Req-18: SIP telephony devices MUST support URIs for
Telephone numbers as per RFC 3966 [9]. This includes the
receiption as well as the sending of requests. It is a reasonable
behavior to send a request to a preconfigured outbound proxy."

>>>To answer myself, I think the device must be able to properly process

>>>incoming messages containing TEL URIs anywhere they are legal.
Whenever 
>>>a device is configured with a URI to be inserted in requests in
places
>>>where a TEL URI is permitted it should be able to be configured with
a
>>>TEL URI. And whenever a device transforms a phone number into a URI
for 
>>>insertion into a message it should be capable to being configured to 
>>>transform it into a TEL URI.
>>>
>>>There probably needs to be a special rule for the originating AoR. It
is 
>>>required to be a SIP URI in the REGISTER message, but it may be 
>>>preferable for it to be a TEL URI in From and P-Asserted-Identity
headers.
>>>
>>>> Req-19: SIP telephony devices MUST support REFER and NOTIFY as 
>>>>         required to support call transfer [45], [46]. SIP 
>>>>         telephony devices MUST support escaped headers in the
>>>>         Refer-To header.  
>>>
>>>Need to be clearer what is meant by "support escaped headers". RFC
3261 
>>>section 19.5.1 specifies what is to be done with header parameters. 
>>>Putting them into the message is SHOULD strength for some, SHOULD NOT

>>>for some others. But the ones that are SHOULD strength is not
precisely 
>>>specified. I think its important to specify which must also be placed

>>>into a message.
>> 
>> Of course we are talking about the bla?Replaces=123%3Abla.com stuff.
>
>Are you *only* concerned with the Replaces header? Probably there are 
>others that are important.

Well, I don't want to repeat the discussion of the algorithm
described in RFC 3261. Lets put it that way, I would leave the
treatment of Route, Max-Forwards etc. open.

>
>> If we put here a SHOULD in the context of a call transfer,
practically not
>> a single transfer will work properly. Therefore, we need a MUST here.
>
>My intent was to strengthen the requirement, not weaken it.
>As 3261 is worded, it appears to be up to the UA to decide if a 
>particular header is safe enough to honor, so it would be free to say 
>"yes, I support header parameters, but I just don't consider Replaces 
>safe, so I don't honor it."
>
>So I think you probably need to list the particular headers that must
be 
>honored so that important call flows work.

We don't want to open a beauty contest of what header could
possible be useful in this context.  I would say lets make the
Replaces a MUST and anything else according to RFC3261.

>>>>
>>>>    Req-26: SIP telephony devices MUST generate local ringing and
>>>>            SHOULD ignore any early RTP media when a "180 Ringing" 
>>>>            response is received. Any received media that is not 
>>>>            early media (i.e., not received within the context of an

>>>>            early session, as specified in [71] should be rendered 
>>>>            as soon as it arrives in order to avoid speech clipping.

>>>>            SIP telephony devices MUST play the RTP stream for the 
>>>>            established dialog and ignore any other RTP media 
>>>>            streams when a "183 Session Progress" response is 
>>>>            received.  
>>>>
>>>>    Req-27: SIP telephony devices SHOULD obey the last 18x message 
>>>>            received when multiple 18x responses are received. If
>>>>            the last response is "180 Ringing", the client MUST 
>>>>            generate local ringing. If the last response is "183 
>>>>            Session Progress", the client MUST play the RTP stream. 
>>> 
>>>This is contrary to recommendations in RFC 3960.  I think this should

>>>say that a SIP telephony device, when acting as a UAC, SHOULD support

>>>the gateway model of RFC 3960, and that when acting as a UAS it
SHOULD
>>>NOT send early media.
>> 
>> You are probably right that is it would be smart to refer to the work
on
>> early media.
>> 
>> I would suggest the wording "Req-26: When acting as a UAC, SIP
telephony
>> devices SHOULD support 
>> the gateway model of RFC 3960 [x]. When acting as a UAS, SIP
telephony
>> devices SHOULD NOT send early media.". Delete Req-27 (or replace it
with
>> the wording below).
>
>Sounds good to me.
>
>>>Somewhat related - seems like there should be another requirement
around 
>>>support for forking - that when a UAC sends a request that is forked,
it 
>>>MUST do the right thing - namely it must be able to handle the first 
>>>dialog that returns a 2xx even if there are other early dialogs, and 
>>>that it must deal with additional 2xx responses that may arrive - at 
>>>least sending a BYE with reason code to them.
>> 
>> I personally had a lot of discussions with different vendors. This
>> requirement is clearly included in RFC 3261 but almost nobody
implements
>> it. However the usual result is one-way audio if this requirement is
not
>> implemented.
>
>Right. When nobody pays attention, it is best to repeat and rephrase
the 
>requirement often until it is understood!
>
>> May I propose the following wording: "Req-27: SIP telephony devices
MUST
>> be able to handle multiple dialogs in the context of request forking.
>> When a dialog was already established, it is a reasonable behavior to
>> send a BYE request upon the arrival of additional 2xx responses."
Sorry
>> for my bad English, maybe someone finds more poetic words for the
>> multiple 2xx problem.
>
>No problem with your English. Its as good as mine. (And way better than

>my German.)
>
>>>>       Req-64: SIP telephony devices MUST support the option to
reject 
>>>>               an incoming INVITE where the user-portion of the SIP 
>>>>               request URI is blank or does not match a provisioned 
>>>>               contact. This provides protection against war-dialer 
>>>>               attacks, unwanted telemarketing and spam. The setting
to 
>>>>               accept/reject MUST be configurable. 
>>>
>>>This seems to *require* that a device be configurable to *accept* 
>>>requests where the R-URI doesn't match an expected contact address.
This 
>>>is overreaching - it should never be wrong to accept requests only to

>>>addresses that have been advertised.
>> 
>> If this is not configurable, some vendors argue that the device is
not
>> SIP compliant. I am personally on your side, but in our company we
>> already had trouble with stuff that was too dumb to generate request
URI
>> like this and we were blamed because we are not "SIP compliant".
>> Therefore have a flag to make the device "SIP compliant" again.
>
>Maybe I am not being clear. Suppose I have a device that creates and 
>registers two contacts:
>
>	sip:[email-masked]
>	sip:[email-masked]
>
>It expects to be receiving requests at those addresses, and no others.
>
>I interpret Req-64 as *requiring* that it be configurable to accept 
>requests addressed to sip:device123.atlanta.com. While I think it
should 
>be free to accept those if it wishes, I don't thing there should be a 
>requirement that it must.
>
>> Maybe we can resolve this problem by making the requirement a SHOULD.
>
>No, I don't think that is the solution. This is just a one-way 
>requirement. It must either be restrictive all the time, or at least 
>configurable to be restrictive. If it is restrictive by default then it

>need not be configurable to be lenient.
>
>But I do think the wording is too strict in one respect:
>
>     "... does not match a provisioned contact ..."
>                           ^^^^^^^^^^^
>
>This may exclude cases where the user part of the contact is assigned
at 
>runtime rather than being provisioned. For instance a UA that handles 
>conferencing locally may construct a contact for use as a focus. (But 
>maybe this is too obscure to worry about.)
>
> Req-64: A SIP telephony devices MUST support the option to reject
>         an incoming INVITE where the user-portion of the SIP
>         request URI is blank or does not match a value the device
>         has designated for the receipt if incoming requests.
>         This provides protection against war-dialer
>         attacks, unwanted telemarketing and spam. The requirement
>         to reject MUST be configurable. (The ability to accept
>         requests at undesignated addresses is NOT REQUIRED.)
>

Ok, lets put it that way. 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 May 2005 09:38:30 -0400

Christian,

I think I am almost finished here. I've trimmed the conversation a lot 
in hopes of making it readable and to focus on remaining points.

	Paul

Christian Stredicke wrote:

>> "sip:" at the front and "@"+proxy-name at the back.
> 

I think that is close. I'm struggling with whether or not to complicate 
it to cover all the issues. Perhaps this is close enough. I presume the 
next step is to use these requirements to drive a common schema for 
configuration. At that point these things can be dealt with in detail.

(The thing I am thinking the above may technically miss is that in a URI 
like <sip:4321;phone-context=[email-masked];user=phone>, "user=phone" 
is a URI parameter, but "phone-context=foo.com" is not.)

> behavior to send a request to a preconfigured outbound proxy."

OK. I think that is better.

>>>>Need to be clearer what is meant by "support escaped headers".

>>>>RFC 3261 section 19.5.1 specifies what is to be done with header
>>>>parameters. Putting them into the message is SHOULD strength for
>>>>some, SHOULD NOT for some others. But the ones that are SHOULD
>>>>strength is not precisely specified. I think its important to
>>>>specify which must also be placed into a message.
>>>
> described in RFC 3261.

Agree - the point is not to repeat that. I think the point is to go 
beyond that with additional requirements where that is necessary to 
achieve the desired functionality.

> Lets put it that way, I would leave the

Yes.

>> be honored so that important call flows work.
> 

It seems like there are two choices of approach here:
- open the beauty contest. List exactly those headers that
   are needed to make important call flows work.
   (The standard of beauty is determined by the call
   flows that are selected and the header parameters they
   require.)

- establish independent criteria for determining if headers
   are "safe". Then require devices to honor the safe ones.

The second approach might be better in the long run, but I don't think 
it is the place of a document like this to do that. The beauty contest 
approach at least has clear criteria, so is probably the pragmatic 
choice here. I haven't checked - is "Replaces" the only one that is 
needed to make the important call flows work? If so then your proposal 
seems right.

	Paul