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

Peter Musgrave PMusgrave at newheights.com
Thu Apr 26 10:13:57 EDT 2007


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20070426/ea99ff4c/attachment.html 


More information about the techwg mailing list