Hi Deepak,
Like re-INVITE, UPDATE is a target refresh request.
The Contact header in the next request sent by UAC MUST contain the updated
Remote target URI that it received in response to the previous UPDATE.
That is probably the reason why UAS must respond with 500.
Thanks,
Pranab
___
Hi,
Both the CANCEL and ACK issues that you are facing is because the sent-by value
of the Via header in both these requests is different from what was used in
INVITE.
The issue is with the UAC, UAS is not able to match the requests to an existing
server transaction.
Refer section 17.2.3 of rf
The only issue I can see is in the formation of FROM header in ACK request.
See if this header is exactly equal to that of INVITE. Everything else seems
to be fine.
Thanks
Gaurav Khare
- Original Message -
From: "Vivek Batra"
To:
Sent: Tuesday, January 22, 2013 9:40 AM
Subject: [Sip-imp
Hi Vivek,
As per RFC 3261 Section 9.1, To tag is compulsary for all the requests. See
the snippet below
The following procedures are used to construct a CANCEL request. The
Request-URI, Call-ID, To, the numeric part of CSeq, and From header
fields in the CANCEL request MUST be identical to
Hi folks,
I am facing issue with one specific service provider where UAS is busy and
hence sends 486 Busy message, and also get ACK for 486 Busy but UAS somehow
couldn't match the ACK transaction and keep retransmitting 486 Busy till
timeout. Can you have a look at ACK message below and suggest
Hi folks,
I am facing issue with one specific service provider where caller wants to
cancel the transaction and sends CANCEL message but UAS responds with 481
Call Leg/Transaction Does Not Exist. I assume that as per RFC 3261, CANCEL
message should not contain the To tag however in the below me
