Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04; why encapsulation is problematic

[Adam Roach <[e-mail]>]

On 11/10/09 2:01 PM, [e-mail] wrote:
>
> These are my issues with SIP-T:
>
> 1) ISUP messages end up at end users. This violates regulatory requirements in countries where ISUP must only be sent to licensed carriers. For example, called parties will see the calling party numbers, even if the calling party required privacy. Apart from the MIME issues, this prevents us from using encapsulation.
>
> 2) Encrypting SIP-T message bodies would solve 1), but looking at SIPit results, S/MIME for SIP is a dead technology.
>    

S/MIME for a general purpose network suffers from the classical key 
distribution problem. It's not used for the same reason encrypted email 
is not used (except among the geek community).

But you're not talking about general purpose networks.

You're talking about tightly constrained networks with PSTN gateways 
that are either all within a single administrative domain, or that 
communicate with each other through bilateral agreements. In these 
circumstances, key distribution is no more difficult a problem than IP 
address assignment. It's a simple matter of configuration.

> 3) Will application servers acting as B2BUAs deal properly with SIP-T multipart MIME bodies? People seem to be worried that they are not even able to forward a Reason header..
>    

B2BUAs will break whatever they break. Until someone sits down and 
documents their behavior, we can't really do too much to work around 
their behavior. It's the same problem we're having all over the place 
(identity, MSRP ACM, etc). There's no point in talking about something 
as nebulous as B2BUA behavior.

> 4) Many client don't implement Multipart MIME, as it can get quite complex (what to do with multiple SDP bodies, alternative SDP bodies etc). I'd have to ask my vendors to add complexity to the software without real benefit ("You'll have to implement multipart MIME, so we can send binary blobs to you the device has to throw away"). In the year 2009 some SIP clients don't even get simple SDP offer/answer right, how could we expect them to handle Multipart MIME in a sensible manner?

While many UAs won't be able to ignore the multitype body (aside: this 
is sad -- email clients all can), you'd be hard pressed to find one that 
can't understand multipart that also won't respond to a multipart body 
in a request with a 415. This ends up looking just like SIP 
authentication, since the UAC will detect the failure to support 
multipart and re-attempt with a single body:

  UAC           UAS
   |---INVITE--->|
   |<----415-----|
   |---INVITE--->|
   |<----180-----|
         ...
   |<----200-----|
   |-----ACK---->|



> 5) User agents might have to switch TCP, just to receive oversized SIP messages with SIP-T bodies that will by thrown away.
>    

At one point, you said "IMS." I don't think you'll find an IMS client 
that has any hope of receiving a UDP SIP message -- show me an INVITE on 
the terminating side of an IMS network that is somehow smaller than 1500 
bytes, and I'll be shocked into silence. TCP is a foregone conclusion.

/a