Hi All,

Quick question on what the "correct" behaviour of a SIP redirect server
is expected to be, in a Voice Telephony environment where the redirector
is used solely to spread call load over a number of dedicated
Application Servers:

Initiating AS   Redirector              Destination AS

INVITE----------------->
<-------------100 Trying
<-------------180 Ringing *
<-------------302 Moved Temp
ACK-------------------->
INVITE---------------------------------------->
<------------------------------------100 Trying
<------------------------------------180 Ringing
<------------------------------------200 OK
ACK------------------------------------------->

Ideally, a SIP Redirect Server should only be implemented with a
"limited Transaction User layer, which has access to a location
service".  You would therefore expect that the server does not act on
behalf of the end service (the destination AS has this responsibility),
and is only responsible for responding with appropriate level of
information about how to reach the end service (via 3xx) or any error
handling (4xx).

As such, I would expect that there should be no need to send further
provisional 1xx responses after a 100 Trying - especially as a 180 is
generally used to indicate that the eventual destination has been found,
and is being alerted (which is not the case with a redirect server - as
the 302 indicates that in fact the end service is still yet to be
contacted).  

So I would then make the assertion that the 180 Ringing indicated by the
(*) is in fact superfluous - and I would argue - that it is actually
incorrect in a redirect server scenario to implement the stack in this
way.  Any thoughts?  

Regards

Nathan Smith
Senior VoIP Specialist
Enterprise Fixed & IP Calling
Telstra Corporation Ltd
Email: [EMAIL PROTECTED]

DISCLAIMER:
The information contained in this email message may be confidential. If
you are not the intended recipient, any use of, interference with,
disclosure or copying of this material is unauthorised and prohibited.
If you have received this message in error, please notify me by reply
email and then delete the message.

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to