thanks..
On Sat, Mar 28, 2009 at 12:00 AM, <
sip-implementors-requ...@lists.cs.columbia.edu> wrote:
> Send Sip-implementors mailing list submissions to
>sip-implementors@lists.cs.columbia.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
>https://lists.cs.columbia.
Hi
I have a question on 3GPP 24.229 specification related to IMS AKA as a
security mechanism.. As I have not received any replies in [IMSTech]
forum, wanted to get clarified with Sip Implementors.
Document: 24229-851.doc
1)"Section 5.1.1.4.2 IMS AKA as a security mechanism: On sending a
REGI
Đani Vladislavić wrote:
> Hi,
>
>
>
> could you help me ragarding the question marked with asterixes in
> attached file where call flow scenario is described. The questions are
> from MGCF point of view.
So I gather the MGCF is a B2BUA, right?
> 1st (*) Is it allowed to receive any SDP in 18
2009/3/27 Anuradha Gupta :
> Hi
>
> As per RFC 3261
> ---
> 21.3.5 380 Alternative Service
>
> The call was not successful, but alternative services are possible.
>
> The alternative services are described in the message body of the
> response. Formats
Hi
As per RFC 3261
---
21.3.5 380 Alternative Service
The call was not successful, but alternative services are possible.
The alternative services are described in the message body of the
response. Formats for such bodies are not defined here, an
Hi,
could you help me ragarding the question marked with asterixes in
attached file where call flow scenario is described. The questions are
from MGCF point of view.
1st (*) Is it allowed to receive any SDP in 183 reliable provisional
response as described? shouldn't the call be released immed
Hello ,
I have read this response code with respect to emergency services to provide
alternate service URN in xml body.
Regards,
Sumit Jindal
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñak
2009/3/27 Anuradha Gupta :
> Hi
>
> What should be the handling for SIP 380 response? Should it be handled as
> other 3xx response or it should be treated as a call failure.
380 is not a response code, but a warning code defined in:
http://tools.ietf.org/html/draft-ietf-sip-sips
Hi
What should be the handling for SIP 380 response? Should it be handled as other
3xx response or it should be treated as a call failure.
Regards
Anuradha Gupta
Aricent
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for
the us
