Subject: [Sip] Some comments on draft-ietf-sip-dtls-srtp-framework-02

From: "Schneider, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 7 Aug 2008 00:40:38 +0200

1) The draft currently states in section 5:

"     The endpoint MUST use the setup attribute defined in [RFC4145].
      The endpoint which is the offerer MUST use the setup attribute
      value of setup:actpass and be prepared to receive a client_hello
      before it receives the answer.  The answerer SHOULD use the setup
      attribute value of setup:active and will send the client_hello in
      the media path."

My proposal is to replace the last sentence by "The answerer MUST use
the setup
attribute value of setup:active or the setup attribute value of
setup:passive."

With this, if the receiver takes up the active role, as recommended in
the original text, he can start the handshake and if the handshake has
been carried out successfully before the SDP answer, he can send
encrypted early media (before the SDP answer). Obviously, with the usage
of self signed certificates, the offerer can authenticate the origin of
the early media only retrospectively, after he has received the SDP
answer, which somewhat reduces the value of encrypting the early media.
Early media as well as a handshake at that point in time will however
not work in an environment, where middleboxes are present that will not
let traffic pass in the media plane before the answer has been sent.

So if the receiver assumes such an environment, he may decide to take up
the passive role. By this, the offerer will start the handshake as soon
as he receives an answer, which would typically be close to the first
point in time at which the handshake messages will be able to pass the
middleboxes.

I feel it's quite reasonable to do the handshake after offer and answer
have been exchanged, because the offerer can check the fingerprint of
the certificate received in the handshake immediately; and he will not
accept encrypted media that may be sent by an attacker. So he is less
vulnerable to DoS. This does not allow encrypted early media to be
received, but is this so essential? In fact, accepting only encrypted
early media could be harmful, as it would prevent a caller to receive
e.g. an announcement that is sent by some server in the network that
only sends unsensitive announcements and therefore does not support
encryption at all.

2) With respect to unmanaged (e.g. residential) stateful firewalls the
draft currently states in section 6.6 that if ICE is not used and the
handshake could not be completed (until offer and answer have been
exchanged)

  "the passive side MUST
   do a single unauthenticated STUN [I-D.ietf-behave-rfc3489bis]
   connectivity check in order to open up the appropriate pinhole.  All
   implementations MUST be prepared to answer this request during the
   handshake period even if they do not otherwise do ICE."

And later, in the message flow on page 13 and the respective
explanations it becomes obvious that the idea is that the sender of this
STUN connectivity check in fact waits for an answer before he proceeds
(although implementations must only *be prepared* to answer a
connectivity request - I wonder whether "be prepared" should rather be
removed from this sentence). However, if there are middleboxes on the
path that block the STUN connectivity check, an answer will never come,
although the purpose of the connectivity check - to establish a session
in the residential firewall and open it up for incoming traffic - may
already have been achieved.

So instead of making the sending of the STUN connectivity check
mandatory in this situation, I propose rather to recommend that the
passive UA in the connection setup should try to make sure that a
firewall protecting the UA does not block the client hello starting the
handshake. This could be done by STUN or other means. This is exactly
what is recommended also in draft-ietf-mmusic-media-path-middleboxes-01,
section 7, REC #1.

3) More generally, I propose that the draft should mention possible
problems with middleboxes, and should advise implementors to follow the
recommendations in draft-ietf-mmusic-media-path-middleboxes.

4) Concerning the possible sequence of messages used to establish
sessions that use DTLS-SRTP, the draft IMO should give clearer
recommendations. This is currently mostly treated in the section
"example message flow", which indeed explains two flows currently. It is
unclear, to which degree this is normative, and what variants of such
flows would also be considered compliant to the draft.

5) Another topic where information is only given in the example flows is
the treatment of RTCP. If RTP/RTCP multiplexing on a single port is not
used, at which time should the handshake for RTCP be done - immediately
after the handshake for RTP, so that sender reports could be sent for
early media? Or only after the SDP answer, when both sides know which
ports are used on both sides? This becomes even more complex, if
non-symmetric RTP/RTCP would be applied, which is not excluded in
draft-ietf-avt-dtls-srtp-02.
I propose to describe these issues in a dedicated section.

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

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 Aug 2008 12:22:32 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Schneider, Peter (NSN - DE/Munich)
> Sent: Wednesday, August 06, 2008 3:41 PM
> To: Tschofenig, Hannes (NSN - FI/Espoo); 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [Sip] Some comments on draft-ietf-sip-dtls-srtp-framework-02
> 

But this will cause an SRTP-enabled call to suffer user-noticable
call setup delay (due to DTLS-SRTP handshake that needs to occur).
This is the R-CLIPPING requirement from 
draft-ietf-sip-media-security-requirements.

To avoid this clipping, we would need draft-ietf-sip-dtls-srtp-framework 
to require the SDP answer be sent reliably before 200 Okay -- perhaps
using a technique similar to what ICE does to send SDP reliably
in 18x messages.  For DTLS-SRTP, this would mean re-transmitting
the 18x with the SDP answer until a DTLS Client Hello is seen.  Would
that be acceptable?

> received, but is this so essential?

There are some apparently-legitimate uses of early media, at least
from the perspective of some network operators, to deliver things
like "Than you for using <operator>", advertisements, colorful ringback
(music as ringback), and so on.  Brian did a great write-up of many
scenarios in the (now expired) 
draft-stucker-sipping-early-media-coping-03.txt.

I expect that SRTP offers will, for a looong time (perhaps forever),
need to offer both RTP and SRTP (using 
draft-ietf-mmusic-sdp-capability-negotiation).  Endpoints will have 
to figure out what they want to do with RTP that arrives before the
answer.  If attackers start taking advantage of this, endpoints will
necessarily evolve to be more restrictive (only accept incoming
RTP if the UDP port matches the SDP answer [thus requiring 
symmetric RTP], only accepting incoming SRTP if the the fingerprint
matches, etc.); in order to reduce user-noticable call setup 
delay, this will also require reliably delivery of SDP answers 
before the 200 Ok.  I view much of this as evolution.

> In fact, accepting only encrypted

I suppose.  Depends on if the worry is being attacked with spam or
the worry is listening to RTP that 'the network' is attempting to 
deliver to the endpoint.

> STUN connectivity check in fact waits for an answer before he proceeds

There is no choice:  until the SDP answer arrives, the endpoint doesn't know
the IP address or port to send a STUN connectivity check.

> already have been achieved.

Could you draw a diagram of such a network, and the location of such
a middlebox?

> what is recommended also in 
> draft-ietf-mmusic-media-path-middleboxes-01,
> section 7, REC #1.
> 
> early media?

RTP early media (which isn't not SRTP), RTCP would be sent to whatever
draft-ietf-mmusic-sdp-capability-negotiation said.

> Or only after the SDP answer, when both sides know which

I agree that draft-ietf-avt-dtls-srtp and/or
draft-ietf-sip-dtls-srtp-framework do need to mandate symmetric RTP and
symmetric RTCP.

-d

---

From: Dean Willis <[email-masked]>
Date: Wed, 20 Aug 2008 17:40:10 -0500

On Aug 20, 2008, at 2:22 PM, Dan Wing wrote:
>
> There are some apparently-legitimate uses of early media,

No there aren't, IMHO.

> at least

Well, if you caveat it that way., then your statement is correct. One  
might reasonably ask if those operators don't simply have their  
requirements confused.

My take, however, is that "early media" is a cop-out for coping with a  
fundamentally broken PSTN-interworking model, coupled with Bad Ideas  
about charging based on signaling rather than content.

But like forking, this genie has left the bottle, and we have to deal  
with the consequences of that failing as long as we have SIP 2.0.

---
Dean

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 21 Aug 2008 10:16:44 -0500

I have changed the Subject title

Early media should just be an endpoint application when the SIP endpoint is
a PSTN gateway. This seems logical, or does it?

===================

I agree that early media has no role in pure/clean IP-IP communications, but
only when connecting to the PSTN. Should early media support not be
localized in the respective SIP endpoints, that is in the SIP-PSTN gateway?

Support of early media in the SIP-PSTN gateway would resolve this issue.

What do you think?

Henry

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Thu, 21 Aug 2008 15:37:06 +0000

What if you want to implement those or similar services between VoIP end
systems?  For example what if you want to provide "color ringback tones"
between VoIP end systems?  There is no PSTN gateway involvement in such
services. 

tim

> Behalf Of Henry Sinnreich
> Sent: Thursday, August 21, 2008 10:17 AM
> To: Dean Willis; Dan Wing
> Cc: [email-masked]; [email-masked]
> Subject: [Sip] Early media as an endpoint application
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 21 Aug 2008 09:17:12 -0700

> From: Dwight, Timothy M (Tim) 
> [mailto:[email-masked]] 
> Sent: Thursday, August 21, 2008 8:37 AM
> To: Henry Sinnreich; Dean Willis; Dan Wing
> Subject: RE: [Sip] Early media as an endpoint application
> 
> between VoIP end systems?  There is no PSTN gateway 
> involvement in such services. 

There are friendlier ways of implementing color ringback tones than described
in Brian's document.  Brian's document only describes the current state of the
art.

It would be friendlier, more secure, and allow conveying RTP payload types, to
only play media after you have received SDP describing that media.  For
example, playing color ringback tone could first require sending the caller a
18x with the SDP of the stream generating the color ringback tone (IP address,
UDP port, codec, packetization interval, etc.), and then stream the music to
the caller.  When the called party generates its 18x and SDP, that would also
sent to the calling party (who continues playing back the color ringback
tone).  Sending the called party's SDP allows the calling party to prepare to
receive that RTP, such as kicking off DTLS-SRTP (if being used), invoking a
transcoder, etc. -- all the while the color ringback tone is being played.
When the called party answers, the 200 causes the calling party to prefer that
incoming (S)RTP over the color ringback and the color ringback music can be
stopped.

-d

---

From: "Schneider, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 21 Aug 2008 18:42:58 +0200

> -----Ursprüngliche Nachricht-----
> Von: ext Dan Wing [mailto:[email-masked]] 
> Gesendet: Mittwoch, 20. August 2008 21:23
> An: Schneider, Peter (NSN - DE/Munich); Tschofenig, Hannes 
> (NSN - FI/Espoo); [email-masked]; [email-masked]
> Cc: [email-masked]
> Betreff: RE: [Sip] Some comments on 
> draft-ietf-sip-dtls-srtp-framework-02
> 

The receiver chooses "passive" because he lives in an environment where a managed middlebox blocks the path before the SDP answer is transmitted (as described in draft-ietf-mmusic-media-path-middleboxes-01). Clipping will happen not because of the passive role, but because of the middlebox.

> the 18x with the SDP answer until a DTLS Client Hello is seen.  Would

Sending the SDP answer in the first provisional response is a good idea and helps in the middlebox scenario. But this is not an alternative to allowing the receiver of the offer to take the passive role, but an addition. The receiver of the offer must have the passive role if he re-transmits "the 18x with the SDP answer until a DTLS Client Hello is seen", right? 

...
> the IP address or port to send a STUN connectivity check.

The connectivity check is not sent by the SDP offerer in the draft, but by the answerer - but this is not relevant for my point, I think.

> Could you draw a diagram of such a network, and the location of such

Sorry, I have no diagram at hand. Let me explain better what I had in mind: The draft assumes some unmanaged NAT or firewall in this scenario, e.g. a residential one, close to the UA. IN ADDITION, there still can be the (managed) middleboxes described in draft-ietf-mmusic-media-path-middleboxes-01. Its them who may discard a STUN connectivity check and by this make the handshake as described currently stall.
 
...

Peter

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Thu, 21 Aug 2008 14:09:16 -0400

I would prefer the phrase "media before Answer". In SIP, translates to
media before 200 OK. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henry Sinnreich
Sent: Thursday, August 21, 2008 11:17 AM
To: Dean Willis; Dan Wing
Cc: [email-masked]; [email-masked]
Subject: [Sip] Early media as an endpoint application

Early media should just be an endpoint application when the SIP endpoint
is
a PSTN gateway. This seems logical, or does it?

===================

I agree that early media has no role in pure/clean IP-IP communications,
but
only when connecting to the PSTN. Should early media support not be
localized in the respective SIP endpoints, that is in the SIP-PSTN
gateway?

What do you think?

Henry

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 21 Aug 2008 13:41:22 -0500

> I would prefer the phrase "media before Answer". In SIP, translates to

Yes, "Media Before Answer" would be a more accurate description.
It would also help to make the distinction with existing Early Media
definitions and/or interpretations.

Henry

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 21 Aug 2008 09:03:23 -0500

What do you think?

Henry

---

From: Dean Willis <[email-masked]>
Date: Thu, 21 Aug 2008 14:54:03 -0500

> between VoIP end systems?  There is no PSTN gateway involvement in  

The problem with early media is that it assumes that there is a need  
to transfer media BEFORE a session is "established". We inherit this  
assumption from the PSTN, because the PSTN billing model allows one- 
way media to flow from destination to origin before the call is  
"established". It works only because the stateful-everything prevents  
multiple early media sessions. With SIP, and forking, we get chaos.

So the "right answer" is to have two separate but fully negotiated SIP  
sessions -- one for the early media, one for the regular media.  The  
second session, should it occur, replaces the first (and we have a  
signaling mechanism to do just that). This eliminates the whole (or at  
least most of)  "early media" problem. But it confuses the heck out of  
bellheads who have decided to start billing based on the 200 OK, but  
also want to slavishly imitate the billing sequence of PSTN. It's  
stupid, broken, and can be manipulated to get vast amounts of "free  
long distance" out of the system, but it is deeply entrenched.

More on this: In the model I'm describing, a PSTN gateway handling a  
call from SIP to PSTN would send an initial 200/sendonly on receipt of  
the ACM (or equivalent). This would give us a SIP session for the  
"early media" phase. Then the gateway could either reinvite or refer/ 
replaces on the ANS.

The problem with this is that, if you're billing on the INVITE/200  
transaction, a naive system starts billing on the first INVITE/200  
(the early media).  So one needs a smarter billing system that 1)  
knows that the call is to a gateway, so it should start billing when  
the gateway initiates the bidirectional session, and 2) knows to bill  
the user, rather than the gateway.  This could be helped by a SIP  
exetension of some sort that identifies the early 200 OK as "early"

Now this isn't perfect, as if one forks a call, and one fork goes to a  
PSTN gateway, that's the fork you're going to get connected to every  
time, as it sends back the quickest 200 OK. But hey, if that's where  
you're getting media from, that's where you should be listening,  
right? Forking is broken. If it hurts, don't do it. Forking to a PSTN  
gateway really requires a B2BUA that understands the "early media  
session" model proposed above, and is smart enough to drop the early- 
media session if it gets a non-early 200 OK from another leg.

On a pure VoIP system, localized ringback is probably better handled  
with extensions to "alert-info".

--
Dean

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 21 Aug 2008 16:21:17 -0500

Dean,

How would the proposed "Media Before Answer" endpoint/gateway application
affect the billing in your opinion? Would it change anything with the issues
here below? 

(The SIP servers in the network do not need to understand "Media Before
Answer", they just do the rendezvous job)

Henry

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 21 Aug 2008 15:09:03 -0700

> The receiver chooses "passive" because he lives in an 
> environment where a managed middlebox blocks the path before 
> the SDP answer is transmitted (as described in 
> draft-ietf-mmusic-media-path-middleboxes-01). Clipping will 
> happen not because of the passive role, but because of the middlebox.

Yes, the clipping is caused by the middlebox.  However, due to
the DTLS-SRTP handshake (2 round trips) the clipping for a 
DTLS-SRTP session will be more user noticable.

> Sending the SDP answer in the first provisional response is a 
> good idea and helps in the middlebox scenario. But this is 
> not an alternative to allowing the receiver of the offer to 
> take the passive role, but an addition. The receiver of the 
> offer must have the passive role if he re-transmits "the 18x 
> with the SDP answer until a DTLS Client Hello is seen", right? 

I have an idea for another approach, which might even be better 
than what is in the document right now:  leave the DTLS client/server 
roles as described in draft-ietf-sip-dtls-srtp-framework-02, and
when the offerer gets the 200 Ok, the offerer sends a DTLS
HelloRequest.  This will open NAT bindings and cause an SBC
to 'latch' -- just like an ICE connectivity check would.

(If there are no middleboxes interfering with the media path,
the answerer would have initiated DTLS-SRTP by its own accord
by sending ClientHello message(s).)

> The connectivity check is not sent by the SDP offerer in the 
> draft, but by the answerer - but this is not relevant for my 
> point, I think.

Here is the text from -02's Section 6.6, ("ICE Interaction"), 
with a correction that is needed in one sentence.  Other parts 
of the document describe the offerer as having the passive role, 
and Section 6.6, it is the offerer has the passive role and 
that sends the connectivity check:

   If ICE is not being used, then there is potential for a bad
   interaction with SBCs via "latching", as described in
   [I-D.ietf-mmusic-media-path-middleboxes].  In order to avoid this
   issue, if ICE is not being used and the DTLS handshake has not
   completed, upon receiving the other side's then the passive side MUST
                                             ^
                                         "SDP answer"
   do a single unauthenticated STUN [I-D.ietf-behave-rfc3489bis]
   connectivity check in order to open up the appropriate pinhole.  All
   implementations MUST be prepared to answer this request during the
   handshake period even if they do not otherwise do ICE.

> Sorry, I have no diagram at hand. Let me explain better what 
> I had in mind: The draft assumes some unmanaged NAT or 
> firewall in this scenario, e.g. a residential one, close to 
> the UA. IN ADDITION, there still can be the (managed) 
> middleboxes described in 
> draft-ietf-mmusic-media-path-middleboxes-01. Its them who may 
> discard a STUN connectivity check and by this make the 
> handshake as described currently stall.

Ok -- so a standard consumer VoIP box connected to a as-typically-deployed
SBC.

-d

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Thu, 21 Aug 2008 19:04:34 -0400

Dean,

Wrong, ISUP allows for media  in both directions before answer.

Also, is the IETF taking on the topic of "billing/charging" now?

Martin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henry Sinnreich
Sent: Thursday, August 21, 2008 5:21 PM
To: Dean Willis; Dwight, Timothy M (Tim)
Cc: [email-masked]; [email-masked]; Dan Wing
Subject: Re: [Sip] Early media as an endpoint application

Dean,

How would the proposed "Media Before Answer" endpoint/gateway
application
affect the billing in your opinion? Would it change anything with the
issues
here below? 

Henry

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Thu, 21 Aug 2008 19:44:32 -0400

Dan,

I support a draft that relays a CN, but would have issues with the IETF
addressing issues WRT when billing/charging should begin and end.

Martin 

-----Original Message-----
From: Dan York [mailto:[email-masked]] 
Sent: Thursday, August 21, 2008 7:37 PM
To: DOLLY, MARTIN C, ATTLABS; [email-masked]; Henry Sinnreich;
Dean Willis; Dwight, Timothy M (Tim)
Cc: [email-masked]; [email-masked]; Dan Wing
Subject: Re: [Sip] Early media as an endpoint application

Martin,

To a certain degree, some of us have already been taking on the
billing/charging question. See my P-Charge-Info draft (which I have been
told in comments today is doing something similar to the ISUP Charge
Number parameter).

Dan
-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com

-----Original Message-----
From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>

Date: Thu, 21 Aug 2008 19:04:34 
To: Henry Sinnreich<[email-masked]>; Dean
Willis<[email-masked]>; Dwight, Timothy M
(Tim)<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; Dan Wing<[email-masked]>
Subject: Re: [Sip] Early media as an endpoint application

Dean,

Martin

-----Original Message-----

Dean,

Henry

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Fri, 22 Aug 2008 02:38:13 +0000

I'm sorry but it seems pretty far-fetched to try and blame SIP
shortcomings on "Bell-heads".  Since when have they (we) been that
influential?

My point to Henry was just that this "problem" is not specific to PSTN
gateways; so it wouldn't be appropriate to confine its solution to such
a device.  The need for media interaction prior to call completion
(which as Martin notes can be 2-way) arises from the intermediated
service model; which is as applicable to VoIP as to circuit switched
networks.

Tim

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Thursday, August 21, 2008 2:54 PM
> To: Dwight, Timothy M (Tim)
> Cc: Henry Sinnreich; Dan Wing; [email-masked]; [email-masked]
> > What if you want to implement those or similar services 
> between VoIP  
> > end

---

From: "Schneider, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 22 Aug 2008 12:01:02 +0200

> by sending ClientHello message(s).)

A good idea. I'd say, the offerer should send this HelloRequest as soon
as he gets the SDP answer, if he hasn't got the ClientHello before. And
the answerer should send the answer as soon as possible, e.g. in an 18x,
even if PRACK is not used. (The HelloRequest lets the answerer know that
the answer has reached its destination.)

Peter

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Aug 2008 10:44:14 -0400

> addressing issues WRT when billing/charging should begin and end.

IMO the ietf has no desire to be involved in deciding when billing 
begins and ends. But its hard to deny that the issue isn't a subtext to 
many other decisions about how things are done.

Its like some of the requests that have come from IMS - they sometimes 
start out as a request that some particular artifact be added to sip, 
with little explanation of why, or how it will be used, or why the 
proposed mechanism was selected rather than some other one. Usually in 
such cases we push back and ask for requirements that are more in the 
form of use cases, so that an appropriately general mechanism can be 
designed.

I think it *might* be reasonable for accounting to be taken up as a 
topic by Bliss - not to standardize how it is done, but to examine a 
number of use cases of differing ways that accounting might be done, and 
how the protocol does/doesn't facilitate them.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 22 Aug 2008 12:34:12 -0500

> affect the billing in your opinion? Would it change anything with  

If you wanted to bill on signaling, the billing nodes would need to be  
able to differentiate between the "early" session and the "real"  
session. They might could do this by noting the initiator of the  
session if a "repalces" model or "reinvite" model is used, or by  
adding a header field.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 22 Aug 2008 12:37:11 -0500

> Wrong, ISUP allows for media  in both directions before answer.

However, that's not the use case that is commonly cited as causing the  
SIP interaction problem. If it were, we'd probably have come to a more  
reasonable conclusion on SIP early media.

> Also, is the IETF taking on the topic of "billing/charging" now?

I'd argue that we moved into the topic of "accommodating broken  
billing/charging models" by the concessions we made with our flawed  
and mostly dysfunctional early-media model.

It's broken now, it has always been broken, and I predict it will  
continue to be broken for the future of SIP 2.0.

---

From: Dean Willis <[email-masked]>
Date: Fri, 22 Aug 2008 12:39:04 -0500

On Aug 21, 2008, at 6:44 PM, DOLLY, MARTIN C, ATTLABS wrote:
>
> I... would have issues with the IETF

I agree to that also. However, I support having a clearly defined  
state machine that a billing/charging model could queue off of.

The problem is that the current "early media" model lacks such a  
mechanism, especially when forking has occurred.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Aug 2008 13:41:07 -0400

DOLLY, MARTIN C, ATTLABS wrote:
> Paul,
> 
> We could try taking up the accounting topic in BLISS, but need to be
> aware of all the national variants.

Well, "all" is rather daunting. :-)
Perhaps it would be sufficient to have a "representative set" of use cases?

	Thanks,
	Paul

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Friday, August 22, 2008 10:44 AM
> To: DOLLY, MARTIN C, ATTLABS
> Cc: [email-masked]; [email-masked]; Henry Sinnreich; Dean Willis;
> Dwight, Timothy M (Tim); [email-masked]; [email-masked]; Dan Wing

---

From: Dean Willis <[email-masked]>
Date: Fri, 22 Aug 2008 12:55:33 -0500

> shortcomings on "Bell-heads".  Since when have they (we) been that

Since we were busy defining the SIP-PSTN interworking model back in  
about 1998, and came up with the "early media" approach. Mots of us  
working on SIP back then were bell-headed, even if we didn't think so  
at the time. It's a matter of accepting the preconceived notions that  
the telephone system was reasonable. I'm quite guilty of it myself.  
Remember, Henry and I were sponsored by MCI back then, and our mission  
was to make something that interopped with the PSTN and that the  
business people could understand how to make a business out of.

A lot of the insanity here stems back to obtuseness on my part at the  
interim meeting we held with the DCS cable team back in 1999, where we  
came up with the idea of QOS preconditions negotiated with reliable- 
provisionals rather than just using a two-stage invite. We should have  
had a first INVITE for QoS, and a re-invite for media, and probably  
would have if we hadn't had people thinking that the first 200 OK  
meant "start billing", or if we had realized that gateway/precondition  
forking really requires a B2BUA, not a proxy. But JDR and I really  
believed in proxies back then . . .

See:

http://www.softarmor.com/sipwg/meets/interim-nov-1999/

> service model; which is as applicable to VoIP as to circuit switched

So we need to be able to differentiate the "intermediated" session  
from the "non-intermediated" session. Insisting that the "session"  
hasn't started (despite the fact that media is flowing) until some  
arbitrary downstream event has occurred is just silly.

We've massed layers of complexity (early media, early session,  
preconditions)  onto the rather elegant base protocol just to  
compensate for this misunderstanding. And frankly, it hasn't helped  
things all that much -- implementations are now insanely difficult,  
I'm confused by it, and AFAIK, nobody's stuff actually works 100% to  
the specs. Why should we be happy with this? As (I think it was  
Douglas Adams that said) it is easy to become blind to the essential  
uselessness of these things due to the sense of wonder and fulfillment  
one gets from getting them to do anything at all.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 22 Aug 2008 23:44:31 +0200

Hi, 

>>application affect the billing in your opinion? Would it change 
>>nything with the issues here below?
>
able to differentiate between the "early" session >and the "real"
session. They might could do this by noting the initiator of the session
if a "repalces" model or 
>"reinvite" model is used, or by adding a header field.

The differentiation is based on what comes before 200 OK, and what comes
after.

I am not sure how separate/replaced dialogs etc would help.

I don't think early media as such is the problem, but (as others have
also said) forking. And, to be precise: parallel forking.

Two potential solutions:

1. Forbid parallel forking.

- That is probably no problem when forking occurs "in the network", for
example when a request is first forked to an anouncement server, and
after that towards the called user. I believe serial forking is mostly
used in such scenarios - and 199 helps to indicate when one forked leg
is "finished" :)

- That is probably a problem when a registrar forks, because it would
take a long time before all of the called user's terminals would be
given a chance to "ring". Once the registrar has tried all terminals the
calling user has probably hang up...

2. Terminate forking already on 18x

- When a forking proxy receives a 18x (with SDP) on one leg, it would
terminate all other legs. That is very similar to Dean's proposal on
sending 200 OK already for early media (but it would not affect charging
models etc which are based on the assumption that 200 OK means that the
user has answered).

- The problem, as Dean said earlier, is of course that the one that the
entity that first starts to send early media (and 18x) may not be the
entity that would accept the call. But, since all other legs would be
terminated, the only entity which can accept the call is the one who
send 18x first.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 22 Aug 2008 23:52:39 +0200

Hi, 

>>I'm sorry but it seems pretty far-fetched to try and blame SIP
shortcomings on "Bell-heads".  Since when have they (we) >>been that
influential?
>Since we were busy defining the SIP-PSTN interworking model back in
about 1998, and came up with the "early media" 
>approach. Mots of us working on SIP back then were bell-headed, even if
we didn't think so at the time. It's a matter of 
>accepting the preconceived notions that the telephone system was
reasonable. I'm quite guilty of it myself.  
>Remember, Henry and I were sponsored by MCI back then, and our mission
was to make something that interopped with the 
>PSTN and that the business people could understand how to make a
business out of.

I think we should all be thankful for your mission back then. Otherwise
we would all now be working on H.323 version 56.

...and they don't serve cookies in SG16.

Whether the protocol solution for early media could have been done in
another way is of course one question, but I agree with Tim that
use-cases where early media is needed is nothing PSTN specific. I think
there are useful IP services (no matter whether they are implemented in
the network or in Henry's pure/clean IP-IP world) which use early media.

>A lot of the insanity here stems back to obtuseness on my part at the
interim meeting we held with the DCS cable team 
>back in 1999, where we came up with the idea of QOS preconditions
negotiated with reliable- provisionals rather than just 
>using a two-stage invite. We should have had a first INVITE for QoS,
and a re-invite for media, and probably would have 
>if we hadn't had people thinking that the first 200 OK meant "start
billing", 

Instead of the first 200 OK you could have used 202, and 200 OK whenever
the billing was supposed to start.

...if there would have been a 202 at that time, that is :)

>or if we had realized that gateway/precondition forking really requires
a B2BUA, not a proxy. But JDR and I really 
>believed in proxies back then . . .

If we could turn back time...

Regards,

Christer

> gateways; so it wouldn't be appropriate to confine its solution to 
> such a device.  The need for media interaction prior to call 
> completion (which as Martin notes can be 2-way) arises from the 
> intermediated service model; which is as applicable to VoIP as to 
> circuit switched networks.
>

So we need to be able to differentiate the "intermediated" session from
the "non-intermediated" session. Insisting that the "session"  
hasn't started (despite the fact that media is flowing) until some
arbitrary downstream event has occurred is just silly.

We've massed layers of complexity (early media, early session,
preconditions)  onto the rather elegant base protocol just to compensate
for this misunderstanding. And frankly, it hasn't helped things all that
much -- implementations are now insanely difficult, I'm confused by it,
and AFAIK, nobody's stuff actually works 100% to the specs. Why should
we be happy with this? As (I think it was Douglas Adams that said) it is
easy to become blind to the essential uselessness of these things due to
the sense of wonder and fulfillment one gets from getting them to do
anything at all.

--
Dean

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

---

From: Dean Willis <[email-masked]>
Date: Sat, 23 Aug 2008 01:36:14 -0500

> ...and they don't serve cookies in SG16.

Thanks! I look at my mission is making the Internet better, one cookie  
at a time.

> the network or in Henry's pure/clean IP-IP world) which use early  

I'll agree that there are services that use media transmission before  
the final session is established.

Would these services be impossible if there were actually separate SIP  
sessions for the "early" and "regular" sessions?

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 23 Aug 2008 13:12:10 +0200

Hi,

>>I think we should all be thankful for your mission back then.  
>>Otherwise we would all now be working on H.323 version 56.
>>

Geneva has better fondue than Minneapolis, though...

>>use-cases where early media is needed is nothing PSTN specific. I  
>>think there are useful IP services (no matter whether they are implemented  
>>in the network or in Henry's pure/clean IP-IP world) which use early  
>>media.
>
>

Maybe not, but I am still not sure what problems you would solve by having separate sessions.

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Sat, 23 Aug 2008 23:06:52 -0500

> having separate sessions.

By having a fully connected "offer/answer" completed session instead  
of "early session", we  escape most of the state machine complexities,  
resolve the "media before answer" pinhole opening and codec loading  
problem, etc. It also makes ICE and SRTP much easier to deal with. By  
making the transition to "regular" session a re-invite  the gateway  
can transition from send-only to send-receive (if needed), the billing  
system (if it cares) can start the meter running, etc.

Plus we can drop all the 100-rel and preconditions cruft out of the  
state machine completely, making life MUCH better for the coder.

Think of it this way -- If I'm calling a PSTN gateway, do I really  
want to wait until the PSTN side connection completes before I do the  
setup work for SRTP? I think I'd rather get that out of the way before  
the called party answers, or before I even see early media coming back  
unprotected.

Now, lets think about forking. When we fork in a proxy, the UAC can  
only deal with one "best answer", and early media is anybody's guess  
as to how it might work or what might happen (it pretty much turns to  
soup, especially if you get multiple early media channels).

Consider instead that a forking node is really a "forking gateway",  
not a proxy. It takes one call in, establishes a fully-negotiated  
"early session",  then sends out its multiple INVITES.  As those  
sessions (which might have early media) connect up, the forking  
gateway deals with the multiple media streams (by bridging,  
discarding, whatever). When a forked session matures to a "regular  
session", the forking gateway can re-invite the UAC to make that  
session a "regular session", or can even arrange to drop itself out of  
the media path if needed.

If we have to have forking, and we have to have media before there's a  
final answer, then I think something like this is needed to make it  
work.
--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 24 Aug 2008 14:25:32 +0200

Hi,

>>>Would these services be impossible if there were actually separate  
>>>SIP sessions for the "early" and "regular" sessions?
>>

Having worked with/implemented offer/answer state machines for many years, it really isn't that complex in my opinion. The problem is that people are often trying to "implement call flows", not taking forking and multiple early dialogs into consideration etc.

>problem, etc.

The "media before answer" (if you refer to SDP answer) can be solve by simply saying that one must send an SDP answer must be sent before media is sent.

The you-must-be-able-to-receive-media-once-you-have-sent-the-INVITE doesn't work, because today media sent before SDP answer will often be discarded anyway.

>It also makes ICE and SRTP much easier to deal with. By  

So, just to clarify, you are still talking about a single SIP session, right?

The issue with that solution is of course that a forking proxy, as currently defined, would terminate all other legs once the first 200 OK (establishing the early media path of the session) arrives.

But, that would minimize multiple early media streams, which again in my opinion shows that the main problem is not offer/answer, but forking :)

>state machine completely, making life MUCH better for the coder.

If you separate the offer/answer state machine from the SIP transaction state machine it shouldn't really matter in what SIP messages the offers and answers are carried.

And, eventhough we probably would be able to remove SDP from provisional responses, I think provisional responses would still be useful for other things (indicating ringing etc).

But, of course we could have instead have used something like UPDATE (or even INFO) to indicate "ringing" etc, instead of provisional responses.

>the called party answers, or before I even see early media coming back  

What prevents you from doing the SRTP negotiation using reliable provisional responses, in the same way you are able to perform preconditions before the called party answers? 

>soup, especially if you get multiple early media channels).

Correct. And, that will be a problem as long as it is possible for the UAC to receive multiple early streams - no matter how they are negotiated.

>discarding, whatever).

Doesn't that simply move the how-to-choose-which-early-media-stream-to-listen-to from the UAC to the forking proxy/gateway?

>When a forked session matures to a "regular session", the forking gateway can re-invite the UAC to >make that session a "regular session",

Today it does that again by sending 200 OK. 

Again, I agree that many things probably could be done in a "cleaner" way, but I think the main problem still exists: if there are multiple early media streams (due to forking proxy or forking gateway), how do I choose which one to play?

>or can even arrange to drop itself out of the media path if needed.

How would that work? It would be able to change the local contact from itself to the called party, but it would not be able to add the possible Record-Routes between itself and the called user.

Not being able to modify the signaling path during a session (read: update the Record-Route) is a "bug" in the protocol, I think, but it's a separate issue :)

>final answer, then I think something like this is needed to make it  

Again, it could make the signaling flows a little more nicer, and it would move some decissions from the UAC to the forking gateway, but the problem with multiple media streams (no matter whether you call them early or not :) would still exist.

In my opinion, the only solution, using what we have today, is to make sure there is only one early media stream sent.
 
Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Sun, 24 Aug 2008 14:30:55 -0500

On Aug 24, 2008, at 7:25 AM, Christer Holmberg wrote:

>>
> The "media before answer" (if you refer to SDP answer) can be solve  
> by simply saying that one must send an SDP answer must be sent  
> before media is sent.
>
> The you-must-be-able-to-receive-media-once-you-have-sent-the-INVITE  
> doesn't work, because today media sent before SDP answer will often  
> be discarded anyway.
>

Perhaps not, but it's how ever device and service  I currently have  
works.

Not that they work well, mind you.

> So, just to clarify, you are still talking about a single SIP  

That's one of the two possible approaches, and probably the easiest to  
explain.

> The issue with that solution is of course that a forking proxy, as  
> currently defined, would terminate all other legs once the first 200  
> OK (establishing the early media path of the session) arrives.

One could of course change that behavior and have the forking proxy  
return ALL responses.

>
>
> But, that would minimize multiple early media streams, which again  
> in my opinion shows that the main problem is not offer/answer, but  
> forking :)

The two certainly play poorly with each other.

> If you separate the offer/answer state machine from the SIP  
> transaction state machine it shouldn't really matter in what SIP  
> messages the offers and answers are carried.

Perhaps true, but the SIP 100-rel state machine is profoundly ugly all  
by itself.

>
>
> And, eventhough we probably would be able to remove SDP from  
> provisional responses, I think provisional responses would still be  
> useful for other things (indicating ringing etc).

Yes, and provisionals also impact the resend timers. We need them. We  
just don't need 100-rel.

>
>
> But, of course we could have instead have used something like UPDATE  
> (or even INFO) to indicate "ringing" etc, instead of provisional  
> responses.
>
> What prevents you from doing the SRTP negotiation using reliable  
> provisional responses, in the same way you are able to perform  
> preconditions before the called party answers?

In my case, mostly the desire to avoid reliable provisional responses.

And when you cross-factor reliable provisional, SRTP, and forking, you  
get a real mess.

> Correct. And, that will be a problem as long as it is possible for  
> the UAC to receive multiple early streams - no matter how they are  
> negotiated.
>
> Doesn't that simply move the how-to-choose-which-early-media-stream- 
> to-listen-to from the UAC to the forking proxy/gateway?

It allows the forking gateway to either mix all the streams into one  
(a boon to the bandwidth-restricted UAC), or more intelligently choose  
which one to relay based on media-analysis. For example, ringing can  
easily be differentiated from speech, so if a forking-b2bua sees four  
legs of ringing and one of speech, it could quite reasonably choose  
the speech channel to send back to the UAC.

>
>
>> When a forked session matures to a "regular session", the forking  
>> gateway can re-invite the UAC to >make that session a "regular  
>> session",
>

Right -- assuming you did your media setup in provisional (and keying  
in reliable provisional, which is messy)

> Again, I agree that many things probably could be done in a  
> "cleaner" way, but I think the main problem still exists: if there  
> are multiple early media streams (due to forking proxy or forking  
> gateway), how do I choose which one to play?
>

I'm not aware of a perfect asnwer, but (as above) can say there are  
definitely several "better" answers than what we have now.

> How would that work? It would be able to change the local contact  
> from itself to the called party, but it would not be able to add the  
> possible Record-Routes between itself and the called user.

Media path, not signaling. Fall back to 3PCC setup techniques on a  
reinvite sequence.

>
> Not being able to modify the signaling path during a session (read:  
> update the Record-Route) is a "bug" in the protocol, I think, but  
> it's a separate issue :)
>

yeah, re-invite should be abele to re-route.

> Again, it could make the signaling flows a little more nicer, and it  
> would move some decissions from the UAC to the forking gateway, but  
> the problem with multiple media streams (no matter whether you call  
> them early or not :) would still exist.

Perhaps. However, one of the more profound problems today (as with  
mobile nets) is limited bandwidth to the UA. Dealing with mixing,  
recoding, and selection-from-alternatives in a "server" is much easier.

>
> In my opinion, the only solution, using what we have today, is to  
> make sure there is only one early media stream sent.

Yep. That's quite true. It's also very difficult, if anything forks.  
Our greatest power is our greatest problem.

--
Dean

---

From: Henry Sinnreich <[email-masked]>
Date: Sun, 24 Aug 2008 15:01:54 -0500

(changed the subject line)
I have followed this discussion and am convinced that (though I started it)
the issues raised here and in countless other SIPPING/SIP related
discussions cannot be solved by apparent logic, no matter how long and how
thorough. Just like the physics cannot be proven by discussions but only by
experiment. This is the whole difference between engineering/science and
beliefs/opinions. 

The only way IMO to fix the SIPPING/SIP issues discussed here is to have an
open reference implementation running in a test bed (such as one provided
maybe by the SIP Forum) and cooperate in LUNIX-style with testing (why not
in SIPit events as well) and fixing the code. Any fruitful discussions must
be part of fixing running code based on test results. This is actually
pretty plain, so forgive my rant...

Selecting a reference SIP implementation:
There are quite a few SIP UA and and SIP server OS code sites available and
the next step could be selecting the best candidate(s).
If asked, I would be only to happy to recommend some candidates.

Continuing such discussions without a reference implementation is fruitless
and the SIP issues discussed here will not get fixed so as to meet the
requirements for a good standard. This applies to all SIP related WGs.

Any comments?

Thanks, Henry

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 24 Aug 2008 22:19:04 +0200

Hi Henry,

Based on what criteria would you choose the reference implementation(s), and what is it that you really want to test? Offer/answer?

Because, eventhough there seems to be problems implementing offer/answer correctly, the early media/forking problem, raised by Dean, is more of a "bi product" of the way we designed the protocol. In other words, even if you have an implementation which works 100% according to the specs, it doesn't solve the problem which may come up when you, due to forking, receive early media from multiple locations :)

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Henry Sinnreich [mailto:[email-masked]]
Lähetetty: su 24.8.2008 22:01
Vastaanottaja: Dean Willis; Christer Holmberg
Kopio: SIP IETF; Cullen Jennings
Aihe: Fixing SIP with OS reference implementations for UA and server

Any comments?

Thanks, Henry

---

From: Henry Sinnreich <[email-masked]>
Date: Sun, 24 Aug 2008 15:31:41 -0500

Christer,

I agree with both you and Dean and should have also specified that the SIP
standard should be amended step by step, based on testing the reference
implementation. There is nothing wrong with an I-D with fixes for SIP based
on testing a reference implementation.

Sorry for not having been clear also on the need to fix the standard
document by adding an amendment RFC.

Henry 

On 8/24/08 3:19 PM, "Christer Holmberg" <[email-masked]>
wrote:

> 
> Hi Henry,
> 
> Based on what criteria would you choose the reference implementation(s), and
> what is it that you really want to test? Offer/answer?
> 
> Because, eventhough there seems to be problems implementing offer/answer
> correctly, the early media/forking problem, raised by Dean, is more of a "bi
> product" of the way we designed the protocol. In other words, even if you have
> an implementation which works 100% according to the specs, it doesn't solve
> the problem which may come up when you, due to forking, receive early media
> from multiple locations :)
> 
> Regards,
> 
> Christer
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 24 Aug 2008 22:52:18 +0200

Hi,

>Perhaps not, but it's how ever device and service  I currently have  

At least in environments with gating, SBCs and/or bandwidth/radio resource reservation procedures I don't think those devices would work very well, because the media sent before the SDP answer would most likely be terminated somewhere.

>Not that they work well, mind you.

So, the first step would then be: make sure you don't send media until you have sent an SDP answer :)

>>>can transition from send-only to send-receive (if needed), the  
>>>billing system (if it cares) can start the meter running, etc.
>>

Probably the easiest to implement also. Because, if you would use separate SIP sessions, you would need to somehow "transfer" the ICE/SRTP/resource reservation state between them.

...unless you want to perform separate ICE/SRTP/resource reservation on the early- and the full dialog sessions, which would be really bad.

>One could of course change that behavior and have the forking proxy  

They do currently forward all 200 OK responses, but there will of course only be multiple 200 OK responses if they were sent before the CANCEL sent by the forking proxy arrived. 

>Yes, and provisionals also impact the resend timers. We need them. We  

If you want to get rid of 100-rel there is also another way: get rid of UDP ;)

>the speech channel to send back to the UAC.

What if it sees four legs of speech and one of ringing?

I agree that you could make the life of the UAC easier, and better control that the media sent towards the UAC "fits" within the negotiated UAC-proxy bandwidth etc, using this kind of forking-b2bua.

But, it would require a big box, media mixing and possibly transcoding, in the network, and someone told me that IETF is about UA-to-UA-with-nothing-but-stupid-cable in between :)

>recoding, and selection-from-alternatives in a "server" is much easier.

Yes, but saying that is not politically correct, is it? :)

>>In my opinion, the only solution, using what we have today, is to make sure there is only one early >>media stream sent.
>

Eventhough it doesn't solve the problem, I think many things would work much better if people implemented and used RFC 3841 (and RFC 3840). It e.g. allows you to indicate that you don't wish parallel forking to occur.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 24 Aug 2008 22:31:36 -0400

Henry,

Its interesting that you have drawn parallels here with physics.
In physics there are theorists and experimentalists. I think most of 
them agree that progress in physics requires both - the experimentalists 
require a theory to verify, and the theorists need observed violations 
of the theory and data that is unexplained by existing theories.

I agree that experimentalists are useful in our business too. I in 
general agree with your implied assertion that we (the IETF sip-related 
WGs) are theorists.

Its not entirely clear to me whether we need *more* experimentalists 
than we already have, or if they could or should be more closely 
affiliated with the IETF than they already are. We do already have SIP 
Forum, running SIPit. We hear the results of that. And clearly there are 
plenty of participants here that speak for implementations.

Based on what you have said before, I gather you think there is too much 
standardization done in relation to the amount of implementation done. 
There certainly are cases when that is true. But remember that most of 
the documents we are producing are only drafts - they aren't even 
complete theories ready to be tested. Even the RFCs we produce are only 
Proposed Standards, and so are probably good candidates for testing.

If one person, or a very few working closely together, are doing all the 
design and implementation of something, then you *might* be able to get 
by just implementing without first specifying what is being implemented. 
Some of the agile methods advocate that kind of approach.  If what you 
are attempting has too many moving parts for that, then its still 
necessary to write a spec. Doing an open source implementation doesn't 
change that. It may just change which group does the specification. In a 
way this is like having the experimental physicists develop the theories.

Bottom line - IMO it would be good to get more early implementation 
experience than we seem to get now. An open reference implementation is 
one way to get that. But I don't think we should make some sort of rule 
that you can't submit a draft without a reference implementation, or 
even that you can't have an RFC without a reference implementation. 
(There is already a requirement for multiple implementations before a 
*Draft* standard.)

	Thanks,
	Paul

Henry Sinnreich wrote:
>>>>> billing

---

From: Dean Willis <[email-masked]>
Date: Sun, 24 Aug 2008 23:40:51 -0500

On Aug 24, 2008, at 3:52 PM, Christer Holmberg wrote:

>
> Probably the easiest to implement also. Because, if you would use  
> separate SIP sessions, you would need to somehow "transfer" the ICE/ 
> SRTP/resource reservation state between them.
>
> ...unless you want to perform separate ICE/SRTP/resource reservation  
> on the early- and the full dialog sessions, which would be really bad.
>

Good point.

> They do currently forward all 200 OK responses, but there will of  
> course only be multiple 200 OK responses if they were sent before  
> the CANCEL sent by the forking proxy arrived.

Right. I meant that the forking proxy would have to not prune the  
forks, and the UA might have to deal with multiple concurrent media  
sessions as a result.

> If you want to get rid of 100-rel there is also another way: get rid  

I've suggested that from time to time. Very seriously.

However, you still need end-to-end reliability, because proxies might  
receive a message (satisfying TCP), but then drop it.

So one really has to eliminate UDP and proxies. I'm OK with that.

> I agree that you could make the life of the UAC easier, and better  
> control that the media sent towards the UAC "fits" within the  
> negotiated UAC-proxy bandwidth etc, using this kind of forking-b2bua.
>
> But, it would require a big box, media mixing and possibly  
> transcoding, in the network, and someone told me that IETF is about  
> UA-to-UA-with-nothing-but-stupid-cable in between :)

See above discussion of eliminating proxies too .  . .

> Yes, but saying that is not politically correct, is it? :)

Me, politically correct? Surely you jest.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Aug 2008 09:01:43 -0400

> forks, and the UA might have to deal with multiple concurrent media  

There is the Request-Disposition header defined in 3841. 
(Request-Disposition:no-cancel). If anybody actually implemented it.

	Paul

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 25 Aug 2008 18:08:29 +0200

> What if it sees four legs of speech and one of ringing? 

You have a talking donkey touring a poor sound engineer?

Keith

> Behalf Of Christer Holmberg
> Sent: Sunday, August 24, 2008 9:52 PM
> To: Dean Willis
> Cc: SIP IETF
> >>The "media before answer" (if you refer to SDP answer) can 
> be solve by 
> >>simply saying that one must send an SDP answer must be sent before 
> >>media is sent.
> >>
> >>doesn't work, because today media sent before SDP answer 
> will often be 
> >>discarded anyway.
> >
> >
> At least in environments with gating, SBCs and/or 
> bandwidth/radio resource reservation procedures I don't think 
> those devices would work very well, because the media sent 
> before the SDP answer would most likely be terminated somewhere.
> 
> So, the first step would then be: make sure you don't send 
> media until you have sent an SDP answer :)
> 
> >>>It also makes ICE and SRTP much easier to deal with. By making the 
> >>>transition to "regular" session a re-invite  the gateway can 
> >>>transition from send-only to send-receive (if needed), the billing 
> >>So, just to clarify, you are still talking about a single 
> SIP session, 
> >>right?
> >
> Probably the easiest to implement also. Because, if you would 
> use separate SIP sessions, you would need to somehow 
> "transfer" the ICE/SRTP/resource reservation state between them.
> 
> ...unless you want to perform separate ICE/SRTP/resource 
> reservation on the early- and the full dialog sessions, which 
> would be really bad.
> 
> They do currently forward all 200 OK responses, but there 
> will of course only be multiple 200 OK responses if they were 
> sent before the CANCEL sent by the forking proxy arrived. 
> 
> >It allows the forking gateway to either mix all the streams 
> into one (a 
> >boon to the bandwidth-restricted UAC), or more intelligently choose 
> >legs of ringing and one of speech, it could quite reasonably 
> choose the 
> >speech channel to send back to the UAC.
> 
> I agree that you could make the life of the UAC easier, and 
> better control that the media sent towards the UAC "fits" 
> within the negotiated UAC-proxy bandwidth etc, using this 
> kind of forking-b2bua.
> 
> transcoding, in the network, and someone told me that IETF is 
> about UA-to-UA-with-nothing-but-stupid-cable in between :)
> 
> >>>If we have to have forking, and we have to have media 
> before there's 
> >>>a final answer, then I think something like this is needed 
> to make it 
> >>>work.
> >>
> >>In my opinion, the only solution, using what we have today, 
> is to make sure there is only one early >>media stream sent.
> >
> Eventhough it doesn't solve the problem, I think many things 
> would work much better if people implemented and used RFC 
> 3841 (and RFC 3840). It e.g. allows you to indicate that you 
> don't wish parallel forking to occur.
> 
> Regards,
> 
> Christer
> 
> [email-masked] for questions on current sip

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 25 Aug 2008 15:04:56 -0700

Paul,

I really love your way of arguing, but feel it's too apologetic of the
present way of doing business as usual, since SIP has become an ecosystem in
its own right and has spawned a global VoIP industry. This implies far
greater sense of responsibility that can only be met by using the most
successful examples of software development in academia and R&D:

The same person(s) to write both the code and papers in parallel and publish
them along with ample test results. It's much of a looped process. There are
plenty of such sites, for example in the open source community. There are
bug fixes, lists of know issues, etc. We all know them and have the
responsibility to apply such engineering _discipline_ here as well.

* When seeing over 100 standards, how is one going to know SIP in adequate
depth?
* What is the cost of this complexity?
* When proposing an extension what are the unintended consequences?
* When seeing dissent among the leading SIP experts, where to go for
guidance, except in some test environment?

That explains my insistence on running code and testing as part and parcel
of further SIP development, and also for fixing the problems currently
discussed here - but not mainly by discussions :-)

The endless flow of I-Ds without running code and test results has to stop
somewhere IMO, but I don't want to belabor it since we probably disagree.

Thanks again for your thoughtful comments.
My two cents,

Henry

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Aug 2008 18:45:09 -0400

Henry,

I've been thinking about this a bit recently. (But not too much or too 
deeply.)

In the open source world, in some sense there is only one 
implementation. If that is the implementation of a distributed 
application, then the protocol connecting the pieces is embedded in the 
implementation, rather than being an external interface. (Though I guess 
it *could* be an external interface if it was sufficiently documented, 
but that would tie down the evolution of the application.)

If you would like to enable *multiple* implementations of different 
components of that application, e.g. using different languages or for 
different OSs, then for them to able to remain consistent with the rest 
I guess they must be merged into the same open source initiative. That 
is one way to do things, but not everybody wants to work that way.

In a sense, the IETF is also an open source initiative. But what is 
being developed is interface specs rather than running code. The 
assumption being that those interfaces are the stable part, while the 
implementations are many, varied, and changing over time.

If the goal is to have everybody working on and using a single 
implementation then an open source approach is probably better and 
quicker. If the goal is to facilitate a multiplicity of interoperable 
implementations, then the IETF process may be better.

In any case I still think there is a valid distinction between theory 
and experiment. Do you want a crypto implementation that hasn't had its 
algorithm designed by a crypto theorist? Do you want a communication 
protocol that has been implemented for the common cases but hasn't had 
all the subtle cases considered? (There is a reason we make fun of 
implementors that implement to the use cases rather than the spec. Its 
even worse if all you have is the use cases and the code - no spec.) It 
is much easier to examine those kinds of issues with a high level spec 
than a piece of executable code.

There is no doubt a place for all these techniques. The process of 
writing the spec first is slow - no doubt about it. Its not appropriate 
for everything - only for critical stuff that is going to be implemented 
lots of times. Just doing an open source project without a separate spec 
may be more practical for more narrowly focused goals. And of course you 
can always have an open source project to implement a spec that is 
developed alongside that project.

	Thanks,
	Paul

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 25 Aug 2008 16:04:22 -0700

Paul,

We sure agree on the need for the protocol specification, but seem to differ
on how to get there.

Henry

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 26 Aug 2008 09:01:57 +0200

Hi Henry,

As I've said before, I don't think the number of standards is the problem.

Many of the extension specifications simply specify ways (headers, parameters etc) to transport specific data. Those normally don't have big impact on the core SIP state machine, and whether they are implemented or not depends on the requirements of the network environment in which they are to be used. If there are no requirement, it doesn't matter whether you have implemented header X and I haven't (the header should simply be ignored).

The important thing is that people get the relatively small number of core specifications correct - specs like 3261, 3264 etc. If you don't get those right, it doesn't matter if you have implemented every other SIP related specification out there... 

Regards,

Christer

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: 26. elokuuta 2008 1:05
To: Paul Kyzivat
Cc: Christer Holmberg; Dean Willis; SIP IETF; Cullen Jennings
Subject: Re: [Sip] Fixing SIP with OS reference implementations for UA and server

Paul,

I really love your way of arguing, but feel it's too apologetic of the present way of doing business as usual, since SIP has become an ecosystem in its own right and has spawned a global VoIP industry. This implies far greater sense of responsibility that can only be met by using the most successful examples of software development in academia and R&D:

The same person(s) to write both the code and papers in parallel and publish them along with ample test results. It's much of a looped process. There are plenty of such sites, for example in the open source community. There are bug fixes, lists of know issues, etc. We all know them and have the responsibility to apply such engineering _discipline_ here as well.

* When seeing over 100 standards, how is one going to know SIP in adequate depth?
* What is the cost of this complexity?
* When proposing an extension what are the unintended consequences?
* When seeing dissent among the leading SIP experts, where to go for guidance, except in some test environment?

That explains my insistence on running code and testing as part and parcel of further SIP development, and also for fixing the problems currently discussed here - but not mainly by discussions :-)

The endless flow of I-Ds without running code and test results has to stop somewhere IMO, but I don't want to belabor it since we probably disagree.

Henry

On 8/24/08 9:31 PM, "Paul Kyzivat" <[email-masked]> wrote:

> them agree that progress in physics requires both - the 
> experimentalists require a theory to verify, and the theorists need 
> observed violations of the theory and data that is unexplained by existing theories.
> 
> Forum, running SIPit. We hear the results of that. And clearly there 
> are plenty of participants here that speak for implementations.
> 
> Based on what you have said before, I gather you think there is too 
> much standardization done in relation to the amount of implementation done.
> complete theories ready to be tested. Even the RFCs we produce are 
> only Proposed Standards, and so are probably good candidates for testing.
> 
> If one person, or a very few working closely together, are doing all 
> the design and implementation of something, then you *might* be able 
> to get by just implementing without first specifying what is being implemented.
> change that. It may just change which group does the specification. In 
> a way this is like having the experimental physicists develop the theories.
> 
> experience than we seem to get now. An open reference implementation 
> is one way to get that. But I don't think we should make some sort of 
> rule that you can't submit a draft without a reference implementation, 
> or even that you can't have an RFC without a reference implementation.
>> I agree with both you and Dean and should have also specified that 
>> the SIP standard should be amended step by step, based on testing the 
>> reference implementation. There is nothing wrong with an I-D with 
>> fixes for SIP based on testing a reference implementation.
>> 
>>> Based on what criteria would you choose the reference 
>>> implementation(s), and what is it that you really want to test? Offer/answer?
>>> 
>>> Because, eventhough there seems to be problems implementing 
>>> offer/answer correctly, the early media/forking problem, raised by 
>>> Dean, is more of a "bi product" of the way we designed the protocol. 
>>> In other words, even if you have an implementation which works 100% 
>>> according to the specs, it doesn't solve the problem which may come 
>>> up when you, due to forking, receive early media from multiple 
>>> locations :)
>>> 
>>> Regards,
>>> 
>>> Christer
>>> 
>>> 
>>> I have followed this discussion and am convinced that (though I 
>>> started it) the issues raised here and in countless other 
>>> SIPPING/SIP related discussions cannot be solved by apparent logic, 
>>> no matter how long and how thorough. Just like the physics cannot be 
>>> proven by discussions but only by experiment. This is the whole 
>>> difference between engineering/science and beliefs/opinions.
>>> 
>>> The only way IMO to fix the SIPPING/SIP issues discussed here is to 
>>> have an open reference implementation running in a test bed (such as 
>>> one provided maybe by the SIP Forum) and cooperate in LUNIX-style 
>>> with testing (why not in SIPit events as well) and fixing the code. 
>>> Any fruitful discussions must be part of fixing running code based 
>>> on test results. This is actually pretty plain, so forgive my rant...
>>> 
>>> There are quite a few SIP UA and and SIP server OS code sites 
>>> available and the next step could be selecting the best candidate(s).
>>> Continuing such discussions without a reference implementation is 
>>> fruitless and the SIP issues discussed here will not get fixed so as 
>>> to meet the requirements for a good standard. This applies to all SIP related WGs.
>>> 
>>> Any comments?
>>> 
>>> Thanks, Henry
>>> 
>>> 
>>>>> The "media before answer" (if you refer to SDP answer) can be 
>>>>> solve by simply saying that one must send an SDP answer must be 
>>>>> sent before media is sent.
>>>>> 
>>>>> The 
>>>>> you-must-be-able-to-receive-media-once-you-have-sent-the-INVITE
>>>>> doesn't work, because today media sent before SDP answer will 
>>>>> often be discarded anyway.
>>>>> 
>>>>>> It also makes ICE and SRTP much easier to deal with. By making 
>>>>>> the transition to "regular" session a re-invite  the gateway can 
>>>>>> transition from send-only to send-receive (if needed), the 
>>>> That's one of the two possible approaches, and probably the easiest 
>>>> to explain.
>>>> 
>>>> 
>>>>> currently defined, would terminate all other legs once the first 
>>>>> 200 OK (establishing the early media path of the session) arrives.
>>>>>> Plus we can drop all the 100-rel and preconditions cruft out of 
>>>>>> the state machine completely, making life MUCH better for the coder.
>>>> Perhaps true, but the SIP 100-rel state machine is profoundly ugly 
>>>> all by itself.
>>>> 
>>>>> 
>>>>> provisional responses, I think provisional responses would still 
>>>>> be useful for other things (indicating ringing etc).
>>>> Yes, and provisionals also impact the resend timers. We need them. 
>>>> We just don't need 100-rel.
>>>> 
>>>>> 
>>>>> But, of course we could have instead have used something like 
>>>>> UPDATE (or even INFO) to indicate "ringing" etc, instead of 
>>>>> provisional responses.
>>>>> 
>>>>>> Think of it this way -- If I'm calling a PSTN gateway, do I 
>>>>>> really want to wait until the PSTN side connection completes 
>>>>>> before I do the setup work for SRTP? I think I'd rather get that 
>>>>>> out of the way before the called party answers, or before I even 
>>>>>> see early media coming back unprotected.
>>>> And when you cross-factor reliable provisional, SRTP, and forking, 
>>>> you get a real mess.
>>>> 
>>>>> 
>>>>>> Now, lets think about forking. When we fork in a proxy, the UAC 
>>>>>> can only deal with one "best answer", and early media is 
>>>>>> anybody's guess as to how it might work or what might happen (it 
>>>>>> pretty much turns to soup, especially if you get multiple early media channels).
>>>>>> Consider instead that a forking node is really a "forking 
>>>>>> gateway", not a proxy. It takes one call in, establishes a 
>>>>>> fully-negotiated "early session",  then sends out its multiple 
>>>>>> INVITES.  As those sessions (which might have early media) 
>>>>>> connect up, the forking gateway deals with the multiple media 
>>>>>> streams (by bridging, discarding, whatever).
>>>> It allows the forking gateway to either mix all the streams into 
>>>> one (a boon to the bandwidth-restricted UAC), or more intelligently 
>>>> choose which one to relay based on media-analysis. For example, 
>>>> ringing can easily be differentiated from speech, so if a 
>>>> forking-b2bua sees four legs of ringing and one of speech, it could 
>>>> quite reasonably choose the speech channel to send back to the UAC.
>>>> 
>>>>> 
>>>> Right -- assuming you did your media setup in provisional (and 
>>>> keying in reliable provisional, which is messy)
>>>> 
>>>>> from itself to the called party, but it would not be able to add 
>>>>> the possible Record-Routes between itself and the called user.
>>>>>> If we have to have forking, and we have to have media before 
>>>>>> there's a final answer, then I think something like this is 
>>>>>> needed to make it work.
>>>>> Again, it could make the signaling flows a little more nicer, and 
>>>>> it would move some decissions from the UAC to the forking gateway, 
>>>>> but the problem with multiple media streams (no matter whether you 
>>>>> call them early or not :) would still exist.

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 26 Aug 2008 10:02:51 -0700

Christer,

> The important thing is that people get the relatively small number of core
> specifications correct - specs like 3261, 3264 etc. If you don't get those
> right, it doesn't matter if you have implemented every other SIP related
> specification out there...

I could not agree with you more.

Incidentally, we have also published such a short list in
"Simple SIP Usage Scenario for Applications in the Endpoints"
http://www.ietf.org/internet-drafts/draft-sinnreich-sip-tools-03.txt

We could compare notes, though our I-D is tailored to the usage scenario
where all applications reside in the endpoints and only the rendezvous and
session setup of SIP are used. This usage scenario is of interest when
combining SIP with Rich Internet Applications (RIA) in the Web browser.
So many apps are in the browser already, so why not add SIP apps?

Could you help out and share what the short list of key SIP standards may be
for other usage scenarios? This is of interest to a larger audience.

Henry

On 8/26/08 12:01 AM, "Christer Holmberg" <[email-masked]>
wrote:

> Many of the extension specifications simply specify ways (headers, parameters
> etc) to transport specific data. Those normally don't have big impact on the
> core SIP state machine, and whether they are implemented or not depends on the
> requirements of the network environment in which they are to be used. If there
> are no requirement, it doesn't matter whether you have implemented header X
> and I haven't (the header should simply be ignored).
> 
> The important thing is that people get the relatively small number of core
> specifications correct - specs like 3261, 3264 etc. If you don't get those
> right, it doesn't matter if you have implemented every other SIP related
> specification out there...
> 
> Regards,
> 
> Christer
> 
>  
> 
> I really love your way of arguing, but feel it's too apologetic of the present
> way of doing business as usual, since SIP has become an ecosystem in its own
> right and has spawned a global VoIP industry. This implies far greater sense
> of responsibility that can only be met by using the most successful examples
> of software development in academia and R&D:
> 
> plenty of such sites, for example in the open source community. There are bug
> fixes, lists of know issues, etc. We all know them and have the responsibility
> to apply such engineering _discipline_ here as well.
> 
> That explains my insistence on running code and testing as part and parcel of
> further SIP development, and also for fixing the problems currently discussed
> here - but not mainly by discussions :-)
>

---

From: "Eric Rescorla" <[email-masked]>
Date: Fri, 22 Aug 2008 07:01:11 -0700

> the answer has reached its destination.)

When we discussed the latching issue before, this HelloRequest technique
was considered and rejected in favor of the current STUN check based
technique. Among the reasons was that we should have one set of
NAT traversal mechanisms, namely those based on STUN and ICE.

-Ekr

---

From: "Eric Rescorla" <[email-masked]>
Date: Fri, 22 Aug 2008 10:47:04 -0700

On Fri, Aug 22, 2008 at 8:37 AM, Dan Wing <[email-masked]> wrote:
> Considering Peter's proposal, though, is it more disruprive to
> swap DTLS client/server roles, or more disruprive to keep them
> the same (offerer is always DTLS server) and use HelloRequest?

I don't see a problem with the roles being variable, as long as the
offerer is prepared to take on either role.

-Ekr