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

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 May 2005 13:48:00 -0400

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.

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.

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

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.

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

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.

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

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

_______________________________________________
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