Hi Muralish,
You can take the look at the following thread.
http://lists.cs.columbia.edu/pipermail/sip-implementors/2005-November/011002.html
Regards,
Somesh S. Shanbhag
--- Muralish P N [EMAIL PROTECTED] wrote:
hai
My name is Muralish.Can u please help me in
implementing sip in VoIP.
As per RFC 3265, subscribers need to refresh subscriptions on a periodic
basis using a new SUBSCRIBE message on the same dialog as defined in RFC
3261.
Chapter 12.2 'Requests within a Dialog' in RFC 3261 states,
The UAC uses the remote target and route set to build the Request-URI
and Route
On Fri, 2005-11-11 at 22:48 +0100, Jeroen van Bemmel wrote:
I disagree here. The proxy may not be able to determine whether the requests
are perceived as being the same, but that is not what it should be looking
at anyway. The loop check essentially determines if the proxy (and possibly
its
Dale R. Worley wrote:
The difficulty is that the proxy cannot discern which headers might
affect routing in downstream proxies.
IMHO, a proxy is responsible for routing decision *it* makes.
Outside of closely coupling the processing rules of two
proxies, I don't think one proxy can
Vijay K. Gurbani wrote:
Dale R. Worley wrote:
Even loop detection isn't sufficient. In the sipX proxy that Scott
and I work on, one can trivially -- or accidentally -- write
forwarding rules like this:
name@domain - nameA@domain name@domain -
nameB@domain
That will generate an exponential
The design goal in implementing loop detection is to detect and stop
infinite routing loops quickly. (The Max-Forwards mechanism will always
terminate them eventually.) The implicit complementary design goal is
to never signal Loop Detected on a request that would succeed
otherwise. It's easy
On Fri, 2005-11-11 at 21:10 +0100, Jeroen van Bemmel wrote:
And it's clear that all in-dialog
requests should have the proper Contact value for their end of the
dialog.
Strictly speaking: only in target-refresh or dialog-creating requests or
registrations. Contact is not allowed in BYE
On Thu, 2005-11-10 at 05:46 +, venu yadlapalli wrote:
If a SIP proxy, redirect server, or registrar is to be contacted
through the lookup of NAPTR records, there MUST be at least three
records - one with a SIP+D2T service field, one with a SIP+D2U
service field, and one with a SIPS+D2T
On Thu, 2005-11-10 at 11:37 -0800, Bob Penfield wrote:
RFC 3261 section 13.2.2.3 says
4xx, 5xx and 6xx responses may contain a Contact header field value
indicating the location where additional information about the error
can be found.
Yes, I'd say that that sentence meant to say
Hi,
In all the sections dealing with Registration, RFC 3665,
example call flow messages do not use nc in the Authorization
header.
This seems to be a deviation from RFC 2617, which states,
--
nonce-count
This MUST be
10 matches
Mail list logo
