[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