On Thu, Oct 2, 2008 at 11:09 AM, Harsha. R [EMAIL PROTECTED]wrote:
... they just refer to the fact that Tables 1 and 2 in rfc3262 extend
tables 2 and 3 in rfc3261 and the Contact is marked as optional in 1xx
responses. If 3262 clearly stated that reliable provisional responses
MUST have
2008/10/2, Harsha. R [EMAIL PROTECTED]:
Its not clear to me as to why the 18X is expecting a Contact. The purpose of
Contact is to do a target refresh.
18X missing a Contact header means a target refresh has not happened. In
this case, address the PRACK to
the original remote target(
Hi,
I need information on how to send DTMF tones as unsolicited Notify method
within an established dialogue. Can anyone explain the
steps to implement the same?
Information on any SIP soft-phone that supports DTMF as Notify would be of
great of help?
With regards,
Vivek GUpta
INFO is more appropriate to send DTMF using application/dtmf-relay
content-type. Please note that this is not IANA registered application mime
type though.
For example:
INFO sip:[EMAIL PROTECTED] [EMAIL PROTECTED] SIP/2.0
Via: SIP/2.0/UDP 172.80.2.100:5060
From: sip:[EMAIL PROTECTED] [EMAIL
Is a SIP proxy allowed to insert Option tags when forwarding a
request?
Not usually but this RFC allows it. I guess the reason is that protecting
against a poxy's resource leakage is sometimes considered more important than
allowing a call to proceed without the requirement.
In that case,
INFO is more appropriate to send DTMF using application/dtmf-relay
content-type.
That is a matter of opinion - some would say that DTMF should be solicited
before it is sent.
I guess though in this case, the NOTIFY is unsolicited anyway.
It is unusual for unsolicited NOTIFY to be used for DTMF
Hello,
Iñaki Baz Castillo wrote:
2008/10/2, Dmitry Akindinov [EMAIL PROTECTED]:
RFC 3262 says clearly that The provisional response ***MUST establish a
dialog*** if one is not yet created.
... they just refer to the fact that Tables 1 and 2 in rfc3262 extend
tables 2 and 3 in rfc3261 and
2008/10/2, Dmitry Akindinov [EMAIL PROTECTED]:
For me this means that, in RFC 3261, Contact must be present in a 2xx
to an INVITE.
Yes, but according to this table it's optional for 1xx. And 3262 does not
update that, though with reliable 1xx the Contact is more likely to be
needed to
2008/10/2, Manoj Priyankara (NOD) [EMAIL PROTECTED]:
Hi All,
Does anyone know the usage of XML inside SIP messages (like NOTITY) ?
What is exactly the question?
--
Iñaki Baz Castillo
[EMAIL PROTECTED]
___
Sip-implementors mailing list
Harsha. R wrote:
... they just refer to the fact that Tables 1 and 2 in rfc3262 extend
tables 2 and 3 in rfc3261 and the Contact is marked as optional in 1xx
responses. If 3262 clearly stated that reliable provisional responses
MUST have Contact - we would not have this issue
Its not
I'm not going to tell you how to do that because it isn't a legal sip usage.
It is true that some things have been known to use unsolicited NOTIFY.
I'm not certain I have heard of it for DTMF, but I have heard of it for
MWI. But its still not a standard usage.
The only plausible reason I can
On Thu, Oct 2, 2008 at 12:39 PM, Manoj Priyankara (NOD)
[EMAIL PROTECTED] wrote:
Does anyone know the usage of XML inside SIP messages (like NOTITY) ?
There are tens of RFCs registering new XML-based MIME types as well as
new XML namespaces.
This paper [1] might be what you are looking for,
Hello,
Iñaki Baz Castillo wrote:
2008/10/2, Dmitry Akindinov [EMAIL PROTECTED]:
For me this means that, in RFC 3261, Contact must be present in a 2xx
to an INVITE.
Yes, but according to this table it's optional for 1xx. And 3262 does not
update that, though with reliable 1xx the Contact is
What is the behavior of the receiver if it receives offer with
different
session id in
re-INVITE or UPDATE?
Take down the call as REINVITE o-line with a new session id identifies a
session that does not exist at UA.
[Kamal]
Taking down the existing call may not be a good idea, one can reject
14 matches
Mail list logo
