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

[Paul Kyzivat]

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