Subject: [Sipping] RE: draft on SIP architectural principles

From: "Steve Langstaff" <[email-masked]>
Date: Wed, 2 Mar 2005 14:16:05 -0000

Does this indicate some bias against forking? :)

http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-sip-arch-00.txt

2.4  Client Multiplicity
[snip]
   "Similarly, users can receive calls that
   "ring" each device at the same time or in sequence.  Forking, which
   allows multiple devices to be wrong at once, is a key part of the
   baseline SIP specification."

_______________________________________________
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: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 2 Mar 2005 15:56:26 -0500

So end to middle encryption is out of favor?

Mike 

>-----Original Message-----
>From: Brian Rosen [mailto:[email-masked]] 
>Sent: Wednesday, March 02, 2005 3:53 PM
>To: Michael Hammer (mhammer); Jonathan Rosenberg (jdrosen); 'sipping'
>Subject: RE: [Sipping] draft on SIP architectural principles
>
>I'm sorry, but we HAVE to allow encryption of the body end to 
>end, and that includes SIP-T.  It's pretty unusual to have a 
>proxy server route on the ISUP body, and it just doesn't work 
>if the proxy can't decrypt it.
>
>Brian
>
>> -----Original Message-----
>> From: Michael Hammer (mhammer) [mailto:[email-masked]]
>> Sent: Wednesday, March 02, 2005 3:28 PM
>> To: Brian Rosen; Jonathan Rosenberg (jdrosen); sipping
>> Subject: RE: [Sipping] draft on SIP architectural principles
>> 
>> Brian,
>> 
>> Limiting to headers would be too restrictive.
>> Use the SIP-T ISUP-based MIME body as a case in point.
>> 
>> Mike
>> 
>> >-----Original Message-----
>> >From: [email-masked]
>> >[mailto:[email-masked]] On Behalf Of Brian Rosen
>> >Sent: Wednesday, March 02, 2005 10:26 AM
>> >To: Jonathan Rosenberg (jdrosen); 'sipping'
>> >Subject: RE: [Sipping] draft on SIP architectural principles
>> >
>> >I like this draft.
>> >
>> >The only technical issue I thought of when reading is in:
>> >   That said, the specifications do not prohibit proxies 
>from invoking
>> >   special routing logic based on method or other information in the
>> >   message.  Such behaviors are typical of distributed 
>proxy networks
>> >   where the overall processing of a SIP user agent is distributed
>> >   across multiple components, and a proxy is used to route 
>messages to
>> >   the appropriate component.
>> >
>> >The problem is with the phrase "other information in the message".
>> >If you had said "other information in the headers" I would have no 
>> >problem.  By saying "in the message", you sanction 
>examining the SDP, 
>> >and thus run afoul of SMIME encryption.
>> >
>> >I noticed a few nits other than "wrong at once"
>> >Section 3.2 "use a button the remote to indicate" missing an "on"
>> >Section 3.4 "Of course, if the endpoints fail, the call is 
>over even 
>> >in any case" probably doesn't need the word "even"
>> >Section 3.8 "SIP has not tried to parsimonious in its" 
>missing a "be"
>> >Section 4.3 "Genreally speaking" oh really?
>> >Section 4.9 "including non-SIP URI like the" probably "URIs"
>> >
>> >Brian
>> >> -----Original Message-----
>> >> From: [email-masked] 
>[mailto:[email-masked]] On 
>> >> Behalf Of Jonathan Rosenberg
>> >> Sent: Wednesday, March 02, 2005 3:06 AM
>> >> To: sipping
>> >> Subject: [Sipping] draft on SIP architectural principles
>> >>
>> >> Folks,
>> >>
>> >> I wanted to call your attention to the following I-D:
>> >> 
>http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-sip-arc
>> >> h-
>> >> 00.txt
>> >>
>> >> This is an attempt to summarize some of the key architectural and 
>> >> design principles that underly SIP. Henning and I would welcome 
>> >> comments and suggestions for additional principles.
>> >>
>> >> Thanks,
>> >> Jonathan R.
>> >> --
>> >> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>> >> Director, Service Provider VoIP Architecture   Parsippany,
>> >NJ 07054-2711
>> >> Cisco Systems
>> >> [email-masked]                              FAX:   
>(973) 952-5050
>> >> http://www.jdrosen.net                         PHONE: 
>(973) 952-5000
>> >> http://www.cisco.com
>> >>
>> >> 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
>> >>
>> >
>> >
>> >
>> >
>> >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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Mar 2005 23:24:53 -0500

Brian Rosen wrote:

> I observe that my own work violates this :(
> If you need to route on location, and location is carried in a body, you
> better not SMIME encrypt the location.

Heh, well 911 appears to be the exception to nearly every rule...

> 
> In this case, the sender knows he wants to route the call based on location.
> 
> You probably could make the same argument for other things.
> The general case is still true; assume SMIME of bodies.

I think its fair to say that in SIP's original design, only the r-uri 
was really used for forwarding logic. That has clearly changed over 
time, and now includes bodies sometimes too, as in the 911 case (I don't 
see why proxies need to look at bodies for SIP-T routing, though). As 
such, sadly, there isn't really a common principle there anymore, 
excepting that the r-uri is really the primary source of routing logic, 
but not always.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com