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

[Ahmad, Syed]

Peter,
 
Assuming here that the SIP signalling passes thru an intelligent SIP
Proxy as it goes out from Enterprise to SP (Incase there needs to be any
header modifications) - correct?
 
Or should we assume that Firewall/NAT/Proxy traversal is beyond the
scope ?

Thanks & Best Regards 
Syed Ahmad
/PCCUK 

 

  _____  

From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On Behalf Of Peter Musgrave
Sent: 26 April 2007 15:14
To: techwg at sipforum.org
Subject: [SIPForum-techwg] (Interop) Basic Call Use Case



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



Note:
Email domain @kmeuk.co.uk will change to @eu.panasonic.com.
ie: john.brown at kmeuk.co.uk changes to john.brown at eu.panasonic.com. Please update your contact details now.


..............................................................................
Confidentiality Notice
The information contained in this Email, and any attachments, is intended for the named recipients only. It may contain confidential and/or legally privileged information. If you are not the intended recipient, you must not copy, store, distribute or take any action in reliance on it. Any views expressed do not necessarily reflect the views of the company.

If you receive this Email by mistake, please advise the sender by using the reply facility in your Email software and then delete it.
.............................................................................
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20070426/6a906c34/attachment-0001.html