Hi,
when a UA receives an INVITE request with a to-tag it should check if
there's a dialog that matches the request. But what if there's no
matching dialog? Should the UA treat it as an in-dialog request and
respond with an 481 (call leg/transaction does not exist) response. Or
should the UA
Ideally, the UA should reject with 481 (call leg/transaction does not exist)
response.
Some IP phones do this.
But, Pingtel or snom (I dont remember) was little liberal and was treating
the invite with to-tag as new call.
Regards,
Aswin Bhupalam.
- Original Message -
From: Sigrid Thijs
Hi All,
I am new to this mail grpu and SIP world :). I need some information
about how to construct the CANCEL message at the proxy level.
Scenario
1 Caller A sends INVITE message to PROXY
2 PROXY(stateful) send 100 trying to caller A and sends the INVITE
message to caller B
3 Caller A sends
Hi Sigrid,
If UA receives the request with to tag than it MUST use the same
tag in the response.See section 8.2.6.2 in RFC 3261.
If a request contained a To tag in the request, the To header field
in the response MUST equal that of the request. However, if the To
header field in
Hi,
This condition can occur, if the UAS might have crashed or restarted
for some reason. Its implementation dependent, either accept or reject this
request. Can be rejected as you said with 481 (call leg/transaction does not
exist) response, if accepted then UAS should be in a position to
Sigrid,
Both are legally possible. The final result will depend on what you
actually want. Please refer to sections 13.3.1 (point 3) and 12.2.2 in
RFC 3261.
Regards,
Anshuman S. Rawat
Software Group,
Conexant Systems India Private Ltd.
-Original Message-
From: [EMAIL PROTECTED]
On 11/18/05 13:37, Sigrid Thijs wrote:
Hi,
when a UA receives an INVITE request with a to-tag it should check if
there's a dialog that matches the request. But what if there's no
matching dialog? Should the UA treat it as an in-dialog request and
respond with an 481 (call leg/transaction
Hi,
I overlooked the question in my previous mail.
I agree with RamaKrishna comments.
In addition,
If the length of the corrupted SDP in 200OK is larger than
content-length UAC can send Ack
If the length of the corrupted SDP in 200OK is shorter than
content-length,UAC discards 200 OK and
Tadkot,
I think the problem is here -- and insert it own VIA header field
value.
Section 9.1 of RFC 3261 states that -
A CANCEL constructed by a client MUST have only a single Via header
field value matching the top Via value in the request being cancelled.
I am not sure about the branch
Anshuman,
You are right , that's where i have a doubt too. for the Via header
value for CANCEL and INVITE they differ in branch parameter value.Where
i dont know if that should be same.
What put me in doubt is , with CISCO MG it works!! but with pingtel is
doesn't.So not able to figure out the
Hi! Are the following Header Fields standard SIP
message content:
P-hint: USRLOC
P-RTP-Proxy: YES
P-Marked-Contact: YES
P-Behind-NAT: Yes
P-NAT-Checked: Yes
I just cant find any materials to describe these
fields. I usually see these after the
hi,
well when u get a 200 Ok for Re-Invite with a corrupted SDP then the UA
should send an Ack for the 200 ok and then depending on the local policies
you can -
1.send another Re-Invite with a new offer
2.still continue the media session with the previous successful
5 PROXY construct this message with same Request-URI, TO , FROM,
CALL-ID and Cseq number field values of the INVITE message send to
caller B and insert it own VIA header field value. the branch id is
different from the one which is sent in INVITE message to caller B.
Ah, your problem is the
Thanks!!
Are there any other parameters which also needs to removed/added/updated
while sending CANCEL for INVITE message.
Regards
-venkat
[EMAIL PROTECTED] wrote:
5 PROXY construct this message with same Request-URI, TO , FROM,
CALL-ID and Cseq number field values of the INVITE
Thanks for all your responses.
The problem is that our UA is being tested for etsi conformance, and one
of the test-cases (SIP_CC_TE_CE_V_016) has the following purpose:
Ensure that the IUT on receipt of an INVITE request with a TAG set on
the To header, sends a Success (200 OK) or a
On Fri, 2005-11-18 at 18:36 +0530, [EMAIL PROTECTED] wrote:
What put me in doubt is , with CISCO MG it works!! but with pingtel is
doesn't.So not able to figure out the right way to construct CANCEL message.
Have you read section 9.1 of RFC 3261? Its third paragraph starts The
following
On Fri, 2005-11-18 at 07:23 +0100, Jeroen van Bemmel wrote:
Yes, that's what I intended above (except that per Contact URI more than
just the expire time can be maintained). In my example the last Call-ID and
CSeq seen for that Contact URI are also maintained.
Although as far as I can tell,
Few questions:
Is it realistic for a PRACK to carry an offer? Isnt PRACK usually supposed
to carry an answer to a 183 OFFER? In what scenarios can a PRACK actually
carry an OFFER? ( only if INVITE had no offer and one recieved a 180? )
Also if an INVITE carried an offer and the 183 carried
Hi all,
I have been reading (RFC's and peoples postings) on SIP INFO and its use for
DTMF transport.
My question is:
Is it possible (practical) to send more than one digit in a SIP INFO
message?
What are the pros/cons associated with it?
Anyone know any implementations which this
Few questions:
Is it realistic for a PRACK to carry an offer? Isnt PRACK usually supposed
to carry an answer to a 183 OFFER? In what scenarios can a PRACK actually
carry an OFFER? ( only if INVITE had no offer and one recieved a 180? )
If INVITE has an offer and it is answered in 1xx-rel, PRACK
20 matches
Mail list logo
