[SIPForum-discussion] [Query] recommended behavior of a SIP proxyon receipt of REGISTER request
mjhorse
mjhorse at qq.com
Fri Jul 25 08:11:49 UTC 2008
Hi,
Just based on my knowledge. I don't think S-CSCF return provisional response in the duration of registration.
I've looked through some IMS related books and I found no such circumstance, neither did I encounter before.
------------------
by mj
------------------ Original ------------------
From: "dushyant"<dushyant.dhalia at rancoretech.com>;
Date: Fri, Jul 25, 2008 04:11 PM
To: "mjhorse"<mjhorse at qq.com>;
Subject: RE: [SIPForum-discussion] [Query] recommended behavior of a SIP proxyon receipt of REGISTER request
Hello Mj,
Thanks for the reply.
Please consider the case when my node is waiting for Cx response from HSS done on receipt of REGISTER message shouldn’t we respond the request with 100 trying to stop its retransmission from UE.
Dushyant P S Dhalia
From: mjhorse at qq.com [mailto:mjhorse at qq.com]
Sent: Friday, July 25, 2008 1:08 PM
To: dushyant
Subject: Re:[SIPForum-discussion] [Query] recommended behavior of a SIP proxyon receipt of REGISTER request
Hi,
I think there is no 100 trying process in registration. In general, registra should return 200OK if registration succeeds or return 4xx if fails.
------------------
by mj
------------------ Original ------------------
From: "dushyant"<dushyant.dhalia at rancoretech.com>;
Date: Thu, Jul 24, 2008 07:45 PM
To: "discussion"<discussion at sipforum.org>;
Subject: [SIPForum-discussion] [Query] recommended behavior of a SIP proxyon receipt of REGISTER request
Hi all,
I have a general question related to proxy behavior related to SIP/IMS registration.
What is the recommended behavior of a SIP proxy on receipt of REGISTER request w.r.t sending provisional responses? Should a proxy respond a REGISTER request with 100 Trying?
Dushyant P S Dhalia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20080725/8bc721ea/attachment-0014.html>
More information about the discussion
mailing list