[SIPForum-techwg] (Interop) Basic Call Use Case

[Peter Musgrave]

I agree it's a deliberately too draconian start. 

However, I did find that at SIPIT20 I had to turn off ICE headers in
order to make calls to equipment from a "significant vendor". So I'm ok
with SIPConnect enforcing "ignore headers you don't understand - but it
does mean some "significant vendors" have some work to do...

Peter

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com] 
Sent: Thursday, April 26, 2007 11:18 AM
To: Peter Musgrave
Cc: techwg at sipforum.org
Subject: Re: [SIPForum-techwg] (Interop) Basic Call Use Case

Hi - kibitzing here...

What you suggest is certainly draconian! At the very least I think you 
must distinguish between what may be *sent* and what is acted upon. A 
fundamental principle of sip is that headers, options, etc. that are not

understood are ignored. You should not be forbidding things from being 
included.

So for instance you should not be banning the presence of ICE headers, 
even if the expectation is that the other side is not going to 
understand and/or honor them.

The difference is key to allowing the same device to operate in multiple

environments.

	Paul

Peter Musgrave wrote:
> Hi all,
> 
>  
> 
> To ensure a successful basic call some clearly specified limitations
on 
> the degrees of freedom in the various RFCs will be necessary.
> 
>  
> 
> The **most extreme** point of view would be to limit the call to
INVITE, 
> OK , ACK and BYE (with no reINVITEs to change media endpoints after
call 
> establishment, no 302s etc.).
> 
>  
> 
> No registration is required for call establishment.
> 
>  
> 
> Enterprise to SP Call:
> 
>  
> 
> 1)     Establish TLS connection
> 
> a.      SP server to be identified by a FQDN and SPS located via SRV
> 
> b.      Certificates MUST be verified
> 
> 2)     INVITE from E -> SP
> 
> a.      INVITE must contain sdp offer with public IP and port (and no 
> ICE headers)
> 
> b.      Codec offered is G711 only, with no ptime (RTP will be 20ms) 
> [keep the sdp as simple as possible]
> 
> c.      RFC2833 to be used for DTMF
> 
> d.      From header per SIPConnect Option 2 (12.1.2 From header only)
> 
> e.      To header per 12.2.1 (sip URI)
> 
> f.       ReqUri uses same rules as To header
> 
> 3)     SP response
> 
> a.      No early media
> 
> b.      200 OK sdp has RFC2833 dtmf
> 
> c.      Sdp has no ptime. RTP 20 ms
> 
> d.      To/From unchanged from INVITE - no extra identity headers.
> 
> e.      Re-uses existing TLS connection (is this actually required??)
> 
> 4)     ACK
> 
>  
> 
> The only message allowed after dialog establishment is BYE (from
either 
> side).
> 
>  
> 
> Any change in call state within the enterprise must be hidden from the

> service provider.
> 
> The media must continue to flow to/from the originally negotiated 
> IP/port. Media renegotiation is not permitted.
> 
>  
> 
> Session timers are not enabled.
> 
>  
> 
> No messages are challenged.
> 
>  
> 
> I realize this seems draconian - but hopefully by seeing which parts
are 
> viewed as unreasonable we can get to a consensus on which restrictions

> are untenable.
> 
>  
> 
> Peter
> 
> 
>
------------------------------------------------------------------------
> 
> _______________________________________________
> techwg mailing list
> Send mail to: techwg at sipforum.org
> Unsubscribe or edit options at:
http://sipforum.org/mailman/listinfo/techwg