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

[Paul Kyzivat]

Peter Musgrave wrote:
> 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...

As somebody who works for a "significant vendor" I realize you might be 
talking about my own company's products...

Nevertheless, when things are wrong they need to be fixed. Thats life.

It may be a different issue if we are talking about incompatibilities 
between implementations of different draft versions of ICE. I can see 
how that might present difficulties.

	Paul

> 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
>