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

From: "Christian Stredicke" <[email-masked]>
Date: Tue, 17 May 2005 23:43:26 +0200

Comments inline.

CS

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Tuesday, May 17, 2005 8:01 PM
> To: [email-masked]
> Subject: [Sipping] Re: draft-sinnreich-sipdev-req-06.txt
> 
> 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.

> 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.

> 
> >        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.

> 
> 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. 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.

> 
> >        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).

> 
> 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.

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.

> 
> >        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 we can resolve this problem by making the requirement a SHOULD.

> 
> >      4.3. Privacy 
> > 
> >         Media Encryption 
> >                Secure RTP (SRTP) [41] MAY be used for the encryption
of 
> >                media such as audio, text and video, after the keying

> >                information has been passed by SIP signaling. 
> >                Instant messaging MAY be protected end-to-end using 
> >                S/MIME. 
> 
> Before this functionality will be useful in a general way it will be 
> necessary to say something about how this is to be negotiated, and any

> modality controls in the UI. But it may be premature to nail this down

> because the drafts for how to do it are still somewhat immature.
> 

Absolutely. 

> 
> _______________________________________________
> 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
> 
> 
> 

_______________________________________________
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: Tue, 17 May 2005 19:46:48 -0400

Christian,

Further comments inline.
Sorry, but this is getting hard to read due to folding of quoted text.

	Paul

> 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.

> 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.

> 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.

> 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.

> 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.

> devices SHOULD NOT send early media.". Delete Req-27 (or replace it with

Sounds good to me.

> it. However the usual result is one-way audio if this requirement is not

Right. When nobody pays attention, it is best to repeat and rephrase the 
requirement often until it is understood!

> for my bad English, maybe someone finds more poetic words for the

No problem with your English. Its as good as mine. (And way better than 
my German.)

> 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.)

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 18 May 2005 10:28:54 -0400

> From: Paul Kyzivat

I have no particular opinion about this possible requirement in general, but
I think that there is a special case that needs to be handled -- the
Contact: addresses that the device reports need to be ones at which it will
accept SIP messages.

For a number of "end-point call control" scenarios, devices generate INVITEs
and REFERs to the URIs in Contact: headers (or as reported in the "target"
elements of dialog event packages).  As far as I know, there is currently no
requirement that these URIs actually accept SIP messages outside of existing
dialogs.  And if the device does not, many call control scenarios cannot be
implemented.

So while I am agnostic as to what users a device must accept in URIs, I
think that there should be a MUST requirement that any URI a device
generates as a Contact:, it must accept requests to.

Dale