RE: SIP Identity and RFC 3893

My short answer is no, I don't think so. In part this is because there is a need for third-party
authentication for mechanisms like Referred-By (RFC3892), and it's not at all clear that sip-identity
could be adapted to those needs. Speaking more to S/MIME in general, although sip-identity provides an
integrity property for SIP message bodies, it doesn't provide a confidentiality property. There are a
few significant use cases today that still require confidentiality for SIP message bodies, notably some
of our media security schemes. Pending some of the work in play on the rtpsec list, of course, that
particular need could change over time. But I certainly wouldn't say that we're in a position to deprecate
S/MIME yet.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Francois Audet [mailto:audet <at> nortel.com]
> Sent: Wednesday, April 19, 2006 10:35 AM
> To: sip <at> ietf.org; Peterson, Jon
> Subject: SIP Identity and RFC 3893
> 
> 
> Jon,
> 
> Does sip-identity-06 make RFC 3893 (the AIB format for 
> S/MIME) obsolete?
> 
> Sip-identity is remarkably silent about RFC 3893. It sorts of hints in the 
> introduction that sip-identity is an alternative to S/MIME, but it is not
> very specific.
> 
> The changelog (which will be removed upon publication) sheds a bit of light

IETF Meeting Survey for IETF 65

Ray Pelletier (IETF administrative director) and team have put  
together a survey relating to the IETF 65 experience, and would  
appreciate additional input.

It takes about 5 min to complete (just did it myself).

http://www.surveymonkey.com/s.asp?u=649182049947

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

dialog state model for SUBSCRIBE / NOTIFY usages

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

I-D ACTION:draft-ietf-sip-gruu-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation
Protocol (SIP)
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-sip-gruu-07.txt
	Pages		: 36
	Date		: 2006-5-1
	
Several applications of the Session Initiation Protocol (SIP) require
a user agent (UA) to construct and distribute a URI that can be used
by anyone on the Internet to route a call to that specific UA
instance.  A URI that routes to a specific UA instance is called a
Globally Routable UA URI (GRUU).  This document describes an
extension to SIP for obtaining a GRUU from a server and for
communicating a GRUU to a peer within a dialog.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-07.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-gruu-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-gruu-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

Question regarding ptime attribute

Hi,

If SDP contains following media line data:

m=audio 49230 RTP/AVP 96 97 98
 a=rtpmap:96 L8/8000
 a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2
a=ptime: 30

Does it mean that it is using 30 ms packetization period for all the audio 
codecs, or only for codec with PT=98, rest all codecs use 20 ms.

-Udit

Minor comments on draft-ietf-sip-gruu-07.txt

- Section 10 Grammar does not mention the new "+sip.instance" parameter
  for the Contact header, but includes :
     instance-val   = *uric ; defined in RFC 2396 (should be RFC 3986)

- The SUBSCRIBE message on page 27 and page 28 :
  o The URI in the To header field must be enclosed in "<" and ">". As
    it is now, the "opaque" and "grid" become To header parameters.
  o Allow: INVITE, OPTIONS, CANCEL, BYE, ACK should also include 
    SUBSCRIBE and NOTIFY

- Page 5  :   ">From" should be "From"

- Page 12 :   "reuqest" should be "request"

- Section 7.1.1.1 :  "..., it MUST use [14]" => "..., it MUST follow the
procedures defined in [14]".

- Section 8.2.1 "(allowing mutiple flows.." has no closing bracket.

- Section 8.2.3 "(which happens when the client.." has no closing
bracket.

- The last sentence on page 21 makes no sense. "This information may be
present from the hint if the topmost Route header field URI, if the
proxy used that technique".

- Request-URI has been written as "Request URI", "request URI" (eg.
8.1.3 "the incoming request URI") as well as "Request-URI" throughout
the document.

- And we have "AOR" and "AoR"

- Section 14 should register "Predefined Values : None" for all the new
parameters.

Regards,
Ya-Ching

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

RE: I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt

Hi,

I do not really have a strong opinion on this but
can anyone point out the reason of having RFC 3263 as
a separate document and not integrated to RFC 3261 ?

Both were created at the same time and RFC 3261 relies
on 3263 but they still remained as separate. Understanding
the reasons for that better would enable us to check if
they also apply to this.

Logically I would think that having two separate specs
would be clearer in a way that Outbound would update RFC 3261
while Outbound-discovery would update RFC 3263 instead of
bundling all that together into one single atomic document.

But like mentioned, if there are good reasons for integrating
those documents then why not (at least after reaching stable
enough consensus about the mechanisms used for discovery).

Regards,

Erkki 

>-----Original Message-----
>From: ext Francois Audet [mailto:audet <at> nortel.com] 
>Sent: 28.April.2006 19:13
>To: Juha Heinanen; Dean Willis
>Cc: SIP WG
>Subject: RE: [Sip] I-D 
>ACTION:draft-koivusalo-sip-outbound-discovery-00.txt 
>
>If we are happy with it, and it is normative, then why don't 
>we just integrate this draft into sip-outbound? I see no
>advantage to have it a separate draft.
>
>> -----Original Message-----
>> From: Juha Heinanen [mailto:jh <at> tutpro.com] 
>> Sent: Friday, April 28, 2006 08:59
>> To: Dean Willis
>> Cc: SIP WG
>> Subject: Re: [Sip] I-D 
>> ACTION:draft-koivusalo-sip-outbound-discovery-00.txt 
>> 
>> 
>> Dean Willis writes:
>> 
>>  > 1) Are we basically happy with this approach?
>> 
>> at least i'm happy.
>>  > 
>>  > 2) Do we need to include a reference to this in Outbound? 
>> If so, is  
>>  > an informative reference adequate?
>> 
>> no, the reference MUST be at the same level as rfc3261 
>> references rfc3263.  there is no difference.
>> 
>> -- juha
>> 
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors <at> cs.columbia.edu for questions on current 
>> sip Use sipping <at> ietf.org for new developments on the 
>> application of sip
>> 
>> 
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors <at> cs.columbia.edu for questions on current sip
>Use sipping <at> ietf.org for new developments on the application of sip
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

ptime attribute in Offer SDP

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

RE: ptime attribute in Offer SDP

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

RE: I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt

Hi,

I am happy to see some discussion raised by my I-D, since 
one aim for publishing the I-D was to get more focused
comments on the autodiscovery topic.

>why did you choose to use the SRV priority in that way? 
>You said "choose one of each priority level".

The reason for my choice was how draft-ietf-sip-outbound-03 
is currently written (and the focus of my thoughts when writing
the I-D).

The chapter 3.3 Multiple Connections from a User Agent starts
the discussion with introducing the primary and backup proxies
using the following statements:

   The UA is configured with a primary and backup registration URI.

   The deployment here requires
   that DNS is configured with one entry that resolves to all the
   primary hosts and another entry that resolves to all the backup
   hosts.

I was focusing my thinking about how to avoid the requirements
of having different primary and backup URIs i.e:

a) To configure the UA with two URIs (instead of a single one
   that could be got from DHCP or derived from the AOR of the user)

b) To configure the DNS for primary and backup proxies so that 
   two "domains" would have to be used for each

Actually RFC 2782 (SRV RR) also discusses primary and backup services:

   The SRV RR allows administrators to use several servers for a single
   domain, to move services from host to host with little fuss, and to
   designate some hosts as primary servers for a service and others as
   backups.

I just found it convenient to make a mapping between the concepts 
used in these two specs in the way I did. So instead of the need to 
separately configure "backup registration URI" to the UA, the SRV 
records with higher numbers could be used as backup servers for 
SIP Outbound.

On the other hand my I-D is not explicit what comes to the scalability 
and load balancing. My intention was to leave it as the responsibility
of usual SRV RR processing as discussed within
draft-ietf-sip-outbound-03.

   Note that each URI
   in the outbound-proxy-set could resolve to several different physical
   hosts. The administrative domain that created these URIs should
   ensure that the two URIs resolve to separate hosts.  These URIs are
   handled according to normal SIP processing rules, so things like SRV
   can be used to do load balancing across a proxy farm.

   Scalability
   is achieved by using DNS SRV to load balance the primary connection
   across a set of machines that can service the primary connection and
   also using DNS SRV to load balance across a separate set of machines
   that can service the backup connection. 

The approach for load balancing specified in RFC 2782 (SRV RR) is as
follows:

   Priority
        The priority of this target host.  A client MUST attempt to
        contact the target host with the lowest-numbered priority it can
        reach; target hosts with the same priority SHOULD be tried in an
        order defined by the weight field. 

   Weight
        A server selection mechanism.  The weight field specifies a
        relative weight for entries with the same priority. Larger
        weights SHOULD be given a proportionately higher probability of
        being selected.

In other words load balancing is achieved between multiple UAs, each
of them randomly selecting one proxy amongst the ones defined within
the highest priority SRV RR. One UA would ever use only one single
primary
proxy but if there are N primary proxies, then any of those would only
serve 1/N of the whole UA population. My I-D was not supposed to change
any of that, so it was not explicitely specified either. No load
balancing
between the primary and backup connection was planned for the UA,
instead
the load balancing is only done when selecting which primary and backup
proxy to use:

               While there are still elements left at this priority
               level

                   Select an element as specified above, in the
                   description of Weight in "The format of the SRV
                   RR" Section, and move it to the tail of the new
                   list

And now the real problem (which is actually an issue within
draft-ietf-sip-outbound-03) is: if a single UA still needs
a backup proxy (and a backup connection), shall those backup
proxies be one of those the other UAs are using as their 
primaries or should those backup proxies be totally separate
from the primary proxy farm ? Currently draft-ietf-sip-outbound-03
seems to suggest having separate set of primary proxies and another
set of backup proxies:

   The deployment here requires
   that DNS is configured with one entry that resolves to all the
   primary hosts and another entry that resolves to all the backup
   hosts.  Designs having only one set were also considered, but in this
   case there would have to be some way to ensure that the two
   connection did not accidentally resolve to the same host. 

If the agreement will be that no dedicated backup proxies should be
used for SIP Outbound but instead one common set of proxies should be
used both for load balancing and backup purposes then I would
suggest:

- Rewriting draft-ietf-sip-outbound-03 accordingly

- Revising draft-koivusalo-sip-outbound-discovery-00 so that:

  * UA would use two proxies within the same SRV RR Priority
    level as primary and backup

  * Load balancing would still be done between the UAs (each
    of them selecting their primary proxy with SRV RR Weight
    and using the primary proxy whenever it responds) instead
    of requiring a single UA to distribute its traffic 
    proportionately to weight (which would complicate the UA
    implementation quite a lot).

Comments ?

Regards,

Erkki 

>-----Original Message-----
>From: ext Hadriel Kaplan [mailto:HKaplan <at> acmepacket.com] 
>Sent: 28.April.2006 19:38
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); sip <at> ietf.org
>Subject: RE: [Sip] I-D 
>ACTION:draft-koivusalo-sip-outbound-discovery-00.txt 
>
>Hi Erkki,
>I am confused by one thing (well, for this topic): why did you 
>choose to use
>the SRV priority in that way? You said "choose one of each 
>priority level".
>If I understand the outbound draft correctly, there is no real 
>distinction
>between primary and backups - any one of them can get new 
>requests at any
>time, and the UA registers to all.  So they're really all 
>primaries once the
>UA chooses to create a flow to them.  Thus I would think it 
>more logical to
>have a UA which supports outbound connect to all servers of 
>the same and
>lowest SRV priority if the server supported outbound, and only 
>connect to
>higher ones upon failure of lower ones.
>
>That way a higher priority really means "connect if lower one 
>fails", as it
>did for SRV before outbound.  No?
>
>-hadriel
>
>
>> -----Original Message-----
>> From: Erkki.Koivusalo <at> nokia.com [mailto:Erkki.Koivusalo <at> nokia.com]
>> Sent: Friday, April 21, 2006 7:34 AM
>> To: sip <at> ietf.org
>> Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-
>> 00.txt
>> 
>> Hi,
>> 
>> >I made up two proposals based on DNS for the UA to find
>> >out proxies supporting outbound within the domain of SIP
>> >AOR of the user or the domain got from DHCP ...
>> >
>> >I am now planning to put together an I-D for those proposals
>> >as an update to RFC 3263. It may take some time, but hopefully
>> >not too long.
>> 
>> The promised I-D is now available:
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> 
>> 
>> 	Title		: Discovering Proxies Supporting SIP Outbound
>> 	Author(s)	: E. Koivusalo
>> 	Filename	: draft-koivusalo-sip-outbound-discovery-00.txt
>> 	Pages		: 17
>> 	Date		: 2006-4-20
>> 
>>    This document describes modifications to DNS procedures used to
>>    resolve a SIP Uniform Resource Identifier (URI) into the 
>IP address,
>>    port, and transport protocol of the next hop to contact.  These
>>    modifications enable the SIP User Agent to discover those proxies,
>>    within the domain of the SIP URI, that support SIP extensions
>>    described in draft-ietf-sip-outbound document.  The introduced
>>    mechanisms update behavior defined in RFC 3263.
>> 
>> 
>> A URL for this Internet-Draft is:
>> 
>http://www.ietf.org/internet-drafts/draft-koivusalo-sip-outboun
>d-discove
>> ry-00.txt
>> 
>> I would appreciate for anyone interested to review this spec
>> and provide me with comments.
>> 
>> Regards,
>> 
>> Erkki
>> 
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors <at> cs.columbia.edu for questions on current sip
>> Use sipping <at> ietf.org for new developments on the application of sip
>
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip