ITU standards, such as, Q.1912.5, imply From header is used for caller id
display.
On Tue, Apr 3, 2012 at 3:46 PM, Brett Tate wrote:
> > But this section 8 is written so generically (eg "However,
> > any specific behavior is specific to implementations or
> > services") that it is pretty much sa
essage-
> > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
> > implementors-boun...@lists.cs.columbia.edu] On Behalf Of Romel Khan
> > Sent: Tuesday, April 03, 2012 12:50 PM
> > To: sip-implementors@lists.cs.columbia.edu
> > Subject: [Sip-implementors]
In a telephony environment, if an INVITE has both From header and
P-Asserted-ID
header, which are not the same phone numbers, shouldn't the CLI and caller
name for display be extracted from the P-Asserted-ID header? Per RFC 3325,
P-Asserted-ID header is more trusted. Is there any reason or case Fr
When a call comes into our system, we do look up whether this number is ours
or not. If it is not our number, we would return SIP 404. Then we check the
presence server to see if the device is registered. If it is not, we send
back SIP 480. A peer of ours is sending back SIP 403 in this case, which
What SIP code should a proxy send back to a caller if the UA the caller is
trying to reach is currently not logged in? Please provide the sip rfc
quote. Thanks.
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.colu
Agreed, 487 is the best choice. I would also opine that SIP 491 should not
be a choice for this particular scenario where the intent is to tear down
the call. SIP 491 Request Pending means the other side should wait a random
amount of time to retry the reINVITE. Since the intent is to tear down the
By the way, we are seeing cases where BYE being used terminating early
dialog without requiring reliable 1XX handling (ie no 100rel option, no
PRACK) in production environment.
On Wed, Jul 27, 2011 at 1:01 PM, Iñaki Baz Castillo wrote:
> 2011/7/27 Brett Tate :
> > The following are two rfc3261
RFC3261, sec 15 : "Typically, when the user hangs up, it indicates a desire
to
terminate the attempt to establish a session, and to terminate any
sessions already created. For the caller's UA, this would imply a
CANCEL request if the initial INVITE has not generated a final
If an INVITE contains an initial offer, per RFC3261 "the answer MUST be
in a reliable non-failure message from UAS back to UAC The UAC MUST
treat the first session description it receives as the answer, and MUST
ignore any session descriptions in subsequent responses to the initial
INVITE."
UPDATE RFC3311 mentions it does not affect dialog state (eg in Abstract:
"has no impact on the state of a dialog"). But the RFC later mentions
that UPDATE can update remote target (eg quote: "UPDATE is a target
refresh request. As specified in RFC 3261 [1], this means that it can
update the remote
UPDATE RFC3311 mentions it does not affect dialog state (eg in Abstract:
"has no impact on the state of a dialog"). But the RFC later mentions
that UPDATE can update remote target (eg quote: "UPDATE is a target
refresh request. As specified in RFC 3261 [1], this means that it can
update the remote
UPDATE RFC text seems to be centered on reliable provisional response.
The only example is covered with reliable provisional response. I know
of at least 1 vendor implementation that forces the use of UPDATE only
when provisional reliable response handling is used.
However the RFC does mention: "
12 matches
Mail list logo
