Hi
I'm trying to implement support for handling challenges with algorithm
"AKAv1-MD5". Somehow I don't seem to get the correct calculated response, and
at the same time RFC3310 seems pretty straightforward.
AKAv1-MD5 consists of two steps, first calculate the RES using OperatorKey,
SecretKey a
until 200 OK is received (and by that
time there will be no more retransmissions of the provisional response.
Regards,
// Andreas
From: ankur bansal [mailto:abh.an...@gmail.com]
Sent: den 11 februari 2014 09:50
To: Olle E. Johansson
Cc: Andreas Byström (Polystar); sip-implementors
Hi
RFC3262 says the following about UAC:
"Note that the PRACK is like any other non-INVITE request within a
dialog. In particular, a UAC SHOULD NOT retransmit the PRACK request
when it receives a retransmission of the provisional response being
acknowledged, although doing so does not c
Hi
If a UA subscribes to register events it will first send out an SUBSCRIBE
request, receive a 200 OK for that request and eventually receive a NOTIFY. If
that NOTIFY requests includes a Record-Route header, should that header be
mirrored into the 200 OK for NOTIFY that the UE creates?
RFC326
...@wipro.com [mailto:santosh.kalsang...@wipro.com]
Sent: den 19 januari 2011 15:16
To: Andreas Byström (Polystar T & M); sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] SIP over TCP
Hi Andreas,
Is it 481 (call leg/transaction does not exist) response for BYE? I happen to
Hi,
I've just recently started to look at a scenario when SIP is sent over TCP (not
UDP as I'm used to have). I see a behavior that I'm not really sure it correct:
It's a very basic SIP call UAA -> UAB
1. UAA sends INVITE to UAB
2. UAB answers with 180 and 200 OK
3. UAA send
Hi all,
I have some problems matching an example of the P-Called-Party-Id header in
rfc3455 with the ABNF for the same header (in the same spec)
Section 5.1 in RFC3455 says the following:
"5.2 P-Called-Party-ID header syntax
The syntax of the P-Called-Party-ID header is described as follows:
Does "user not registered" really fit into the description of 404 in RFC3261? A
subscriber that isnt registered does still exists in the domain that is handled
by the server, doesnt it? I would say that the description of 480 is better for
the unregistered case. RFC3261:
